Using Win32 API to interact with MenuStrip

MattNorman

Well-known member
Joined
May 22, 2021
Messages
98
Programming Experience
1-3
I am working on an app that currently interacts with a third party app using a combination of methods to export data.

My current setup is reliant on mouse and keyboard input which is going to become a problem if running my app on a server that will lock the screen.

I am looking in to possible workarounds to get the data exported without relying on mouse and keyboard input so that it can run on a locked server.

I've done some reading and understand that the menu strip is likely a child of the desktop window once opened.

The issue I am having is how I go about clicking the menustrip edit button and then it's child menuitem.

In Spy++ if I search the menustrip it gives out the class and caption for the window directly. It doesn't show the menustrip or it's top level buttons as their own entities and as such I cannot get any control ID's.

Does anyone have any pointers they can share?


Capture.PNG
 
If it were a regular Windows menu, you would send the WM_COMMAND with the WPARAM and/or LPARAM carrying the appropriate menu ids and parameters.

If it's a custom menu strip, who knows what their strategy for accepting inputs and converting them into messages looks like, and if it'll even work with a locked Windows desktop screen.

If it's a relatively modern custom menu strip, they may have followed some of Microsoft's recommendations for making their menus accessible to people with disabilities. Unfortunately, MS has gone through multiple iterations of it's accessibility APIs so you'll have to do the research on which ones may be appropriate for that era of code, as well as, do some probing of the app to see if it responds.

As a quick aside, have you considered using AutoHotkey?
 
If it were a regular Windows menu, you would send the WM_COMMAND with the WPARAM and/or LPARAM carrying the appropriate menu ids and parameters.

If it's a custom menu strip, who knows what their strategy for accepting inputs and converting them into messages looks like, and if it'll even work with a locked Windows desktop screen.

If it's a relatively modern custom menu strip, they may have followed some of Microsoft's recommendations for making their menus accessible to people with disabilities. Unfortunately, MS has gone through multiple iterations of it's accessibility APIs so you'll have to do the research on which ones may be appropriate for that era of code, as well as, do some probing of the app to see if it responds.

As a quick aside, have you considered using AutoHotkey?
Thanks for the info.

I have managed to get the majority of this working now including selecting the menu item and then updating radio buttons, check boxes and combo boxes.

The issue I have now however is that I ended up having to use WindowFromPoint function to find some of the controls and this function is reliant on the screen being unlocked which is the opposite of what I need.

I haven;t looked into AutoHotKey so will have a read up on it.
 
I've also managed to get around using WindowFromPoint now with a combination of helper methods I created.

I have a helper method to enum child windows and look for the specified window caption.
I have another that does the same but for the window class.
The last then enums child windows looking for the specified class and control ID.

I had to use the third method for things like combo boxes as they had no caption and the class was the same so the only was to tell them apart was the control ID which I got using Spy++.

This all now seems to work fine with the screen locked.
 
Back
Top Bottom