Well, then you should fix the problem. Is it one of your application that crashes ?
TerminateProcess will kill the process in a brutal way, sending a WM_CLOSE message is much elegant because it lets the application do some clean-up before exiting.
I wrote a program in C++ MFC and create 2 more thread , this program ryn on several computers .
recently I bought a new PC and the program can’t create more then one thread .
The same program work nice on other PCs.
All the PCs run WINDOWS XP PRO.
DWORD res=DocumentProperties(0,hPrinter,ptiSel.sPrinter.GetBuffer(0),pDefDEVMODE,pDefDEVMODE, DM_OUT_BUFFER | DM_IN_BUFFER);
if(res != IDOK) MessageBox(0,_T("Could not set printer settings"),0,MB_ICONERROR);
This code is based on msdn sample (http://support.microsoft.com/kb/167345). Settings are not changed. The second call of DocumentProperties retrieves valid DEVMODE structure, I change it and save back to printer, the function returns IDOK result but does not write settings to printer. Can anybody help me?
_beginthreadex instead of CreateThread or visa versa
_beginthreadex() internally calls CreateThread for creating thread. In addition to creating thread, it will perform some CRT initializations also. So if you want to call some CRT functions inside the new thread, its better to use the _beginthreadex() function.
The Value return from GetCurrentthreadId and GetCurrentThread
GetCurrentthreadId return the current thread ID where GetCurrentThread return the handle to current Thread.
handle The GetCurrentthread API returns -1
If you call the GetCurrentthread(), it will always return 0xfffffffe. Actually this is a pseudo handle to the current thread. This value can be used only in that thread. The GetCurrentProcess() also returns a similar value - 0xffffffff.
If you want to get the correct handle value, you need to use the DuplicateHandle() function
HANDLE hRealHandle = 0;
DuplicateHandle( GetCurrentProcess(), // Source Process Handle.
GetCurrentThread(), // Source Handle to dup.
GetCurrentProcess(), // Target Process Handle.
&hRealHandle, // Target Handle pointer.0, // Options flag.
TRUE, // Inheritable flag
DUPLICATE_SAME_ACCESS );// Options
Unfortunately you are correct that those messages are indistinguishable. SendInput() inserts the input messages directly into the kernel input stream. You can read one of my prior posts[^] regarding how SendInput is actually invoking a privileged system call. [^]
If there is a security reason as to why you want to block this function then the only way I can think of is a driver implementing a SYSENTER hook[^].
I am having trouble capturing the mouse wheel messages. Everything works except when WM_MOUSEWHEEL is called, the HIWORD of wParam (combination of WHEEL_DELTAs, positive value means wheel is moved away from the user, negative is towards) is always 0. What is the problem? I am using Visual Studio 2003 btw.
// mousehook.cpp : Defines the entry point for the application.