AutoHotkey Community

In interest of "being neat", a response to Lexikos' post is here and leuallen follows.


I wrote this speil about how it could be done, but I just realized that such functionality would probably be counter-intuitive. Users don't expect the ability to drag within menus - they expect there to be another control (like ListView or TreeView) that allows them the ability to rearrange menu data - if the program allows it, that is. Therefore, I must withdrawl my idea, because I think that adding such functionality may cause more harm than good. Right now, you can programically insert menu items (via Menu_Insert), move items within the same menu (via Menu_Move), and move items to another menu (via Menu_MoveEx), so I believe, at least for now, that will be the extent of menu reordering from me.

I might (when I have free time) add the feature - just for fun, and because someone might find it interesting, but I have a project that I've been working on, and have diverted enough of my attention. Plus, I still have my ListView DnD (TreeView, and other controls pending) to focus on.


The problem with LVM_SETINSERTMARK is that it didn't work (out of the box) in WinXP and won't work in Win9x - this is what I tried. However, by using the Rectangle Function as the insert mark, I have ListView drag/drop already done; also, TreeView drag/drop is done (not uploaded yet, though). Right now, I'm working on multi-control drag support and organizing the code. I already know how I'm going to implement the muilt-control drop, I'm going to start on that today. You can check the current progress, here.


Before I make my request, I have to verify a few things.

1) When a menu item is deleted, would there be the ability to call a user-defined function for "cleanup"? Similarly, when deleting a menu?

2) I presume this, but ask anyway, when recreating the menu, would the associated data be "restored" with the menu creation.

3) Will you have the ability to reorder / insert menu items into the menu?
If not, then this menu wrapper will still need to be maintained, so could you keep me informed on what changes you make to the menu? Ex. if you add associated values, what cleanup (if any) of menu icons is necessary by this wrapper, etc. This way, I can provide one version of this wrapper for Chris' AHK build and another for yours.


4) Since the menu / menu item data might need to be manipulated after being added to the menu, can you add a function to get/set the associated data for a menu / menu item?

Because the Menu / MenuItem object may hold data which needs to be updated (which, for my needs at least, is the case), there would need to be a function to retrieve it. Also, there is the need to set the data. Let's say that the menu data is loaded from an ini file. The script would read the ini file, store the values in a Class object (either one the script programmer created or an existing one), and then when adding the menu item, would associate the object with the menu item - no problem. However, if the program allows loading another ini file - to allow switching of user settings without restarting, then setting the Menu / MenuItem object is required as well.

But, like you say, if the data is associated with the menu as well, then the menu wrapper already has functions to do this Menu_getMenuObject and Menu_getMenuItemObject. However, again, I must ask, will you verify that the two remained synced? For example, if when creating a menu item you can set the data (which would be awesome), the item would then be set in the AHK menu structure and the menu itself. What happens if you need to set the value after menu creation? If you set it on the menu, how would the AHK menu structure remained synced? Or would there be a way to tell AHK to change it internally?


Well, all I need is a uint value - 4 bytes for each Menu / MenuItem object; the initialization and storage of values is done through the Menu / MenuItem object functions. Since a class object can hold any data and any amount of data, and as demand for Class objects increases, the functionality of them will increase, I see no need to burden you with creating OOP when, thanks to your template, it has already been done.

_________________
As always, if you have any further questions, don't hesitate to ask.

Add OOP to your scripts via the Class Library. Check out my scripts.

I wrote a spiel, that I'm going to post shortly, that instructed how to do this. Instead of saying how to do it (in gorry detail), I'm going to add functions to the menu wrapper to do the work for you, and will then post steps to take to get whether the menu is checked. I will not, however, allow checking an item, because such use, in my opinion, is useless. The program shoud not respond to you checking an item - it would be foolish to do so. Instead, use the functionality I'm going to add, and programically select the item. This way, the program is sure to do its job.

Also, in this release, I'm going to add wrappers for all Menu functions that I can think of - leaving off stuff like checking menu items that I personally think could do more harm than good. Of course, checking if the item is clicked should be fine, and you can use that the result of such a check accordingly.

With these additions, will be the ability to programically select menu items that are outside of AHK. For example, I did a test run of my idea, and was able to create a new file in PSPad without moving the mouse or anything, but it still went, File -> New. This should be a nice addition to the library, thank you for for that.

As far as the listview, I'm not sure how much help I can be - I'm still giving it thought tho, but no promises.

For the mouse move, do you only need it to "click" menu items? If so, YEAH! This update will allow you to "click" a menu item without moving that stupid pinwheel of a mouse.

Update:
I got the newest additions working - just doing some final tests. I used Notepad in the test, and it seems that the WordWrap checkmark isn't updated until the menu is shown - does not have to be the Format menu shown. If this is the same problem you have, good, because hopefully the solution (assuming there is one) that works on notepad will work for you. Not sure who the idiot is that did it that way, but maybe they did it just to spite people like us - who knows

_________________
As always, if you have any further questions, don't hesitate to ask.

Add OOP to your scripts via the Class Library. Check out my scripts.

Same problem I have



I don't understand. Would not checking the menu item programically be the same as exposing the menu and checking it? Does not the program respond to checking the menu?

This would be great functionality for me. I have a filter command that can only be set by clicking a menu item or by clicking on a couple of icons that are displayed on the second monitor. I am getting very inconsistent results trying to click on the icon. Lightroom displays a second monitor, if available, by pressing a hot key. The second monitor display is acting strange. My attempts to click the icon, close the window on the second screen before the click. The metrics returned by ControlGetPosition are the same whether the the window is on the first or second screen. Coordmode seems to have no effect. I just can't get to the icon to click it. The icon by the way is a window, not a button. One window serves for three icons.



I can move the mouse to click no problem. But the mouse always returns to its starting position after the click. I put in a mousemove, x,y, 100 and I can see the cursor jumping up to the point, so it gets there.

The listview has a small preview image window above it. The listview lists a bunch of effects that can be applied to the image. As the mouse moves over each item in the list, the effect is displayed in the preview. I use a tablet with mouse and it is difficult to move the mouse over an item and keep it there without undo concentration. What I was hoping to do, is move the mouse over an item so that the effect is displayed and then move the mouse up/down via the keyboard so I could cycle through the effects without using the mouse.

As the mouse goes over an item, the item dimly highlights but not boldly as when it is selected. I can programmically send a click to an item to select it but that applies the effect to the main image which takes some time and must be undone, more time, if it is not the effect desired. I was wondering since I can find and click an item to select it, if there is not some method of selecting the item and getting the effect of the mouse hover. In other words making the listview think that the mouse is over an item.

Larry

Before I explain, let me appologize - I didn't mean to sound as rude as I might have come off; I only meant that there are problems with allowing checking a menu from an external source - such as the program thinking the item is checked when it is not (and visa-versa); this could introduce inconstencies. For example, checking the check box for word-wrap WILL NOT activate it - it will only put a check mark there.

Instead, I would suggest using the functionality I'm adding. The already included Menu_SelectMenuItem function is getting an upgrade. With the new functionality, you will be able to select a menu item from an external menu, an AHK menu (already supported), and AHK GUI menus. Does this solve your problem? No need to click the menu or hunt for it, if you can select the menu programically, right?

I'm going to run some more tests - make sure the functionality works as expected, and will probably upload it in an hour or two.

Since I have tried some things with no luck, I'm going to temporarily put aside trying the "fake a menu activatation" attempts. I think I could emulate a menu click by sending the right messages, but there are three or four messages sent when a menu item is clicked - so I'll need to study them a bit, and hopefully I can find a way to "trick" the menu into thinking it was clicked - so that it will update the values, no promises, not my area of expertise.

_________________
As always, if you have any further questions, don't hesitate to ask.

Add OOP to your scripts via the Class Library. Check out my scripts.

Since a menu item is only deleted specifically at the script's request, I don't think it would be necessary (especially if the script is using a wrapper function to delete items).
Can you think of intuitive syntax for associating data with a menu? I think it is less difficult to associate information with a menu name than with a menu item, and therefore is less important. When considering this, I realised it should also be possible to set the style of a menu. At the very least, MNS_CHECKORBMP should be the default...
If by "recreating the menu" you mean "causing the Win32 menu handle to be destroyed and recreated", it will not be an issue as it has no impact on AutoHotkey's menu data structures.
Perhaps down the track. Unlike this, "Dn" seems very simple to add.
Can do. Any changes I make will also appear in the AutoHotkey_L thread and version history.
None. A script may change or remove the icon explicitly, but AutoHotkey will automatically delete the icon when it is no longer needed.
Since Menu,,Add can be used to modify a menu item, it may also be used to set the associated data.
If you update the item data via Menu,,Add, it will happen one of two ways:

• No menu handle, so the data is stored only in the UserMenuItem structure. When the menu handle is created, the data is stored in dwItemData.
• A menu handle exists, so the data is stored in both directly.

This is very similar to how the item's hbmpItem must be updated when its icon is set, changed or removed.

Setting the item data via SetMenuItemInfo will not be supported (i.e. it will not remain in sync).
My point exactly.
Obviously third-party applications pulling information from the application's menus while they aren't visible were not a design consideration. Why should they be?

Actually, AutoHotkey does exactly the same with its tray menu (but not the File menu in the main window).
Like WinMenuSelectItem?

Ok, so it sounds like the added functionality and this wrapper will be more co-op than a replacement? This is out of personal curiosity, just trying to figure what I need to modify for the Lexikos version. So, deleting items will still need to be done through this wrapper, since each menu and menu item's data needs to be destroyed with the menu / item?


A function that returns the Menu data for a menu? Menu_getData(MenuName) - or something like that. Like NumPut/Get, but for menus. Since the menu must be created before data can be associated, and because it makes little sense to add menu data to a menu item add command, I think this works.

It's a similar problem with wanting to add submenus to a menu - you must first create the menu, then add the submenu. Or, do what I do, create an "empty" menu - add a separator, then use DeleteAll, and add the "empty" submenu. I use this if I need to add a submenu, but haven't created the submenu yet... it's the one downside to using a iterative versus "recursive" programming style (I'm talking about my programmin style here). I'm a top-down thinker - so I think more breadth-first than depth-first. So, I always create empty menus when I need to add them as submenus - I don't worry about creating the submenu first.

Similarly, whatever method you currently use when creating submenus, can be used to associate menu data. Either create an empty menu, add the menu data, and then add the items; or create the menu (by adding an item), then add the menu data - either way works.


I agree that associated data with a menu name is easier, but it gets messy - especially if you have many values - this is why I needed OOP to begin with. For example, for the project I'm working on, the menu stores several values that are used to identify it - granted far less than a menu items. Also, the problem is if the internal data structure doesn't have a spot for the menu object, then it will be lost when AHK recreates the menu. I would love to let AHK rebuild the menus in my wrapper, but if AHK doesn't restore all the data, then the wrapper will have to do it. For example, Menu,, [No]Standard needed a hack, because AHK would recreate the menu (and the menu / item data would be lost). Right now, using my menu wrapper, AHK has no clue if the menu has the standard menu. Instead, the code adds the standard items and removes them. This is necessary to retain the data the AHK can't restore (since its not part of the internal structure). So, bluntly, athough it's easier to associate data with a menu than a menu item, it cannot be seen as less important, because any data not being restored when AHK recreates the menus means the wrappers must be used to add data - because one of the values is if the menu has the standard items.


On a side note, that reminds me. Can you add a function to get the AHK label associated with the item? Right now, that data is stored with the item - so that the label is automatically retained when moving an item to a different menu (it's not needed when moving an item within the same menu). If you could add a command / function that returned the label, that would be awesome.



Yeah, that sounds great - I should add that to the wrapper as well, thanks.


Right, sorry, ignore that question. My mind was still thinking about menu and menu item objects needing to be part of AHK's menu data structures so that they will be restored. I meant to ask: will both menus and menu items have an associated value?


No, I get that. But this I don't get. Why when I click Word-wrap, does the checkmark not get put until the menu is shown again? I would think it be more intuitive to put the checkmark when you click on word wrap. This way, if someone wants to know whether word-wrap is one, they can check for themselves (by sending the right message).

I mean, internally there is a variable that stores if word-wrap is on - this is how the check mark gets updated when the menu is shown. Also, when you click word-wrap, that variable toggles. Why wouldn't they update the checkmark at this time as well? Instead, they update the checkmark when the menu is shown. This sounds like a waste of energy. To gain any efficiency, don't you have to keep track of what values to update? I presume you don't update them all to the current state - that sounds foolish - and a waste. Thus, if they know that word-wrap was changed, and only update when the menu is shown, this would suggest they are trying to save the call to the menu api to set the checkmark (in case the menu is never shown again). This sounds like a lot of work for something so inexpensive as a dll call.


lol, I never knew that even existed... The wrapper function won't be exactly like it, since it requires passing the menu handle, item handle (or position - or a comma delimited list of positions), and the window. In fact, like all AHK functions, WinMenuSelectItem is nicely done, and I feel like a fool for trying to add a function that already exists. Well, I'll still keep it around because it allows selecting items from an AHK menu (like the Tray menu). But, thanks for bring that function to my awareness.

_________________
As always, if you have any further questions, don't hesitate to ask.

Add OOP to your scripts via the Class Library. Check out my scripts.

Also, real quick, it's getting late, and my mind isn't as focused as I would like, so I'm going to wait to upload the latest version until tomorrow. This way, I don't have a small bug that I would otherwise catch if I could concentrate.

@leuallen, did you try the function, WinMenuSelectItem, that Lexikos thankfully brought to my attention, as a replacement for your "menu hunt"? This method would work better than the menu wrappers', because for it, you have to find the menu purely on index - not by name lik AHK provides.

_________________
As always, if you have any further questions, don't hesitate to ask.

Add OOP to your scripts via the Class Library. Check out my scripts.

Yes.
I see a few problems:

• Inconsistency with the existing AutoHotkey API's.
• If data can be associated with a menu, why not any arbitrary control, listview item, treeview item, etc.? (Inconsistency again.) AutoHotkey isn't OO.
• Rarity of use.
• Level of interest vs development time.

I have never understood why you must use the Win32 Menu API to store the data. You could identify the menu via its menu object, or associate the menu object with the menu name. Menu item objects can be stored in an array in the menu object. This is basically what AutoHotkey does:

• Script contains a linked list of UserMenu structures.
• Menus are identified by name; to find the UserMenu, simply search through the list for the one with the right Name.
• UserMenu contains a linked list of UserMenuItem structures.

I'll add it to my list.
Probably only menu items. As I mentioned, "Dn" seems very simple. By contrast, setting menu data or style would require new syntax.
You missed my point. Notepad is intended to be used, not automated. Your argument is only relevant if automation was a design consideration.
I would, but why should they?
Please, there are only two items, and 50% of them must be updated.
It is more likely that neither method deserved much thought, and the programmer went with whatever method seemed appropriate.

Yeah, I was afraid of that. I originally designed CDLL (Circularly-Doubly-linked list) to be the ideal solution for storing the menu data. The only reason I'm against it is the O(n) versus O(1) retrieval time (unless I store the link address with the menu, lol, then it's O(1) ). Maybe I need to grow out of it, but I prefer a "map" over a linked list any day. I usually map my values to give them a O(1) access time instead of O(n) - I would say that's one of the reasons. The second, I don't like forcing people to include a new data structure. Granted, the user never sees the CDLL at work (they just need a copy of CDLL.ahk), and if you are saying that you plan to have Menu item data, but not menu, then I will add it. Right now, the menu stores, 1) the AHK menu name (just in case you have a menu handle and want to get the AHK name (I know, useless, but I thought, "you never know"), and 2) whether the menu has standard menu items - this was needed because AHK wasn't allowed to recreate the menu.

I just realized this... even with these additions, AHK can never be allowed to recreate the menus... if a menu items is moved (or insterted), AHK doesn't know this... So, sadly, I can't give AHK control yet, that sucks. Up until now, I thought that AHK could recreate the menus if it stored the menu data. That's not the case, because if an item was moved (or inserted instead of added to a menu - which requires a move), then AHK won't know this, and when it recreates the menu, this move is lost... bummer. Well, I guess there won't be that much of a difference between the two wrapper versions after all. That's a let down - not your doing, but I can't believe I didn't realize that sooner.


Oh, there are programs designed only to be used?? I'm learning more about this world each day.

I hope that didn't sound as conceited as it does in my head - that wasn't my intent. I only meant that I could not live without automation. My programs are linked to global hotkeys (thanks to PStart), I use gmote for mouse gestures, SyncExp to sync my flash drive with my AHK code (to test on my XP comp), and various other programs. I guess I don't use "true automation" - trying to see if word-wrap is on f.e., but I have seen many posts on this forum for people who want to do just that. So, I guess it just shocks me that programmers design their programs to be used, not automated - when there isn't much difference (e.g. check the menu item when the user clicks on word-wrap versus when the menu is "drawn").

Also, it never ceases to amaze me with the number of portable programs that don't have truly portable settings - they depend on the drive letter, for example. I guess I just think of the most bizarre ways to use someone's code and program my code to be just as bizarre - which is why I'll have people like Lexikos on me about how foolish I am for associating menu data that no one will use . What can I say, "I was born that way."

_________________
As always, if you have any further questions, don't hesitate to ask.

Add OOP to your scripts via the Class Library. Check out my scripts.

@ animeaime:Relax, you're not the only 'freak' out there.
I also tend to think of the most 'impossible' ways to do something and this is proof that at least one person in this world would need that. It really makes me sad when people - usually programmers - ditch certain not-so-standard-and-required option just because there's not enough demand for it. Personally I believe in freedom of thought and expression and as such I'd love to be able to allow such freedom in my 'products'.

As you said: "you never know".

@ Lexicos:
you're right in all aspects; sometimes I'm just simplifying down. In regard to MSLU, there are certain aspects that need pondering; I know for sure certain functions do not work as expected, since they're badly or incompletely implemented and the same goes for native 9x functions that were supposed to handle Unicode.

There have been efforts towards patching/upgrading 9x at an unofficial level (more details in the 95/98/98SE/ME section at the MSFN.org forums board) but we should take into consideration official setups first, for safety.

Thank you for considering 9x support in your version; I'll have to give it a spin someday.

_________________
AHK tools by Drugwash (AHK 1.0.48.05 and Win98SE)

Yes, I've tried it and use when appropriate. It does not work in my situation because is works on menu items that carry out a command, not items that change a state. For example, if the menu item is 'Delete', it will carry out the delete command. But if the menu item is to set the state of 'Show Flagged', a checkmark item, then it does nothing.

I am working on trying to improve the workflow of using Lightroom to cull large amounts of images as wedding photographers encounter. Lightroom is a very good program but for this task, it could stand considerable improvement.

First, the interface is 'Designer' driven - it look pretty above functionality. As an example, there is a icon for turning on/off unflagged photos. The icon is in about 3 or 4 shades of gray and is very small and located on a toolbar which may or may not be visible. It is an important function. Yet it is very, very difficult to determine the state of the icon. The 'on' looks so similar to the 'off' that you must move closer to the monitor and study its state. Not something you want to do when working fast. It breaks concentration and work flow. The solution is very simple, give the 'on' state some color so that the two state appear noticeably different. Design dictums aim for a minimum of color so that is not done.

Second, the interface is mouse centric. I realize the importance of the mouse but for some things it is not the best way to go. The adjustment sliders are very small and it takes concentration and motor skill to get the adjustment you need. I have added via AHK the ability to call up the adjustments and make them using the up/down keys. This works much faster than the mouse and is more precise. With the mouse, you look at the image and decide what adjustment to make and then look at the panel and pick the appropriate slider. Now look back to the image to judge the effects of the adjustment while trying to move the mouse in very small increments and keep it on the slider. It is not easy. You are constantly looking back and forth between the image and panel. Using my method, you hit the hot key for the adjustment, keep your eye on the image, and press the up/down keys for adjustment. No need to take your eyes of off the image. As a bonus, I pop up a little dialog that lets you know you are in the adjustment mode, which adjustment you are making, and (if in the Develop module) what the current adjustment is. It is really quite slick. I hope Adobe steals it from me.

I am aware of the differences between a program designed for automation and one that is not. I customized AutoCad for quite a few years, creating some very complex programs, some that literally took a couple of years to develop and were expensive. This is my first crack at a program not designed to be automated. But being the creature that it is does not mean we should not try to improve it. It just means more hard work, a lot of bitching and moaning, trial and error, trips down blind alleys, and the rare epiphany moment when we finally get it. So if I can't do something, I'll keep searching and try alternative approaches.

By the way I have solved the problem with flags. There is an obscure combo box where you can define the state you want the flags in. So I defined the states I needed and am able to easily set the state programmically via the combobox.

Larry

I updated the latest version of the menu wrapper. I moved the documentation out of Menu.ahk and put it in the included ReadMe. If the documentation is in any way unclear, don't hesitate in asking for clarification. I'll post a response here, and modify the ReadMe accordingly.


Here are the latest updates:

Revision3:

Mod: For functions that have a ByPosition parameter
specify -1 to treat MenuItem as an item handle
specify 0 (or false) to treat MenuItem as a menu item name
specify 1 (or true) to treat MenuItem as a position

If MenuItem is not a parameter, then these specify the return type.
other values are reserved for compatibility with future versions

Mod: Menu_selectMenuItem(hMenuItem, hwnd = 0)

Values for hwnd:
0 - to click an AHK menu item
the empty string ("") - to click a menu item in the Last Found Window
else, the hwnd (window unique ID) for the window

Mod: For functions that take MenuNameOrHandle, the Position (if included) can be one of these:
1) If an integer, the item's position (starts at 1)
2) "h" followed by the item's handle (an integer) - as returned from Menu_getMenuItemHandle

Add: Menu_GetMenuHandle function

Menu_GetMenuHandle(MenuName)
wraps MI_getMenuHandle so even if menu doesn't exist, an error won't occur

Mod: Menu_getMenuItemHandle

Menu_getMenuItemHandle(MenuNameOrHandle, Position, ByRef ThisMenu = 0)
returns the menu item's handle for the menu item at the specified Position in the specified menu
(-1 is returned if the menu item opens a submenu, or if an invalid position is given)

Position can be an integer,
or a comma-delimited list of Positions (each that will "wrap")

The list is the "road map" of menu items (all of which are submenus)
that lead to the last position, which must be a menu item.

Add: Menu_getMenu

Menu_getMenu(hwnd = "")
returns the menu handle for the menu bar of for the specified window

the hwnd is the same as the window's unique ID
(you can use a function call, i.e. WinExist, to retrieve this value)

if hwnd is not specified (or 0), the Last Found Window will be used

_________________
As always, if you have any further questions, don't hesitate to ask.

Add OOP to your scripts via the Class Library. Check out my scripts.

Have you updated all the files accordingly? I'm getting error
• at line 19 in MenuLibraryTemplate.ahk: Menu_destroy_private(MenuObject) -> duplicate function definition.
• at line 24 in MenuLibraryTemplate.ahk: Menu_destroy_private(MenuItemObject) -> duplicate function definition.
and others as well.

The issue seems to be with MenuLibraryTestSetup.ahk where these functions are duplicated.

_________________
AHK tools by Drugwash (AHK 1.0.48.05 and Win98SE)

Sorry about that. I thought I grabbed all the files. Also, forgot to post the link for easy download. You can download the zip here.

_________________
As always, if you have any further questions, don't hesitate to ask.

Add OOP to your scripts via the Class Library. Check out my scripts.

Works correctly now, thank you.

_________________
AHK tools by Drugwash (AHK 1.0.48.05 and Win98SE)