Suppressing "What do you want Windows to do?" message
-
I'm working on an app that allows the user to burn CD's, but if the user hasn't previously set up an action for the CD Drive's property for action on a blank CD, the "What do you want Windows to do?" window pops up. This message needs to be supressed of course. I have a working version of code, initially based off of a "service" article on MSDN (sorry don't have the link), that basically just enumerates all desktop windows to find the title of the window, then enumerates the children of that window to find the "What do you want Windows to do?" message. Once it finds all this, then it closes the window. It does this enumeration every 1/4 second in a background thread, but only when needed (just when prompting the user for a disc) to minimize CPU impact. The window will flash up, but will be gone before the user knows what hit them. This can probably be done better using hooks, but I'm not quite there yet -- and what I've found so far makes me think they won't work much better overall (see the next paragraph). Anyway, the problem I'm having is that although this works, the application needs to be localized into around 8 different languages (possibly more, can't remember exactly off-hand), so looking for strings to go off of won't work very well, not to mention this code will break as soon as windows decides to change the text. Using normal hooking methods don't look any more promising for this, because I still need some way to figure out that it's the correct window being created. I'm thinking there's gotta be something simple I'm missing here. Any ideas? ----- In the land of the blind, the one eyed man is king.
-
I'm working on an app that allows the user to burn CD's, but if the user hasn't previously set up an action for the CD Drive's property for action on a blank CD, the "What do you want Windows to do?" window pops up. This message needs to be supressed of course. I have a working version of code, initially based off of a "service" article on MSDN (sorry don't have the link), that basically just enumerates all desktop windows to find the title of the window, then enumerates the children of that window to find the "What do you want Windows to do?" message. Once it finds all this, then it closes the window. It does this enumeration every 1/4 second in a background thread, but only when needed (just when prompting the user for a disc) to minimize CPU impact. The window will flash up, but will be gone before the user knows what hit them. This can probably be done better using hooks, but I'm not quite there yet -- and what I've found so far makes me think they won't work much better overall (see the next paragraph). Anyway, the problem I'm having is that although this works, the application needs to be localized into around 8 different languages (possibly more, can't remember exactly off-hand), so looking for strings to go off of won't work very well, not to mention this code will break as soon as windows decides to change the text. Using normal hooking methods don't look any more promising for this, because I still need some way to figure out that it's the correct window being created. I'm thinking there's gotta be something simple I'm missing here. Any ideas? ----- In the land of the blind, the one eyed man is king.
-
I bet that will work, but the following disclaimer has me a little worried: "Applications should not modify these values, as there is no way to reliably restore them to their original values." I don't see why there should be any problem restoring to the original settings though. ----- In the land of the blind, the one eyed man is king.
-
I bet that will work, but the following disclaimer has me a little worried: "Applications should not modify these values, as there is no way to reliably restore them to their original values." I don't see why there should be any problem restoring to the original settings though. ----- In the land of the blind, the one eyed man is king.
Ah, even better ... found exactly what I needed on MSDN after checking out that article (and knowing what to search for ... that is half the battle with MSDN) Enabling and Disabling AutoRun[^] Thanks a bunch! ----- In the land of the blind, the one eyed man is king.
-
I bet that will work, but the following disclaimer has me a little worried: "Applications should not modify these values, as there is no way to reliably restore them to their original values." I don't see why there should be any problem restoring to the original settings though. ----- In the land of the blind, the one eyed man is king.
Vineas wrote: I don't see why there should be any problem restoring to the original settings though. A user might change these settings themselves in the control panel or something. If you save the old value, it might not be up-to-data. Therefore if you restore those values, the user might lose their own settings... I wouldn't worry about that too much, since no user is going to change it every day and uninstall your software right after the change. You might list this "feature" as a known bug or something. Behind every great black man... ... is the police. - Conspiracy brother Blog[^]
-
Ah, even better ... found exactly what I needed on MSDN after checking out that article (and knowing what to search for ... that is half the battle with MSDN) Enabling and Disabling AutoRun[^] Thanks a bunch! ----- In the land of the blind, the one eyed man is king.
-
I bet that will work, but the following disclaimer has me a little worried: "Applications should not modify these values, as there is no way to reliably restore them to their original values." I don't see why there should be any problem restoring to the original settings though. ----- In the land of the blind, the one eyed man is king.
Yeah, as long as ANOTHER program does not change them to something else in the meantime. That is ALWAYS the problem. Then, by definition, you are not 'restoring' the original settings, whatever you write back.
-
Yeah, as long as ANOTHER program does not change them to something else in the meantime. That is ALWAYS the problem. Then, by definition, you are not 'restoring' the original settings, whatever you write back.
Turns out I didn't need to use the registry value anyway, the article at the link I put in earlier had a message that is sent to the top level window just before auto play is enacted. I ended up hooking this in a background thread whenever the CD burning dialogs are up, worked really well and didn't have to worry about messing up registry or a blocking AfxMessageBox call (one of the big problems I had once I figured out the message I needed to handle). Thanks again for all the help, the code project has been a constant source of help and inspiration. ----- In the land of the blind, the one eyed man is king.