I want to prevent users from closing a window by Alt + F4 or by clicking the close button.
How to achieve this?
I guess the windows API can do it, but I don't have any experience, and I can't find a specific solution.
Of course, it's good to be able to implement it,don't have to use a specific API.
Background: it is very difficult to find the last place in Word after closing it for a few days. After word2013, word2013 brought with it a way to return to the previous reading position, but that thing is very unstable and often can't be saved. When word is closed, I want to stop closing and pop up a notice to remind me to add a bookmark before exiting.
EDIT: This won't work, as it turned out. At least the message hook won't work because the message is posted and not sent, and about the CBT hook I'm not sure either, and I can't test it at the moment to give an evidence-based statement. The solution is probably to subclass the window but this is also non-trivial and I can't explain it properly and with working examples right now. I can't delete this answer though because it already has a comment. See here for more info. So take it with a grain of salt. I'm turning the answer to community wiki, feel free to edit it and fix/improve the solution!
EDIT2: Seems even subclassing won't be enough because Word is doing things its own way.
You need a windows hook. Either a CBT hook or a getmessage hook will do.
You have to create a DLL for this to work. The hook handler must be located in the DLL. It must have the same bitness as Word (probably 64 Bit). Then you call SetWindowsHookEx to install a global hook.
In the hook, you will have to check whether the current action is a window-closing attempt (in a CBT hook you would check for a HCBT_SYSCOMMAND of SC_CLOSE, in a getmessage hook you would check for a WM_CLOSE message), and whether it is about a Word window (for example using the window class - not sure if it has a recognizable class, you'd have to check - or the process' executable file name which you can get using GetModuleFileName since you will run inside Word's process) and prevent the action (by returning 1 from a CBT hook or returning 0 from a getmessage hook - to allow, call CallNextHookEx).
Related
I need my Visual Studio extension to react to debugging events. I've registered a IDebugEventCallback2 and I'm receiving events, but all I get for each event is an opaque IDebugEvent2 and a Guid, many of which are not only undocumented but don't appear anywhere on the web (or in my registry).
My specific requirement at the moment is to know when the process is Continued - ie. the user has hit Continue, Run to cursor, etc. What Guid should I be looking for?
Or is there some other event family that I should be subscribing to?
(More generally, is there some way I'm missing to find out about the events that are delivered to my IDebugEventCallback2::Event callback, when many of them don't appear in MSDN or anywhere else? Thanks!)
There is no easy way to do this. Actions such as Continue and Run to cursor are abstractions implemented by Visual Studio and do not correspond to any unique event(s) with respect to the debug engine. The debug engine event reporting interface IDebugEventCallback2 will enable you to get notified only on fine-grained events such as when creating a breakpoint or reaching a breakpoint.
While Visual Studio enables you to perform actions such as Continue and Run to cursor programmatically, it does not provide a direct way to get notified when they are taken.
You can use EnvDTE.DebuggerEvents.OnXxx events to get notified when something is about to happen. In particular, the OnEnterBreakMode event enables you to intercept a breakpoint hit and possibly take an action. You can also inspect all the details of the reached breakpoint(s) using the current EnvDTE.Debugger inside the event handler.
Now with some effort, you can use these constructs to implement events that correspond to all Visual Studio debugging actions including Continue and Run to cursor accurately. If you require additional events not provided by EnvDTE.DebuggerEvents (such as when a breakpoint is inserted), you have no choice but use IDebugEventCallback2.Event. In this case if you have specific events in mind, please mention them explicitly and I might be able to tell you the corresponding IDebugEventCallback2.Event GUIDs.
You probably got off on the wrong foot here, the IDebugXxx interfaces were really intended to create your own debugging engine. Still useful perhaps to see what is going on in the existing engine, you are suppose to use QueryInterface() to discover the specific interface that matches the event. Like IDebugEngineCreateEvent2, IDebugProcessCreateEvent2, IDebugProcessDestroyEvent2, etcetera. There are a bunch of them, they are listed in the VSSDK\VisualStudioIntegration\Common\Inc\msdbg.h header and include their IID.
Best thing to do is peek at this sample, it shows how to crack the event notification into the specific interfaces. The AD7Events.cs source file shows the wrappers. Do keep in mind that this sample was made to show how to create an engine, not how to use the one already built into VS.
But yes, you are not going to get a "continue debug" event out of this. A debugging engine does not need that event since it is already responsible for taking care of that by itself. It already knows when it calls IDebugProgram3::Continue().
Surely what you are looking for is IVsDebugger.AdviseDebuggerEvents(). That's the one that tells you what the built-in debugger is doing. You need to pass an object of a class that implements IVsDebuggerEvents, your OnModeChanged() method will be called with a DBGMODE notification. I don't see a lot of fantastic examples that demonstrate usage, this web page might be helpful.
Our application loads 3rd party DLLs that sometimes pops MessageBoxes.
We've notices that sometimes we can't just use exit(0) when there's an open MessageBox.
How can we still force an exist in such a case?
Thanks
Seems like your ugly DLL calls MessageBox (or whatever) from within DLL_THREAD_DETACH or DLL_PROCESS_DETACH.
If this happens in the same thread (i.e. the thread the calls exit) you may try to call PostQuitMessage right before the application exit. This should abort any message loop. If this happens in another thread - you may call PostThreadMessage.
There's also an option to intercept calls to Win32 API functions by hooking the appropriate module (Exe/Dll) import table. Invented by J.Richter (if I remember correctly). http://www.player.idv.tw/prog/index.php/APIHook
If you want to use brute force you may call the TerminateProcess() function. I'm not sure this is a good idea, you may want to detect if there's an open message box and send a close to it (for example using a FindWindow())
Take a look at MSDN.
My application is loading 3rd party DLLs, and some of this DLLs open MessageBox windows.
Is there a way for me to detect when such a window was being opened?
You'll need a CBT hook to receive a notification when a MessageBox window is displayed. You install this by calling the SetWindowsHookEx() function and specifying WH_CBT for the hook ID parameter. The hook callback function will provide you a handle to the MessageBox window, which you can then use to close it.
If you know exactly when to expect the MessageBox is being created and shown, then you can adopt a lighter and simpler approach than a global hook. This would involve calling the FindWindowEx function to get a handle to the MessageBox window, which you can likewise use to close it.
Of course, to close it properly, you will need to know which type of MessageBox it is (that is, which of the standard button choices that it displays) so that you can simulate a click of the desired button. Simply managing to get the MessageBox to disappear off of the screen without providing a valid answer is highly likely to have unexpected results in terms of the library code.
It bears explicit mention that this is really bad behavior on the part of a DLL. Unless absolutely necessary, ditch whatever 3rd party that is foisting such poorly written code upon you. If it is absolutely necessary, well then that's a red flag: work hard to eliminate it as a necessity. You shouldn't have to write and maintain gobs of code to work around their inability to get the big obvious things right.
I'm currently using SetWindowsHookEx to inject my DLL into another process, however it does not get loaded right away. I noticed that if I manually click the window, it will get loaded then, so I'm guessing it is waiting for some type of message to get the activation rolling? I'm currently getting it activated with a
SetForegroundWindow(otherAppHwnd);
SetForegroundWindow(myAppHwnd);
But this seems like a hack, and doesn't always work (i.e. the otherAppHwnd is minimized to the taskbar.
Any pointers would be great!
Edit: It is a CBT Hook
I've successfully used this:
SendMessage(otherAppHwnd, WM_NULL, 0, 0);
to achieve what you want, but only with lower-level hooks like WH_GETMESSAGE, never a CBT hook. It might work. 8-)
It seems that this is not possible.
So instead of forcing my way around this, I decided to just roll with it and make my design be able to handle this.
I'm writing a DLL that is automatically injected on load in a specific application. Because I'd like to run the program while working on it, and my users might want to load the program without it in specific cases (e.g. bug hunting), I sometimes want to prevent loading the DLL.
Currently I do this by checking GetKeyState for VK_LCONTROL, VK_LSHIFT , and VK_LMENU on load, and if all are down, I silently unload myself.
However, it can take quite a few seconds for the program to load and to see if the DLL was loaded or not, so I want to inform the users when we're unloading. I've considered a MessageBox, but that's too disruptive. I've tried MessageBeep, but that didn't seem to do anything on my setup. Currently I'm using a simple dual beep (Beep, Sleep, Beep) to indicate unloading, but that will probably become rather annoying to my co workers. I've also considered a system-tray icon, but that would introduce a lot of code and bug potential, while I'm aiming for a minimal notification as to not introduce any subtle bugs.
Would anyone else know a subtle way (preferably visual) to inform the user that their input has been succesfully received?
Given the limited scope of your goal, this might actually be an appropriate use of a taskbar notification balloon tip.
Edit: Added link the Joe posted in his concurring answer. Thanks, Joe! :)
If your app has a status bar at the bottom, you could place some message text there...
Have you considered a timed messagebox that closes itself?
http://www.codeguru.com/cpp/misc/misc/messageboxhandling/article.php/c203
You could open a window with a short message and close it automatically again after 0.5 seconds or so. It doesn't need user interaction so I don't think it's very disruptive.
Change the window title, then change it back afterwards. Then you can see the change even if the user has Alt-Tabbed over to some other program in the meanwhile, without stealing the focus from the user.
Concur with Greg D.
Look here: http://social.msdn.microsoft.com/Forums/en-US/vclanguage/thread/15cbdc8d-fde3-44ab-bbbc-e50cb2071674/
Two ideas:
Turn it around. Have a visual indication when the DLL is loaded, and have the absence of the indicator let you know that the DLL has been unloaded. Perhaps a suffix in the title bar. That way, you can tell at any time, not just during startup.
FlashWindowEx.