|
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
|
|
|
|
|
Hi,
I need to get the width and height of the monitor.
i tried with GetWindowRect, I am able to get the width( .right) correctly but when it comes to height, the .bottom shows an integer which will be just more than half of the screen.
some one please suggest me.
thanks,
kk_mfc
|
|
|
|
|
I guess you REALLY need this as you have posted it 3 times.
Darka [Xanya]
|
|
|
|
|
try this,
RECT rcWorkspace;
SystemParametersInfo(SPI_GETWORKAREA,0,(LPVOID) &rcWorkspace,0);
regards,
Darka [Xanya]
|
|
|
|
|
Either take the window rect of desktop window or use
GetSystemMetrics() funtion with the following parameters
SM_CXSCREEN - for width
SM_CYSCREEN - for height
nave
|
|
|
|
|
Use GetMonitorInfo()
Appu..
"If you judge people, you have no time to love them."
|
|
|
|
|
GetSystemMetrics retrieves width and height (in pixels) use this function with SM_CXSCREEN and
SM_CXSCREEN<code><br />
and see <code>ScreenToClient maybe it is some helpful to you
whitesky
|
|
|
|
|
Thanks to all.
kk_mfc
|
|
|
|
|
I am working in C++ and I need to run an executable , "Process#1", within the context of another executable, "Process#2". Process#1 is bound to throw exceptions and Process#2 must be able to handle the exceptions thrown by process#1. I am unable to handle using createprocess() or ShellExecute(). Please let me know if there is a way to accomplish this.
Cheers
Pavan
|
|
|
|
|
There is no easy way of doing this apart from Process#1 catching the exception and telling Process#2 what happened using some form of interprocess communication, you cannot throw exceptions across process boundaries which is a good thing.
Darka [Xanya]
|
|
|
|
|
This is an unusual scenario and, without knowing exactly what you’re up to, I feel safe saying it is probably a bad design decision. That said it is possible. When you use the CreateProcess API you can pass the DEBUG_PROCESS or DEBUG_ONLY_THIS_PROCESS flags (the second is probably what you’re after) in the ‘dwCreationFlags’ parameter. This flag is used by debuggers, as you probably guessed by the name, and results in exceptions thrown in the child process being reported to the parent. The information is passed to the parent process via the WaitForDebugEvent API. There is more to it that that obviously and, as I said, I don’t recommend using this technique. If you don't know exactly what you're doing you'll make a mess. Also throwing an exception becomes much more expensive for the child as it now results in a context switch to the parent and back to the child again. The child my also behave slight differently in some aspects; for example the ghost window[^] feature will not work in the process being debugged (the child). That said there are protection schemes, such as Armadillo, which use this technique and the software which uses it seems to work ok and when a developer is making an app it works in the debugger. Also note that as a process can only have one debugger attached to it you will probably not be able to use your debugger on it and even debuggers which can work under these conditions (such as WinDBG) will not be as powerful under this environment.
Steve
|
|
|
|
|
Steve, thank you for all that information. I wish to putforth a little more information that I need.
The child process handles most of the known exceptions, however, the parent process should handle the rest of the exceptions thats not handled by the child process itself. Exception handling by the parent process is a major part of the app that I need to develop.
|
|
|
|
|
When the child process ( sample.exe ) throws an exception, I am unable to get the Exception info thrown by the child process in the parent process's DEBUG_EVENT structure.
<br />
#include<stdio.h><br />
#include<windows.h><br />
<br />
STARTUPINFO startupInfo;<br />
PROCESS_INFORMATION processInformation;<br />
DWORD code;<br />
DEBUG_EVENT debug_event;<br />
BOOL val = 1;<br />
int main()<br />
{<br />
<br />
BOOL b = CreateProcess(NULL,"Sample.exe", NULL,NULL,FALSE,DEBUG_ONLY_THIS_PROCESS ,NULL,<br />
NULL,&startupInfo,&processInformation);<br />
val = WaitForDebugEvent(&debug_event, 2000);<br />
return 1;<br />
}<br />
Cheers
Pavan
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
