|
Thnak u very much
Tejaswini
|
|
|
|
|
Hi all,
I want to Print the Document in Specified Document. I am unable to Decide the Margin's while Printing. Please Help me out.
//===========================================================================
CPrintdlg print(FALSE,PD_AllPages,this);
if(print.DoModel()== IDOK)
{
CDC dcPrint;
dcPrint.Attach(print.GetPrinterDC();
DOCINFO doc; // Setting the Printer Documents....
if(dcPrint.StartDoc(&doc > 0)
{
dcPrint.StartPage();
int x,y;
x = GetDeviceCaps(...); //x,y Cooridinates for Printer.
y = GetDeviceCaps(...);
dc.print(xloc,yloc,"Text"); //----> I have doubt here.
//---> How to Set the Margin for the Page Here.
dcPrint.EndPage();
}
}
UDAY
|
|
|
|
|
As I know:
1) there is no idea to get margin info of a printer.
2) margins can not be adjusted by VC applications.
it is very strange that same printer may have different margins if printed by different PCs.
---- You may ask for another thing?
-- modified at 7:16 Thursday 13th July, 2006
|
|
|
|
|
hi,
TO set Margings mean how to calculate the space it top,left,bottom,right while priting. which is done in VC++ application.
I want to Calcualte the Margin in VC++ only not in Priter.
You understand.
Thanks
uday.
|
|
|
|
|
hi
tell me about WM_COMMAND function in mfc with example or code
to clear my concept
Ashish Dogra
MCA
Noida
|
|
|
|
|
The WM_COMMAND message is sent when the user selects a command item from a menu, when a control sends a notification message to its parent window, or when an accelerator keystroke is translated.
|
|
|
|
|
And here's an extension to the above post
From DOCS
wParam
The high-order word specifies the notification code if the message is from a control. If the message is from an accelerator, this value is 1. If the message is from a menu, this value is zero.
The low-order word specifies the identifier of the menu item, control, or accelerator.
lParam
Handle to the control sending the message if the message is from a control. Otherwise, this parameter is NULL.
Somethings seem HARD to do, until we know how to do them.
 _AnShUmAn_
-- modified at 5:54 Thursday 13th July, 2006
|
|
|
|
|
Did you saw MSDN.
From the MSDN
"This message is sent when the user selects a command item from a menu, when a control sends a message to its parent window, or when an accelerator keystroke is translated."
whitesky
|
|
|
|
|
|
Hi toxcct,
its not problem do you konw why?i think he is lucky because he and you and programers are here and
he find his answer when he has a question he write his question here
whatever this question is clear or not clear but when i start to learn VC i dont have any resource
(teacher or website or anything) except MSDN
"Viens,laissons l'Avenir; laissons nos chagrins fous
Jouissons du present fugitif et si doux!"(Khayyam)
whitesky
|
|
|
|
|
actually, it's always easy to ask valuable people who know the answer to your question. but hey, the minimum he can do he search a bit by itself, googling, searching the msdn... and only then, ask the forum. people sometimes seems so lazy 
TOXCCT >>> GEII power
[VisualCalc 3.0 updated ][Flags Beginner's Guide new! ]
|
|
|
|
|
of course you right before ask a question he can search then he asks
I agree with you
whitesky
|
|
|
|
|
Except he obviously was too lazy because simply typing WM_COMMAND (no need even for site:msdn.microsoft.com) into google brings up the relevant information.
earl
|
|
|
|
|
CP is not MSDN. There topics need some explanation. The first resource to get informatio is MSDN. if it's not clear (rare chance) or something not included, that can be asked here. Most of the MSDN entries regarding Win32 and MFC contains sample snippet.
WM_COMMAND from MSDN[^]
About Messages[^]
SaRath.
"Where I am from, there is no plan B. So, take advantage of today becuase tomorrow is not promised. - 50 Cent"
My Blog | Understanding State Patte
|
|
|
|
|
Hi All .
I need to know that DCOM is faster for data Communication between 2 computer or Socket Programming.
Thanks .
-- modified at 7:20 Thursday 13th July, 2006
|
|
|
|
|
sockets (almost) every time, DCOM is not very fast (obviously DCOM can use sockets as it's transmission layer)
but like anything else, it depends on the implementaion, a badly written sockets layer could run slower than DCOM
Darka [Xanya]
|
|
|
|
|
sockets make you write most of the protocol stack yourself, giving you more chances to screw it up. With a good implementation they can be faster.
earl
|
|
|
|
|
Hi friends,
Given a lib file, Is there any way to identify whether the lib is Static or Dynamic one ??
Thanks in advance.
Appu..
"If you judge people, you have no time to love them."
|
|
|
|
|
libs are not be classifed as static or dynamic, the dlls are classifed as static or dynamic.
a dll can be used dynamically as well as statically, it depends on how the host exe file has been compiled and linked.
if you use depends.exe to view the dependency of the host exe file and if you see the dll under question in the dependency list then it means that that dll was statically linked to the host exe file.
And if you dont see it then the dll is dynamically used.
ofcource you should be sure that the host exe file is using the dll in the first place.
-Prakash
|
|
|
|
|
Mr.Prakash wrote: libs are not be classifed as static or dynamic
but they do often require linkage to either the static or the dynamic C/C++ runtime libs. that is, you can't use a lib built for use with the static CRT in an app built for use with the dynamic CRT - you'll get many link errors.
it's possible that's what the OP is asking about...
Cleek | Image Toolkits | Thumbnail maker
|
|
|
|
|
to clarify, when i said libs i was refering to .lib files.
.lib files are always linked to get either .exe file or .dll file or any other type of executable binary ouput.
-Prakash
|
|
|
|
|
Mr.Prakash wrote: libs are not be classifed as static or dynamic, the dlls are classifed as static or dynamic.
That is only partially correct. *.lib files area always statically linked. That is, when you link with a lib file, the code from it becomes part of your executable (be it a dll or exe). *.dll files are always "dynamic", but they have 2 types of binding (early and late). Early binding to a Dll is when you link to it specifically (that is, include the header file and have its lib placed in the link path), the linker puts the location of the dll resource your executable is trying to access in place of copying the code for it. You can think if it kind of like a pointer to what you really want, which resides in the dll. Late binding is when you use LoadLibrary/GetProcAddress to open a dll and search for the resource you want to use. To compile an executable using early binding, you need to have access to the dll, its header files, and its lib. To compile an executable using late binding, you don't even need the dll on the machine (though, without it, your code won't run when you try to execute it).
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Zac Howland wrote: but they have 2 types of binding (early and late)
you are confused, both late and early "binding" (as you call it) needs both .lib and .h file to get the necessary binary.
Early binding means the OS loads the dll whenever the host exe is loaded. while late binding is that the os loads the dll when it is required to be loaded i.e some method call in that dll.
actually its not called binding, there is something better word for that, cant remember what it is 
what you are saying is statically linked dll, and dynamically linked dll.
-Prakash
|
|
|
|
|
Ah no -- you certainly don't need a .lib for both.
They're called "linking" in the MS docs. Early linking means you use a lib and your linker inserts thunks that are later fixed up either on exe start when the run time loads the dll or on first function call if you used a delay-load pragma.
Late linking, or a dynamically linked dll, you have no lib and not necessarily any .h file (though the latter helps, because you need to know the function signatures). You can simply call LoadLibrary then GetProcAddress with a function name to get a function pointer and that's it. There is no type checking on the function pointer so you better know the signature (here's where a h file is handy) but no h file is required.
See: MSDN[^]
earl
|
|
|
|
|
I assume what you mean is: "by looking at a lib file, can I determine if the executables (or DLL's) that link with it will contain the code that the lib is representing, or will the executable need to load the code from an external DLL?".
You link to a lib file to be able to use code that you are not providing. For example, the "fopen" function needs the "libc.lib" library (or equivalent) to provide you with the code necessary to open a file. You will not provide this code, the "libc.lib" will. Let's call this the "additional code".
However, the way the lib provides the additional code to you can be in 2 diferent ways:
1) It can contain the additional code itself (the set of additional machine instructions that do the actual job that you are needing). In this example, the additional "fopen" code would be contained in the lib, accessing the disk, locking the directory, marking the file as open, etc...
2) It can request the OS to load a DLL from disk and get the additional code from it. In this situation, the lib loads the DLL from disk (usually when the executable loads into memory and before it begins to run) finds the address of the "fopen" function code within it, and provides you with a link to acess this additional code present in the DLL. So, when you call "fopen" you are accessing the lib's "fopen", which is a stub that just links to the location in the DLL where the actual "fopen" code resides and executes it for you.
So, the best indicator that a lib contains the code or not is the size. Small libs (50kb or so) typically contain only names of functions to link to the DLL. Larger libs (500kb or more) usually contain the code itself, and do not rely on external DLL's. These values, of course, are just general guidelines.
The most acurate way I now is for you to produce your executable and then use the dependency walker to determine if it depends on external new DLL's ("new" means "the exe did not need them until I linked with the libs").
Also note that the linker is very smart. If you are not using code from a lib then just linking with it does not mean a DLL will be needed, since the linker will find that out and end up not using its code. To be sure you use it call some of its functions in your program.
I hope this helps,
Rilhas
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
