|
How strange - because I copied it directly from your post - since first of all I hate typing and secondly its always better to copy paste :p
But it is working now - let me test the output etc.
Thanks in advance <3
|
|
|
|
|
But I really think you should not be driving now. 
|
|
|
|
|
No Im not driving lol.
It works!
*cheering the hell outta it*
Adding text to the TextBox and with a button its sending the data to my vector string which can be read and send to the output 
Thank you very very much! I really needed this line!
<33 ![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
|
|
|
|
|
Hi there,
I got the following problem. For an application that I have already up and running I wrote something like an observer program. The observer simply checks from time to time if the application is still alive and responding. If that is, for whatever reason, no the case, the observer kills the application process (TerminateProcess()) and starts another instance.
Now that works quite well so far. Only when a windows error report or such something pops up in the trail of an application crash, the observer is unable to kill the application. So the whole mechanism breaks down.
My question is, is there a possibility to kill an application nonetheless? Or to find out what is blocking the killing and to kill that one first then?
I could get all the possible process names of the processes that might show up, but that will always leave a hole in the system.
Any ideas on that?
Souldrift
|
|
|
|
|
Souldrift wrote: My question is, is there a possibility to kill an application nonetheless?
I would have thought TerminateProcess() to be the right choice as it is used to unconditionally cause a process to exit.
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
First and foremost: never use TerminateProcess to terminate your application, there should be a better method.
If you nonetheless want, at extreme stage, to kill unconditionally the application then use TerminateProcess (rules are there to be broken...  ): as suggested by David, there's no worst hammer than such a function (AFAIK).
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Check the return value of TerminateProcess() and get the error code, if any, using GetLastError().
Is the application and observer running in different user contexts?
If so GetLastError should return Access Denied(5).
|
|
|
|
|
Hey, I'm using Windows Hook, I installed the mouse hook, system-wide and its working perfectly. Now there is a problem, I need to the get window handle on which the mouse was clicked.. How do I do that? Does the Mouse hook event passes us that information?
|
|
|
|
|
Are you using WH_MOUSE?
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
Well, I was using WH_MOUSE_LL earlier. I changed my code to WH_MOUSE.
Now the code is:
HWND hWnd = NULL;
HWND hDesktopListWnd = NULL;
hWnd = FindWindow(_T("ProgMan"), NULL);
hWnd = GetWindow(hWnd, GW_CHILD);
hDesktopListWnd = GetWindow(hWnd, GW_CHILD);
threadID = GetWindowThreadProcessId(hDesktopListWnd, NULL);
hookMouse = SetWindowsHookEx(WH_MOUSE, (HOOKPROC)InternalMouseHookCallback, g_appInstance, threadID);
It installs the hook successfully, but I don't get the mouse hook events now. Basically I want to get click events when any icon on the desktop is clicked.
|
|
|
|
|
Ahmed Manzoor wrote: Well, I was using WH_MOUSE_LL earlier.
In the LowLevelMouseProc() function, the lParam is a MSLLHOOKSTRUCT structure.
Ahmed Manzoor wrote: I changed my code to WH_MOUSE.
In the MouseProc() function, lParam is a MOUSEHOOKSTRUCT structure.
Both of these structures have a pt member.
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
Hmmm. But I ran into another problem. Since I only needed Desktop's ListView (SysListView32) mouse events. I used WH_MOUSE because it can be thread specific whereas WH_MOUSE_LL can be global hook only that's why.
Now when I did this change, I'm not getting any events when I click on the desktop icons or anywhere in the desktop.
hookMouse = SetWindowsHookEx(WH_MOUSE, (HOOKPROC)InternalMouseHookCallback, g_appInstance, threadID);
Here g_appInstance is the address of the DLL. threadID is the ID of the thread in which there is the SysListView32 (which is the desktop). InternalMouseHookCallback is a callback of .NET function.
But now its not working. Please help me out. I'm using the Global System Hooks in .NET
|
|
|
|
|
The first parameter is wrong.
hookMouse = SetWindowsHookEx(WH_MOUSE, (HOOKPROC)InternalMouseHookCallback, g_appInstance, threadID);
You should handle "WM_MOUSE" in the "InternalMouseHookCallback".
|
|
|
|
|
|
transoft wrote: The first parameter is wrong.
No, WH_MOUSE is correct.
transoft wrote: You should handle "WM_MOUSE" in the "InternalMouseHookCallback".
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
I am writing a C++ application using Win32 API (i.e. no MFC, no .NET). I want to process some major messages such as WM_PAINT, WM_MOUSEMOVE, and WM_CHAR in the dialog procedure (let's call it DialogProc). The dialog is created using DialogBox or DialogBoxIndirect in some cases, and DialogProc is passed as the fourth argument to DialogBox. My problem is these aforementioned messages (WM_PAINT etc.) are not passed to DialogProc. Is there any way to catch and handle these messages in a dialog box procedure? or do I have to create a dialog box using RegisterClass and CreateWindow? I appreciate your help.
|
|
|
|
|
You can try to register your class.
|
|
|
|
|
On Mac OS there is a command called "CreateWindowGroup" which allows you to group two or more windows together. These windows move, minimize and maximize as a single unit. I am looking for something similar for Windows. I am coding in C++
Does Windows have something like this built in or would I need to roll my own?
modified on Thursday, October 29, 2009 3:25 PM
|
|
|
|
|
shaosean wrote: ...would I need to roll my own?
Yes. See the example here. Basically it just enables/disables all controls that are contained within the group.
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
Not a group of controls, but a group of windows.. Open two NotePad windows up, move one of them and pretend the other one was moving too 
|
|
|
|
|
shaosean wrote: Not a group of controls, but a group of windows..
In Windows, everything is a window. You are referring to an application window rather than a control window.
shaosean wrote: Open two NotePad windows up, move one of them and pretend the other one was moving too
I've never seen such behavior.
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
(I just started programming for Windows today so some of the lingo is a little different from one OS to the next)
Yes, an application window.. If everything is a window, would the same concept of grouping control windows work with application windows? Something for me to test out when I get back home..
|
|
|
|
|
shaosean wrote: If everything is a window, would the same concept of grouping control windows work with application windows?
Without digging into it deeper, I can't say for sure. If it is, I doubt it's 5-6 lines of code like that example I referenced.
Just out of curiosity, why would you want/need such behavior?
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
Two keep two windows linked together of course 
The plugin I wrote on the Mac has this feature (part of the OS) and someone had requested this feature for Windows and seeing as I am starting the Windows version of the plugin I thought I would try to tackle it but it seems like I may need to wait for this feature..
|
|
|
|
|
shaosean wrote: Two keep two windows linked together of course
Admitingly, I've only been using Windows for 20 years, but in all that time, I've never had the need to link two separate windows together. Other peoples' mileage may vary, however.
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
