Detecting if a macro was opened via menu?

[terrypin]

This one has me struggling. First a little background. The environment is map applications like Memory Map, Google Earth, etc. I sometimes hover the mouse cursor on the map and then with a memorised hotkey activate a macro which does something concerning that position. Such as place a visible marker at that place, or copy its co-ordinates to the clipboard, etc.

 

However, because there are many of these macros and I sometimes forget their hotkeys, I also want to include the macros in a pop-up menu. My preferred method of activating a menu involves middle-clicking the application window title bar. So this inevitably alters the macro, because at the very least I want to display instructions at its start like "Place the mouse cursor at the required position before continuing."

 

Now, I could of course create two separate macros in every case, one for immediate hotkey use, the other for use via the menu. But I'm sure it ought to be possible to accomplish this more elegantly with a single macro, which initially somehow detects whether it's been started from a menu. But how? My first thought was to detect the topmost window title. But of course that doesn't work because a pop-up menu immediately closes when one of its macros is started!

 

Another possibility would be to change the menu activation to a middle click anywhere on the map, rather than restricting it to the title bar. Providing I then activated the macro by its accelerator key rather than impulsively d-clicking it, that would then leave the mouse cursor in the target position.

 

But I suspect I'm missing some obvious smart solution that doesn't require such a major change. Any ideas please?

 

Edit: I've thought of a solution that I'll try shortly. I'll amend the main menu to include code that writes a switch value ON to the registry. Then in the individual macros under discussion add code at their start to read and test that value, continuing as appropriate. And then switch it OFF.

 

--

Terry, East Grinstead, UK

[Yehnfikm8Gq]

I'd do it the same way I do all those sort of things. The following code at start of macro:

 

Text Box Display

"Position mouse and hit keyboard ENTER"

Rest of code

 

An "all-mouse" solution that I've not tried would be:

Floating Text Box Display

"Position mouse and click"

Wait for Mouse Click

Close Text Box Display

Rest of code

[terrypin]

I'd do it the same way I do all those sort of things. The following code at start of macro:

 

Text Box Display

"Position mouse and hit keyboard ENTER"

Rest of code

 

An "all-mouse" solution that I've not tried would be:

Floating Text Box Display

"Position mouse and click"

Wait for Mouse Click

Close Text Box Display

Rest of code

 

Thanks, but my point was that I want to avoid that unnecessary interaction when the macro is started off with the hotkey.

 

I'm up early to try a solution I thought of overnight. I'll edit my original post to include it.

 

--

Terry, East Grinstead, UK

[paul]

Edit: I've thought of a solution that I'll try shortly. I'll amend the main menu to include code that writes a switch value ON to the registry. Then in the individual macros under discussion add code at their start to read and test that value, continuing as appropriate. And then switch it OFF.

What am I missing here? How are you going to add any code to your popup menu? I've not actually used popup menus, so I just created one, but was unable to find any code to modify or insert.

[terrypin]

Simple! In the new menu, 'Mem-Map MENU + Switch', start the old menu with a Macro Run command. Then follow it with the extra code, e.g:

 

Macro Run: Mem-Map MENU

Variable Set String %MemMapSwitch% to "ON"

Write Registry Value "%MemMapSwitch%" into HKEY_CURRENT_USER\Terry Work Area\Text\Mem-MapSwitch

 

And remove the activation from the old menu, adding it instead to the new one.

 

Works a treat. However a downside is that I'd have to add code like the following to every macro in that menu (40 plus at present, in this application alone), even though the majority of those are not macros requiring this special treatment. Otherwise the switch would incorrectly remain ON after running any of them. It's only a copy/paste job though, so I might still do it.

 

Variable Set String %MemMapSwitch% to "OFF"

Write Registry Value "%MemMapSwitch%" into HKEY_CURRENT_USER\Terry Work Area\Text\Mem-MapSwitch

 

 

Edit: Hmm - not so simple after all! The menu activation etc all appears to work just fine. But I've hit an obstacle that may kill the approach dead in its tracks. A pop-up menu will 'run' for ever if you leave the option 'Wait for this macro to terminate before proceeding' checked (the default). I switched it off but have now discovered that my logic test after the Macro Run command is then ignored, despite the variable being correctly shown as ON. Still trying to figure it out. And I just slogged through adding extra code to 40 or so macros!

 

--

Terry, East Grinstead, UK

[paul]

Edit: Hmm - not so simple after all! The menu activation etc all appears to work just fine. But I've hit an obstacle that may kill the approach dead in its tracks. A pop-up menu will 'run' for ever if you leave the option 'Wait for this macro to terminate before proceeding' checked (the default). I switched it off but have now discovered that my logic test after the Macro Run command is then ignored...

What logic test? I didn't see any logic tests in any of the examples you showed!

[terrypin]

What logic test? I didn't see any logic tests in any of the examples you showed!

 

I didn't show the code but I briefly mentioned it here:

"Then in the individual macros under discussion add code at their start to read and test that value, continuing as appropriate."

 

Here's the typical logic code I'm adding at the start of the individual macros:

 

Read Registry Value "HKEY_CURRENT_USER\Terry Work Area\Text\Mem-MapSwitch" into %MemMapSwitch%

If Variable %MemMapSwitch% Equals "ON" // Macro was opened via menu, not hotkey.

Text Box Display: Initial Instructions

End If

// Main part of macro continues here.

 

And at the end of all macros in the menu (not just those that require the alternative treatment), I've added this:

 

Variable Set String %MemMapSwitch% to "OFF"

Write Registry Value "%MemMapSwitch%" into HKEY_CURRENT_USER\Terry Work Area\Text\Mem-MapSwitch // Turn off the menu switch.

 

While away from home for a couple of hours I realised that my edit above about a serious obstacle was nonsense. I accessed it via my Pocket PC (under Windows Mobile) but for some reason couldn't login to delete it. I'll leave it in now.

 

Anyway, I can now confirm that the approach does work OK. IOW, when such a 'special' macro is activated by hotkey, with the mouse cursor already positioned, it does its job with no messages or user intervention. If on the other hand it was invoked via the menu, it pops up a message advising the user to position the mouse cursor before proceeding.

 

--

Terry, East Grinstead, UK

[Yehnfikm8Gq]

There seems to be some confusion as to what is required. To quote the original post, "because at the very least I want to display instructions at its start like "Place the mouse cursor at the required position before continuing". The response to my suggestion for doing exactly that is, "Thanks, but my point was that I want to avoid that unnecessary interaction when the macro is started off with the hotkey". Apart from the fact that was not mentioned, here is no unnecessary interaction - a Text Box Display appears, so what? If you choose the "all-mouse" option you click the mouse just like you do right now. Nothing extra is involved as far as you are concerned.

 

I use the "hit Enter" option for numerous macros. I place the mouse and hit Enter. It's a nothing event. Also, if you use either option I mentioned, the macro behaves exactly the same regardless of how it is activated. Isn't that a good idea? The TBD does not even have to appear but I thought the idea was also to stop you clicking without thinking, "Providing I then activated the macro by its accelerator key rather than impulsively d-clicking it".

 

Going the memory route is fraught with problems. Every time you memorize it has appeared, it has to be reset. That means it has to be reset after any macro has run as you noted. So you are going to edit 40 macros just to stop a TBD appearing that clears itself with no intervention from you. Every time you add a new macro to the menu, you have to remember to add the extra lines.

[paul]

I didn't show the code but I briefly mentioned it here:

"Then in the individual macros under discussion add code at their start to read and test that value, continuing as appropriate."

 

Here's the typical logic code I'm adding at the start of the individual macros:

 

Read Registry Value "HKEY_CURRENT_USER\Terry Work Area\Text\Mem-MapSwitch" into %MemMapSwitch%

If Variable %MemMapSwitch% Equals "ON" // Macro was opened via menu, not hotkey.

Text Box Display: Initial Instructions

End If

// Main part of macro continues here.

...etc.

Why not take advantage of MEP variables - there's no need for the registry at all?

In your menu macro, add a boolean variable called, say, %bMenuCalled%, and set it to True.

Now insert lines at the top of all your macros, as in:

  If Variable %bMenuCalled% Equals "True"
 CalledFromMenu Processing Logic
 Else
 NotCalledFromMenu Processing Logic
 End If

Voila - Nothing else required.

[terrypin]

There seems to be some confusion as to what is required. To quote the original post, "because at the very least I want to display instructions at its start like "Place the mouse cursor at the required position before continuing". The response to my suggestion for doing exactly that is, "Thanks, but my point was that I want to avoid that unnecessary interaction when the macro is started off with the hotkey". Apart from the fact that was not mentioned, here is no unnecessary interaction - a Text Box Display appears, so what? If you choose the "all-mouse" option you click the mouse just like you do right now. Nothing extra is involved as far as you are concerned.

 

I think you missed the point John, and still missing it! I did explain in my opening paragraph that there were two scenarios. Consider them again now with a solid example:

 

1. I forget the hotkey for placing a marker on the map. (I repeat, there are scores of them across several mapping applications). But I know that all my macros are listed in a pop-up menu. I activate the menu for this application by middle clicking its title bar. I activate the Make Marker macro by d-clicking or keying its accelerator. I follow the instructions to position the mouse cursor. The mark is then placed.

 

2. I remember the hotkey. I place my mouse cursor on the target and hit Ctrl+Sh+M. The mark is immediately placed. Much, much faster than the alternative above. And even significantly faster than just displaying a redundant message. For this sort of map work the thought process is Locate then Operate. Move the mouse then place the marker.

 

I use the "hit Enter" option for numerous macros. I place the mouse and hit Enter. It's a nothing event. Also, if you use either option I mentioned, the macro behaves exactly the same regardless of how it is activated. Isn't that a good idea? The TBD does not even have to appear but I thought the idea was also to stop you clicking without thinking, "Providing I then activated the macro by its accelerator key rather than impulsively d-clicking it".

 

Going the memory route is fraught with problems. Every time you memorize it has appeared, it has to be reset. That means it has to be reset after any macro has run as you noted. So you are going to edit 40 macros just to stop a TBD appearing that clears itself with no intervention from you. Every time you add a new macro to the menu, you have to remember to add the extra lines.

 

I agree that there are pros and cons. Time will tell if it was worth the effort. But I use many of these macros dozens of times a day so I reckon it will be.

 

Of course, I might eventually commit all of these hotkeys reliably to memory, in which case the issue disappears!

 

--

Terry, East Grinstead, UK

[terrypin]

Why not take advantage of MEP variables - there's no need for the registry at all?

In your menu macro, add a boolean variable called, say, %bMenuCalled%, and set it to True.

Now insert lines at the top of all your macros, as in:

  If Variable %bMenuCalled% Equals "True"
 CalledFromMenu Processing Logic
 Else
 NotCalledFromMenu Processing Logic
 End If

Voila - Nothing else required.

 

Thanks, that looks neat! Never used Boolean variables before, but will try it later today and report back.

 

--

Terry, East Grinstead, UK

[paul]

Edit: Hmm - not so simple after all! The menu activation etc all appears to work just fine. But I've hit an obstacle that may kill the approach dead in its tracks. A pop-up menu will 'run' for ever if you leave the option 'Wait for this macro to terminate before proceeding' checked (the default). I switched it off but have now discovered that my logic test after the Macro Run command is then ignored, despite the variable being correctly shown as ON. Still trying to figure it out. And I just slogged through adding extra code to 40 or so macros!

There seems to be a bug here which you should report. Even if you switch off the option 'Wait for this macro to terminate before proceeding', the calling macro never seems to regain control. For example,

Macro Run: TestMenu2
Text Box Display:

where TestMenu2 is a popup menu, the Text Box Display command never executes. At least I can kill Forrester when the option is unchecked. When checked, I must kill MEP instead.

Even calling TestMenu2 via MeProc gives the same result. Popup menus must really screw MEP badly.

 

So, of course, my previous suggestion about using variables won't work, and nor will your registry stuff because it's never executed.

[terrypin]

There seems to be a bug here which you should report. Even if you switch off the option 'Wait for this macro to terminate before proceeding', the calling macro never seems to regain control. For example,

Macro Run: TestMenu2
Text Box Display:

where TestMenu2 is a popup menu, the Text Box Display command never executes. At least I can kill Forrester when the option is unchecked. When checked, I must kill MEP instead.

Even calling TestMenu2 via MeProc gives the same result. Popup menus must really screw MEP badly.

 

So, of course, my previous suggestion about using variables won't work, and nor will your registry stuff because it's never executed.

 

I was getting that sort of behaviour (and having to use TM to kill MEP) but I appear to have fixed it! That's why I was trying to delete my edit. I'll re-examine this later and see if I can reproduce your error, or even eliminate it!

 

Meanwhile, your Boolean approach works fine. However, you were a bit hasty with "Nothing else required." After adding the necessary Variable Save and Variable Restore commands, and Variable Set Bool %bMenuCalled% to "False" at the end of each macro, the number of commands is the same as my registry aproach. So doesn't it come down to a matter of which you trust the most? I've read so much over the last year about quirky MEP variable behaviour that I rather lean towards the registry.

 

--

Terry, East Grinstead, UK

[terrypin]

I was getting that sort of behaviour (and having to use TM to kill MEP) but I appear to have fixed it! That's why I was trying to delete my edit. I'll re-examine this later and see if I can reproduce your error, or even eliminate it!

--

Terry, East Grinstead, UK

 

 

I can't reproduce your problem. It all seems to be working OK here.

 

I created a macro called Test macro:

Test_macro.mex

 

Variable Restore: Restore Boolean Variables

// This is activated either by the hotkey Ctl+Sh+F7 or via the menu 'Test Menu' called from the macro 'Test Menu + switch'.

If Variable %bMenuCalled% Equals "True"

Text Box Display:

// Menu-called commands here.

Else

Text Box Display:

// Hotkey-called commands here.

End If

Variable Set Bool %bMenuCalled% to "True"

Variable Save: Save Boolean Variables

 

I created a pop-up menu called Test Menu. Its only entry is 'Test macro'. Activate any way you prefer.

 

I created a new macro called 'Test Menu + switch':

Test_Menu___switch.mex

 

Macro Run: Test Menu

Variable Set Bool %bMenuCalled% to "True"

Variable Save: Save Boolean Variables

 

(The Macro Run command has the option 'Wait for this macro to terminate before proceeding' unchecked.)

 

If I use the hotkey I get the correct display:

"The global macro 'Test macro' is running. It was activated by the hotkey Ctl+Sh+F7."

 

If I use the menu (run from the new macro) I also get the correct display:

"The global macro 'Test macro' is running. It was activated from the menu 'Test Menu'."

 

Forrest disappears when he should.

 

--

Terry, East Grinstead, UK

[paul]

I can't reproduce your problem. It all seems to be working OK here.

It's the Text Box Display command that is the problem! If I remove it and insert non-interactive commands, it all works fine.

[Yehnfikm8Gq]

This will be my last comment on the thread. I may post a new topic on the mouse issue later. The origins of this thread is OT but I did test the two methods I described in post #2. Obviously the max time before the rest of the macro executes can be anything you like. The minimum is so short it's difficult to guess; my estimate is in the 100-250msec range. If that is considered excessive then I suppose it's a problem. I would not be changing 40 macros just for that.

[terrypin]

It's the Text Box Display command that is the problem! If I remove it and insert non-interactive commands, it all works fine.

 

That's your original, not my test? Very odd. Why should that matter? Can you export your macro so I can play with it please.

 

My 'Test macro' had a mistake. I added its last command after testing it, and it should of course have been Variable Set Bool %bMenuCalled% to "False" not True

Here's the revised export: Test_macro.mex

 

And for completeness, here's the 1-line menu macro: Test_Menu.mex

 

BTW, does my code look OK? In particular, I'm puzzling over the Variable Restore. Does 'restoration' only apply to variable values before a macro is run? If I precede

Variable Restore: Restore Boolean Variables

with either Variable Set Bool %bMenuCalled% to "True" or Variable Set Bool %bMenuCalled% to "False" it makes no difference. I'd have expected that value to apply directly after the restore. This is the sort of factor that has me leaning towards the registry for variable storage!

 

--

Terry, East Grinstead, UK

[terrypin]

The origins of this thread is OT

 

I don't know what that means.

 

but I did test the two methods I described in post #2. Obviously the max time before the rest of the macro executes can be anything you like. The minimum is so short it's difficult to guess; my estimate is in the 100-250msec range. If that is considered excessive then I suppose it's a problem. I would not be changing 40 macros just for that.

 

I've used both obvious methods for years and they work fine. The second often proves less flexible but in practice it's always easy to decide which one feels right. But for the situation under discussion (my applications, my macros, my work style) I'm merely looking for something different, simple as that! The jury's still out whether this relatively complex method Paul and I are now discussing will cut the mustard. I'm beginning to doubt it frankly. But I'd be much happier if you were in the discussion too.

 

--

Terry, East Grinstead, UK

[paul]

That's your original, not my test? Very odd. Why should that matter? Can you export your macro so I can play with it please.

Different behaviour tonight! Now, with a Text Box Display command following the call to MenuPopup without waiting, the popup menu appears, followed by the Text Box display (just as if the Wait for completion were ticked). The only problem now is that Forrester remains, though now I can dismiss it by clicking.

 

And if the popup menu used the Default Style, then it appears for only a moment, then disappears because the calling macro resumes control.

 

All in all, a can of worms.

[paul]

BTW, does my code look OK? In particular, I'm puzzling over the Variable Restore. Does 'restoration' only apply to variable values before a macro is run? If I precede

Variable Restore: Restore Boolean Variables

with either Variable Set Bool %bMenuCalled% to "True" or Variable Set Bool %bMenuCalled% to "False" it makes no difference. I'd have expected that value to apply directly after the restore. This is the sort of factor that has me leaning towards the registry for variable storage!

In the beginning (i.e. when MEP is first started) no variables have any values, apart from the default values. Integer variables all equal zero, string variables are all of zero length.

Now set %n[1]% to 100, and do a Variables Save Integer variables.

Later (but without restarting MEP), do a Variables Restore Integer variables. Now all non-integer variables retain their current value, and all integer variables equal zero, except for %n[1]% which equals 100. Any integer variables you created and set in the same macro before you did the restore are gone.

Thus, a variables restore command will restore the variables of the designated type to the values they held when you last did a variables save in the same execution of MEP (i.e. without restarting MEP).

[terrypin]

In the beginning (i.e. when MEP is first started) no variables have any values, apart from the default values. Integer variables all equal zero, string variables are all of zero length.

Now set %n[1]% to 100, and do a Variables Save Integer variables.

Later (but without restarting MEP), do a Variables Restore Integer variables. Now all non-integer variables retain their current value, and all integer variables equal zero, except for %n[1]% which equals 100. Any integer variables you created and set in the same macro before you did the restore are gone.

Thus, a variables restore command will restore the variables of the designated type to the values they held when you last did a variables save in the same execution of MEP (i.e. without restarting MEP).

 

Thanks, understood.

 

--

Terry, East Grinstead, UK

[terrypin]

Different behaviour tonight! Now, with a Text Box Display command following the call to MenuPopup without waiting, the popup menu appears, followed by the Text Box display (just as if the Wait for completion were ticked). The only problem now is that Forrester remains, though now I can dismiss it by clicking.

 

And if the popup menu used the Default Style, then it appears for only a moment, then disappears because the calling macro resumes control.

 

All in all, a can of worms.

 

Indeed!

 

I seem to have been fairly lucky with my many pop-up macros so far. (I currently have 38 menus holding around 450 macros.) But I'll have to think hard about retaining this 'alternative action' approach we're discussing, given its apparent unpredictability. I wonder if it's a Win 7 versus XP issue, as it seems OK here? Another factor could be the Style used for the menus. I never use the buggy and inferior Windows Default method, staying exclusively with Nickname & Scope.

 

--

Terry, East Grinstead, UK

[terrypin]

Indeed!

 

I seem to have been fairly lucky with my many pop-up macros so far. (I currently have 38 menus holding around 450 macros.) But I'll have to think hard about retaining this 'alternative action' approach we're discussing, given its apparent unpredictability.

 

I decided last night to drop this method. Although it was working smoothly for me, the erratic behaviour Paul reported makes me apprehensive. Despite my generous Commenting, I suspect that if it screws up someday I'll have the devil of a job sorting it.

 

So I've reverted to a compromise. For the more frequently-used macros whose hotkeys I'm pretty sure of by now I've duplicated the macro, placing one (with interaction added) on the menu and the other (with no interaction) exclusively hotkey activated. For the rest, the majority, I'm placing them all on the menu. For many that had hotkeys I've even removed that activation method.

 

It's not as satisfying, but I feel more comfortable with it.

 

Paul: Are you going to report the intermittent pop-up menu issues you described?

 

--

Terry, East Grinstead, UK

[paul]

Paul: Are you going to report the intermittent pop-up menu issues you described?

Already done.