start menu's item can be executed single-click,
explorer's item can be executed double-click or right-click and (O)pen.
like this, Windows UI is many execution method.
I want to know execution through UI(like item double-click).
How to know that?
I try to use UI Automation. but focus change is Too late and sometimes executed without focus change.
so I want certain method.
The assumption.
UI to kernel execution message.
Can I get it?
And other method is exist?
Related
Gtk 3.0 application (with C++ and GtkMM). I use set_menubar() to set the menu bar for the main window (loaded from a resource file, i.e. a "*.ui" XML file).
At run time, I want to be able to enable/disable (gray out) menu items in accordance with availability. I know that I can use "add_action()" and "remove_action()" to associate/dissociate the actions, which will have the desired effect. However it is complicated and expensive to add/remove the actions dynamically considering that the only time it matters which actions are available is when the user has opened the menu and is looking at it.
So I was thinking that I should be able to connect to an "activate" signal of the menu bar items to adjust the appearance of their menu each time the user clicks on an item, just before the corresponding menu is displayed to the user. Any idea how I can get to the signal from the Gio::Menu resource? Is this possible in theory but an unfortunate omission in the Glib API? Or is there something I don't understand?
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 have an existing (legacy) SDI app, and I want to call some functions immediately after the UI is shown, i.e. when it would normally sit idle and wait for user input.
Normally I'd put the calls in CView::OnInitialUpdate, e.g.:
CMyView::OnInitialUpdate()
{
CView::OnInitialUpdate();
//...
LoadStartupData(); //<-- this is what I want to call
}
... but this gets executed before the UI is shown. For this I want to show some UI feedback while it runs (it takes a while and should probably be in its own thread, but that's a different problem); the function also shows a dialog at the end of it, so I do need the UI to be visible.
What's the "best practice" on how to do this?
Use PostMessage in your init code with a WM_APP+x message.
When the message pump runs your message is delivered to the window and you can do your lazy init.
Use a ON_MESSAGE(MY_WM_APP_INIT,OnMyInit) entry in the message map.
Other way would be to use CWinApp::OnIdle, but this isn't view specific.
Or use a "one time" Timer... start a timer handle it and kill it.
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 stack of images on which I want to perform some operations. After processing each image, my program should pop up a dialog to prompt the user if they want to proceed with the next image or to abort. Before that, they should have an opportunity to do some manual changes either on the images or on the parameters. Anyway, they must have access to the windows of the applications, while the execution of the method that called the dialog should be blocked until the dialog is closed.
I tried to solve this with a QMessageBox, but if I open it via exec(), it blocks the entire application, and if I use show(), the execution of the program goes on without waiting for user's reaction.
Is there a convenient way to block the calling method or function with a dialog but permit the user to interact with other windows?
Thanks in advance for any hint.
You should split your method that you want to block into two parts. In the end of first part you need to show your dialog without blocking and connect "Next" button (for example) of the dialog to the slot that must contains second part of your old method. This slot will be executed only when user presses the button.
It's the right way to do it in Qt. You need posibly to change your code logic to implement this.
Also, do you really need the second dialog? You can place "Next" button to your main widget. You can also create another modal dialog that will contain some settings and "Next" button.