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.
Related
I need a context menu entry for each program in the taskbar. Want to add an entry which immediately terminates (UNIX/Linux-like signal SIGKILL) the process. There a lot of questions on this site, how it's done for the explorer or desktop. But is it also possible to add such an option to the context menu of the taskbar?
To clarify the question, according to my comments:
The current problem:
I have a program (not Firefox) which randomly crashes. The program is in fullscreen mode. But if I want to close the window of the program with Exit window, it takes a long time that Windows kill the program. When I try to open the Task Manager the program immediately grabs the user input and I have no chance to interact with the Task Manager. So my solution was to add a context menu item in the taskbar to quit the task of the program. According to a user comment, I test the option "Always on top" in the Task Manager. Didn't know that. But I haven't tried it yet. I'm also interested for further projects, if there is a function in WINAPI or Windows Registry to add an item.
To avoid down-votes:
I'm not interested to hack Windows or the application. Solutions with code injection are taboo for me. Want a clean solution, if even possible. I want improve my Windows version. Adding also some additional information (process information) in the context menu.
Have currently found this (Registering shell extension handlers).
Has anybody used this before? I think it's sound promising.
There is no API to extend this menu like that. Applications can customize the top of the menu with ICustomDestinationList but there is no way to add entries for all applications.
For a personal use project, you could inject a .dll in the taskbar instance of Explorer.exe and add your item after figuring out the address of the function where the menu is created. This address can of course change after you upgrade Windows so it is not a very generic solution. Using the public symbols might help but you still have to expect it to break from time to time when Microsoft changes part of their taskbar code.
You don't need to change code in explorer.exe, because you can close a program by doing the keyboard shortcut: Alt + F4.
I need to make multiple enable/disable changes to a main menu in a C++ Builder VCL application.
When the application changes state, I loop through disabling and enabling visibility of multiple menus.
This issue I have is that when looping occasionally during the loop there are more menus visible than what will fit on the screen, causing a wrap, which then causes everything on the main form to resize, and resize back resulting in slowness and a huge flicker.
I have tried the Disable and Enable align on the main form, doesn't have any impact.
I have done the WM_SETREDRAW trick on the main form, however while it stops it drawing, calling invalidate afterwards, doesn't get some of the children controls to redraw correctly. An example of what won't redraw is the tabs on a TPageControl.
An other point that may be of relevance, is that code is called from a TTabSheet::OnShow callback.
Ideally I would like to find a BeginUpdateMainMenu and EndUpdateMainMenu method, however I can't find on in the VCL documentation or the Win32 documentation.
Any help is much appreciated. Thanks.
This is not a technical answer but I'm thinking from an end user "useablilty" point of view : how easy would it be for him/her to use "more menus visible than what will fit on the screen"
Do you have the possibility to group the menu items in some way so that they could be dysplayed in sub-menus ?
I am maintaining I big and mature application, without background on MFC paradigm and layout. I have experience with Qt, OO designs and UI frameworks (I'm aware of each thread responsibility, event loops, event handling hierarchies, etc.
I'm stuck with a settings CDialog window losing focus constantly, while I'm trying to configure my application. I also have a file explorer dialog that behaves exactly the same way. Both are activated by DoModal calls.
I've read that this is probably because I have two modal dialogs competing for focus. How can I debug that? What function could I break on to get a helpful callstack, so I can find the offending code? Is there an MFC::focusWindow(WHND window) or something that I could intercept?
The problem according to your description is that you 'have two modal dialogs competing for focus'. This should normally not be possible because by definition a modal dialog takes over the application and does not return control to its launch point until the dialog is closed. Without knowing the architecture of the application, the simplest solution would be to make the settings dialog modeless (create it then call ShowWindow(SW_SHOW) instead of DoModal. This will allow the message loop to run for the other modal dialog but not take focus from your settings dialog unless it is doing it explicitly in its own methods.
Use Spy++ to spy the messages/events that occurring in the dialog.
You can use SetFocus function, please refer to
http://msdn.microsoft.com/en-us/library/windows/desktop/ms646312%28v=vs.85%29.aspx
I always been interested on how we can accomplish this (hide/show the main menu using the alt key), and now some applications do this very often. One that really please me is the visual studio 2010 with this plugin:
http://visualstudiogallery.msdn.microsoft.com/bdbcffca-32a6-4034-8e89-c31b86ad4813?SRC=VSIDE
(firefox also do this, but i think that is in a different way)
Can anyone explain me how this can be achieved or if you known of any sample project that demonstrate this please tell me.
(what i can see in some replies here in stack is that we have to destroy the menu when is to hide and create it when is to show?! but this seems a bit bad solution...)
Thanks
The SetMenu function lets you add/remove the menu from the window. It does not destroy the menu.
Note that most applications which have the dynamic menu hide/show behavior are not really showing a menu. They're showing a custom control that looks like a menu.
You might also take a look at MFC support for auto hiding menus. I used this technique and it worked really well.
in CMainFrame::OnCreate I did
m_wndMenuBar.ShowWindow(SW_HIDE);
which actually works fine in our project
I stumbled across a related pit fall that will show a hidden main frame without your consent:
Whenever the focus for a child window in an MDI application changes (e.g. due to right clicking in it), the function CMDIChildWnd::OnMDIActivate will be called, which in turn shows the main menu (even if it was removed or destroyed previously) of the MDI application.
This works basically by adding the saved main manu from the underlying's CMDIChildWnd m_hMenuShared variable.
A quick&dirty hack to prevent this, is setting m_hMenuShared to NULL (it's protected in CMDIChildWnd so this needs a custom derived child class of CMDIChildWnd) for all child frames.
I've been working on an input event system.
I mapped all the keys on my own keyboard, the scancodes and so on, including both windows keys.
When I press them, the program successfully receives the distinct keydown events for them without any trouble.
When I release the keys, however, the Start Menu pops up, obscuring the program in windows mode, or even minimizing it in fullscreen.
So my problem lies in suppressing that.
Arma 2, a Military Simulator/Game allows commands to be mapped on those keys without any trouble.
Where do I have to catch that event?
Can I do it for my own window as long as it has focus?
Am I going to be stuck with a disabled win-key as long as it is running?
Or something else?
Googling it was mainly fruitless due to Windows key also referring to the product key, and when I did find something, it usually flat out disabled the whole button.
I just want to suppress the popup.
Edit:
I tried
case WM_SYSCOMMAND:
switch(wParam)
{
case SC_TASKLIST:
return 0;
default:
break;
}
But that gave me very odd results.
If I spammed the winkeys and only the winkeys, it seemed to work, as soon as I moved the mouse while doing so, it didn't, the start menu would pop up again.
Edit:
I also tried hooks, but on win7 they get removed if the callback takes too much time, which can happen when large data is loaded, so they suggest a dedicated thread for it, but I think that's overkill for just one key that needs handled.
I just want to know where the Start Menu gets called. My own program? The system?
This is so friggin annoying, I am contemplating trying to reach the people from Bohemia Interactive and ask them how they did it.
Just this one key, sheesh Microsoft...even with "Super key/superkey" search terms, I usually only get flat out disabling methods, from registry changes to third party background programs.
Bah!
This artcile was relating to C# but may point you in the right direction;
From MSDN:
A global hook monitors messages for all threads in the same desktop as
the calling thread. A thread-specific hook monitors messages for only
an individual thread. A global hook procedure can be called in the
context of any application in the same desktop as the calling thread,
so the procedure must be in a separate DLL module. A thread-specific
hook procedure is called only in the context of the associated thread.
This was the most helpful link in order to answer the question in the above article
The Raw Input API should solve your problem.
http://msdn.microsoft.com/en-us/library/ms645543.aspx