i have work on an app that manipulate some application context menue to extend its functions, i have checked all the common posts here on stackOverFlow on how to manipulate the menu context using Windows api in C# using functions like GetMenu(...), InsertMenuItem(...), ShowOwnedPopups(...) and that comes in vain, here is the scenario, the application i wanna manipulate it context menu has many context menus in many parts but i want to manipulate certain one which belongs to the viewer part. so i have used spy++ to figure the the handle of the viewer and a send a message WM_CONTEXTMENU using SendMessage(...) function. the menu finally appears and i have its handle.
i guess after i get the handle it would be constant for the life time of the program for the single running time, but i figured out that the handle is changing every single time a i have clicked right click. and the parent of the context menu isn't the viewer area itself but the desktop that's was disappointing.
so i have two problems
1- i can't get the handle directly as using GetMenu(...) passing the handle of the viewer returns null, after some search if found that the context menu has a class name of "#32768" so i have filtered all the open windows to get the one that its class name equlas "#32768". and now i can access the handle from my c# code not from the spy. but here is an comming issue: if there is a sub menue.. it also have the same class and unfortunately this is totally logical :/
2- i can't get the context handle before it is shown and if it is shown, i can't manipulate it as i know. The second thing is that the context handle continuously changes every single time i right click the mouse. so i can't pass the first time i click then save the handle for the next clicks to make it work.
any suggestion are very welcomed.
First of all you should figure out if you can just send it a WM_COMMAND message to perform your command. A context menu might not use that message but if the application also has a normal menu then it is likely that it will handle the message. Note that the command id might change between program versions.
All Win32 HMENU menus use the same class and MN_GETHMENU is the only related documented message.
The recommended solution is to use UI Automation/MSAA to navigate the UI of other applications.
Related
I am making a custom OPC Client application in WPF to communicate with a Kepware server. One of the functions is to configure a tag, including setting it's host and server. Now I could do this manually with calls to the Kepware ClientAce API for searching for valid network hosts and valid servers on that host, but ClientAce includes a .dll that already provides a tree control the user can browse directly. However, this out of the box control is in Windows Forms.
So I have this WPF Window that I launch as Modal Dialog with ShowDialog(). Within this window is a WindowsFormsHost element that contains the aforementioned server browsing control. It's works pretty well for the most part, including providing an event to handle when the user has made a new selection in the tree control. That event has a boolean parameter that indicates if the new selection is a server. A good thing since that's the very thing I'm trying to keep track of here.
It also provides a "server has been double-clicked" event, which I handle and have decided to interpret as a shortcut to the user selecting that server as the one they want. (Otherwise, they have to click a separate button for the currently selected server which I stored based on the aforementioned selection event.)
All good so far....
...But! There is another functionality Kepware added (well actually there's a few, but I'm not worried about those at this point). The user has the ability from a context menu to delete a server from the tree. For some reason, this is throwing a null exception (though, it successfully deletes the server from the tree). This is a very bad thing for my purposes because...:
I don't have any idea what leads to this. There is no stack trace. There is no extra information. Just that something, somewhere in that control has thrown an unhandled exception that I must now deal with.
I can't remove the context menu item. There's another context menu item that I can set a property in the XAML to remove, but that one isn't throwing the exception. It's the one I can't remove that is.
There's a lovely event called "ContextMenuItemClicked". It'd be nice if I could handle that. I just go into my handler, put a try/catch around the logic, and ignore the null exception that has absolutely nothing to do with me and what I'm trying to accomplish. However, the universe is against me here, and has decided that this is a mouse-click event, which Windows Forms doesn't want to propogate. I've searched around and this seems to be a common issue with Windows Forms and WPF interop. Mouse-clicks just don't play nice with the interop services. I tried. I really did. But the handler I made just sits there unused. Odd thing is, while I can understand why I can handle the "SelectionChanged" event from this control, I'm curious as to what Kepware did to make the "ServerDoubleClick" event propogate up, and why they didn't decide to extend that same courtesy to the context menu click.
So there I am. With an exception that isn't my fault, that I don't care about, and I apparently can't prevent. I just want to throw it away and move on. However, it's in a modal dialog, and I need to have this exception handled before the method that called ShowDialog() and popped this window up in the first place. (I'll spare you the details as to why. This post is long-winded enough as it is.)
Is there a way I can either somehow propogate the mouse events up, or trap this exception somewhere in my window class so that it doesn't propagate up the stack into the calling method?
I have an application that contains multiple MemoEdit controls containing DevExpress spell checkers. When a user updates the Options (through a MemoEdit's context menu), we are saving those options to our db. Is there any built-in way to broadcast those new options to all spell checkers in the application? It's probably worth noting that some of the MemoEdits are used in Interop controls in the VB6 "part" of our application.
Right now I'm using events, but things aren't working out as well as I'd hoped and before I get too deeply into rolling my own fix I figured I'd ask the SO folks.
Thanks in advance for any tips.
My tech lead and I just acquired dev express subscription for a win forms application we are building and we are using the spellchecker and saving the options to our sql server ce table. We have multiple forms with one spellchecker each tied to one memo edit control per form.
I programmed a single reusable function named “GetSpellCheckerOptions” which returns type “DevExpress.ExtraSpellChecker.OptionsSpelling” that loads the six options from the spell check options dialog form from our sql server ce table. This function is invoked in a form’s constructor where the form has the spellchecker component associated to it and this can be any form in our application. It is built around an “on-demand” basis as opposed to loading it in memory and keeping it around for the lifetime of the application because the notes or comments being written by our users are on forms that load, fill it out and close.
You can use the event called OptionsChanged which is a member of the type “DevExpress.ExtraSpellChecker.OptionsSpelling”. You will have hook up the event in runtime using a subroutine you write like this for example:
jobsSpellChecker.OptionsSpelling.OptionChanged += new EventHandler(this.jobsSpellChecker_OptionChanged);
When a user changes an option on the spell check options dialog this event will fire, however there are some gotchas to be aware of. When the event fires you will not know which option fired the event because the Event Argument does not provide that information. So I save as a whole save regardless of which options were changed. The save occurs after the OK button is clicked as opposed per option being changed. The biggest gotcha is that this event fires three times. Two of those three times is from something totally unrelated to changing an option. So to control the two unneed event fires you need an if statement evaluating the options form dialog result, like this for example,
if(jobsSpellChecker.FormsManager.OptionsForm.DialogResult == System.Windows.Forms.DialogResult.OK)
This will protect your save code from being executed needlessly. In addition without the “if” statement the control has a nasty way of remembering previous state of what the options were before you changed them and during those unneeded two of three event fires, it changes your options setting from the new desired settings back to previous state or settings. Very annoying and it has taken the whole day to get past these obstacles and more experimenting with these controls. Hopefully this information can offer you or someone else a value that will save time, avoid potential frustration and endless browsing product support pages.
I am working on a application, which would be the face of lot of other tools running in background. I am facing an issue. During the launch of a background application ,it needs to load a specific file(file-->load--> file name).
Let the front end application be Fapp and the background application be Bapp. Is it possible for Fapp to get the handle of Bapp's menu item and trigger the load function. I am able to get the handle for buttons but not able to do the same for menu items.
Now we are achieving this using AutoIt, I am trying to achieve this in C# itself.
After you have obtained the handle of the window that you want to invoke its menus, then you may use
HMENU GetMenu(HWND) windows api to get menu
HMENU GetSubMenu(HMENU, int) to get to the file menu and again to open menu.
BOOL GetMenuItemInfo( ... ) to get info about menu
and you can use PostMessage((IntPtr)hWnd, WM_COMMAND, 0, ID_MENU_ITEM); (related post) to perform a click on that item.
all these apis are what AutoIt calls (I think). This solution works if your Bapp is a normal windows application with a normal windows menu, not a fancy WPF app, or a ribbon. If this is the case, then what you see as menu probably is not a menu (technically anyway)
Are you sure this is the right way to get two applications talking to each other?
If you don't have source code for BApp, and it also doesn't have an API that you can use, then pretending to be an interactive user could be the only way to interact with it. Just be aware that it is fraught with issues, consider what will happen when
BApp isn't already running
BApp has a modal dialog open
BApp is in the middle of an operation (or hanging) and its menu is disabled
BApp is updated to a new version and its UI changes
An interactive user changes focus, in the middle of an operation.
An alternative to this would be to do the same thing that you do when you are unit testing an application with a UI. This is because you are doing the same thing, automating an application by making calls that execute its functions, in this case to test the results are as expected. Since this is a WPF post lets assume that you are writing an application with MVVM, and the best way (to avoid brittleness when we are change the UI) is to ignore the UI (View) and call the layer that sits underneath i.e. the VM (ViewModel).
In fact its quite easy just to add a self-hosted WCF connection inside your BApp application so that it can be called externally.
this._host = new ServiceHost(service);
this._host.AddServiceEndpoint(typeof(IContract), new NetTcpBinding(), address);
this._host.Open();
This would then enable you to get the two talking totally independently.
If your Bapp is able to somehow invoke Win32 API - then this can be achieved by sending a custom WM_USER message to your Fapp - using SendMessage(). In your Fapp you handle this message and take appropriate action.
I don't think getting handle to a control and invoking its handler is the right way.
This may be a long short or not even possible but no harm in asking.
What I am trying to do is monitor an application for any new windows it creates in its MDI control. I have implemented hooking in C# and can capture the MDICREATE window message but because I need to get information about the window after is has been created the MDICREATE message isn't much help because at that stage the window hasn't been created in the other application yet.
Without going into to much detail I just need to be able to see when a new window has been created.
Is this possible?
Thanks
I'm not aware of another message that gets the info that you are looking for off hand. But if that message works for you, you could hook that message and then do another scan of the windows to find the one you are missing. You can enumerate the child windows of the parent window. Use Spy++ to see the exact window hierarchy.
If you can watch for a particular function call, I would use some kind of hooking library to grab that (EasyHook comes to mind).
You can hook the MDI create function (assuming there is one), watch for that, then inn your code, call the original and do any lookups using the returned value. You'll have access to the returned value and any parameters, so you should be able to get some info out of those.
Two options off the top of my head.
Hook the WM_MDIACTIVATE event, the first time the window is being activated, use a flag to determine the first time the window is being activated.
If you need to run your code after the WM_MDICREATE or WM_MDIACTIVATE, you can post a new custom message from one of these messages, which is then handled after these messages have completed. You then write your code to handle the custom message.
I am (still) writing a small application which requires me to use several windows forms to show to the user.
Some of the forms just show progress messages while the application performs tests using several external devices.
The forms will usually be used in order (see below) but there may be some errors picked up from the devices, in which case an Error Reporting form will be used. The user will have the option to go back to the beginning or to the 2nd test (the 1st test takes 30 mins to perform). The error report can be invoked from any other form.
Also, the final form has the option to go back to the beginning to perform the tests on a new device.
Obviously this would cause the suite of forms to get rather tangled up. if it were used for several devices with errors etc.
So am I have a few questions.
Am I using the forms correctly and if so, how do I pass control from one form to the next one without having to go back to the original form, if that makes sense ?
Can I still have access to all variables created in preceding forms, or should I create all the variables in the initial form setup ?
Or should I have all the processing within one parent form and simply "show" the other forms as part of the procedure ?
I hope this doesn't sound too stupid, but I havent used multiple forms in C# yet. The steps are ALSO dependent on each other.
The following is the usual flowchart of forms, with PRGERREP being called from any form (more or less).
PRGSTART
PRGDEFAULT
PRGTEST1
PRGTEST2
PRGTEST3
PRGTEST4
PRGMANUAL
PRGFINALE
PRGERREP
Any help or advice would be most appreciated.
Please try to focus more on the question, not the context.
Even though i don't know exactly what you want, you should check out MDI Applications.
Basically you have a parent form with several child forms. Should your tests be finished you can BringToFront() the corresponding child window from the parent form.
I question the requirement to use multiple forms for this. Most applications show all information for a task; progress, tests, errors, messages, et al. in a single window, not multiple windows. Web browsers and office applications are very complex programs and manage to show all task information in a single window.
The fact that you are trying to "pass control" between multiple forms makes me suspect using multiple windows is a bad design. Look at the windows on your screen now; each one is a self-contained environment and does not need to "pass control" between each other.
If you are trying to make the user do something in sequence, handling errors before going on to the next step and allowing the user to "go back to the beginning", a wizard-like design may be better.
Create a single form with fields and buttons for the first task. Clicking a button redraws the form with fields and buttons for the next task, and buttons to go back or start over. This can be done more easily than creating a bunch of separate forms and trying to synchronize data between them.
Consider inheriting from an ApplicationContext to implement this logic in your application. See here and here.