I am instantiating a local COM server using CoCreateInstance. Sometimes the application providing the server takes a long time to start. When this happens, Windows pops a dialog box like this:
Server Busy
The action cannot be completed because the other program is busy. Choose 'Switch To' to activate the busy program and correct the problem.
[Switch To...] [Retry] [Cancel]
I have found mention of a Visual Basic property on the Application object, OleRequestPendingTimeout, that can be used to control the time before this dialog comes up. I can't find any good documentation on this or an equivalent that is useful from C++. Can anyone point me in the right direction?
If you're using MFC, we used to do stuff like this:
// prevent the damned "Server Busy" dialog.
AfxOleGetMessageFilter()->EnableBusyDialog(0);
AfxOleGetMessageFilter()->EnableNotRespondingDialog(0);
Have a look at IMessageFilter and CoRegisterMessageFilter.
To increase timeout call:
AfxOleGetMessageFilter()->SetMessagePendingDelay(nTimeout);
See details here How to prevent the OLE Server Busy dialog box from appearing during a lengthy COM operation
Related
I have a MFC application (Visual Studio 2010) which dynamically creates and destroys lots of editboxes, drop-down boxes, and buttons, based on the user's consequent input.
I used "Create" function to dynamically create controls, and when deleting controls the system first calls "DestoryWindow" function for each control, and then delete each control pointer.
After iterating certain amount of creating/deleting controls, if I try to "open" the dropdown menu, the system fails to open it and stops responding to my input - but I can add more controls, if I do not try to open the dropdown menu.
Could somebody please let me know how to workaround this strange issue? This one nearly drives me crazy...
Workaround is simple - don't try to "open" that menu :)
Now I assume that you want to FIX the issue. Then you need to figure out what is going on. The system may be non-responsive for multiple reasons, most likely one of these two:
You are in a busy loop in your main UI thread.
You are waiting for an event that never happens. Deadlock, for example.
When your application is frozen, try to attach debugger to it and do Debug -> Break All. Then see what code is executing. If the reason for this "freeze" will not be obvious, please post relevant code.
I have a C++ software based on MFC (CDialog). When it starts it is always requesting for focus, mean it is blinking in the windows task bar.
The issue is that task bar is suppose to be set in out hide mode (because I have some other UI that are supposed to cover the full screen). But since this software always request focus, windows task bar never hide until I show and hide this piece of software...
I have other MFC softwares that do not have this behaviour but so far I cannot find out what could be the difference !
If someone had a idea that would be nice !
Thanks in advance.
Looks like I am doing some progress...
If I had ShowWindow(SW_SHOWNORMAL); just before the return of the OnInitDialog() function, then I don't get this behaviour anymore.
That is of course not perferct because I would like this application to be minimized and silent at startup, but when I try ShowWindow with other agrument I always get this flashing issue back...
Any other ideas are welcome ! Thanks.
I've got a Windows 7 VM which runs my mandatory corporate communication systems (Lync and Outlook). What I'd like to do is run a process on this Windows machine which monitors the system tray and sends notifications to my host machine (Xubuntu 13.04) so I'm informed when I get an email or IM (I've already tried seamless RDP to do this but it's an ineffective solution).
Anything Linux or network oriented I can handle with relative ease, what I do not know how to do is to how to query the state of the Windows system tray (or attach an event listener for state changes). I'm comfortable with C++ and Python but I'll give any viable solution a go.
Detailed state information would be preferable but at the very minimum I need to be able to detect changes in the number of icons in the tray.
On Windows, if you install Visual Studio, among Visual Studio Tools there is a useful tool, named "Spy++", basically it's a tool that shows you all the windows and gives ability to see what messages particular window receives.
Using this tool, you can see that whole panel, that contains "Start button", shortcuts, tray, clock, etc. is "Shell_TrayWnd". You can use "Find" menu to search for a particular window just dragging an "aim" on any window.
The tray window itself is "SysPager" (000100D2 on attached image), you can log messages for this window and see what type of message this window receives when you receive mail in Outlook.
After that you can write a code that will listen to all messages that this window receives, and basing on what you have seen in "Spy++" determine what happened.
This is just for start. Writing a code that will get a window handle and listen to messages that window receives is another part, but I think it's already covered at MSDN or even at StackOverflow.
Searching for a particular window handle is done by FindWindowEx function and in order to listen to message you have to set a "hook" that is done by SetWindowsHookEx function. Hooking is described pretty good on MSDN.
may be you need Outlook inspector (http://msdn.microsoft.com/en-us/library/office/ff869356(v=office.15).aspx). As i understand it helps to watch events outlook processes.
I have a game TicTacToe which was created in MFC with document/view architecture and I have server (standart console application) witn winsockets. Where I should initialize socket in client to connect it with server? (It must be exactly winsock, without Csocket). I know how to create winsockets, but I don't know WHERE I must create them in doc/view architecture. (The only I know is to initialize "WSADATA wsaData" in "InitInstance")
It depends on your program design. If you utilised the whole Document/View architecture you would had document's File->Open / File->New / File->Save handlers. So, it seems right to put the communication code there.
However, if the Document is just a "dummy" class that was created by the Wizard, but never used, with all the code put in the View, then you can continue to enhance the program the same way. Put the "connection" part in your OnInitialUpdate method, and the disconnection part into WM_CLOSE handler.
It is probably a good idea to provide the user with "Connect" option (either via a Menu or Toolbar option, or both). Then put the code there
I have a third party encryption library, which may create a MessageBox if key creation fails. The failure can be caused by bad random number generation or other rarities, and in most cases, trying again will result in success. My code will attempt key creation up to three times before deciding it failed.
Now, the issue is that the program may be used with automation. If a MessageBox is created during automation, it will block the process forever, because there's nobody to click the 'OK' button.
Does anyone know of a way to catch when this message box is created and automatically close it?
Anything is fair game, as long as it's not something that will make security suites angry. This means no hooking or code tunneling.
In summary, I need to catch when a MessageBox is created and close it. The MessageBox's creation is outside of my control. Modifying the code at runtime is not acceptable.
Also, I've noticed there are some other similar questions, but they don't have the same requirements.
EDIT: Additional note, I can find the message box via searching through all windows until I find one with a matching title and then send it a WM_CLOSE message, but I don't think this is a great solution. I also have no guarantee that the message box has been/will be displayed, or how long after my call it will be displayed. It could display instantly, it could display 1200 ms later, or it could not display at all.
Just before you begin the encryption process, install a WH_CBT hook, and in its callback watch for an nCode of HCBT_CREATEWND. If you get a matching class name ('#32770 (Dialog)' ?) and a matching title either return a nonzero value from the callback, or if that doesn't work post a WM_CLOSE (or a BM_CLICK to a relevant button if selecting an option is necessary). Uninstall the hook after the process for not messing with every possible dialog your application pops up.
That sounds like bad design on the part of that library. Generally any sort of utility library (like encryption) has no business invoking any kind of GUI (unless you explicitly ask it to).
Is there possibly some configuration or setting in this library that could disable its use of message boxes?
If not, I'd suggest that you might want to investigate using a different library. After all, if the designers of this library have already made this kind of poor design decision once, then there may be other unfortunate surprises lurking in there.
You can hope that it will be found by GetForegroundWindow, but this may catch other applications. The more brute force way is to iterate over all windows with EnumWindows looking for something that has a caption or text equal to this shown by the library.
I have once "remote controlled" an application by sending mouse click events to some controls. I guess you would have to do this in a separate thread that is watching for Events if a window is opened. Pretty ugly but working...
Create a new thread. If your function fails and a Message Box is opened, obtain a handle to the message box by looping through the windows (GetTopWindow, GetNextWindow) and comparing the window's process id to the one returned from GetCurrentProcessId().
Or, you can avoid all the hard work and just hook the MessageBox API with detours. It's not very hard, and if you don't want to pay for detours, you can do it manually.
Call VirtualProtect and set the memory protection at MessageBox at PAGE_EXECUTE_READWRITE
Create a naked function, and use it as a trampoline.
Create a function identical in parameters to MessageBox (this will be your hook)
Create a jump from MessageBox to your hook function.