jrgreenman

I seem ot be having some trouble with activiations using the Windows Key. Win+Z works on my Win7 machines, but after upgrading one of my laptops to Win10, it no longer works. Neither does my Win+G macro. Did Win10 seize control of some more key combinations that makes them unavailable in Macro Express?

Paul, thanks for the tip. I can't use AutoIt at this point because I am sharing macros throughout my organization and installing AutoIt on all the employees' PCs so that this works for everyone creates a maintenance issue my IT folks won't sign up for. But I was able to make use of Window Handles in order to overcome my current issue. As long as the issue doesn't become chronic, using MEP's Window Handle capability might do the trick. But I do hope they update MEP at some point to address the underlying issue of not having a way to prevent hidden windows interfering with visible windows. Thanks again for the input. Jace

Good suggestion. I'll give that a try.

Well, I've only got two montors, but all 26 of my icons are on one. So it's getting a little tight. Thanks for commisserating though.

I think I'm having a similar problem. I open an Outlook folder whose window title is "PubContacts - Business in Public Folders - Microsoft Outlook" and then attempt to "Activate" the window using "Partial Match" and the string "PubContacts - Business". But it fails consistently, even if I have just a one-line macro containing the Activate command. In the past, this has been affected by the existence of hidden windows with conflicting titles. And sure enough, when I look at the hidden windows, I find two additinioal hidden with the same title. So far, I've never had a need to access hidden windows. They have always just been something I have to work around. Is there way to tell the Activate command to ignore hidden windows and just activate the visible window? Jace

The Win7 systme tray does not show the running man because the icon is "hidden" (along with 20 or others that I don't want to show). But when I go to the "hidden" list and Customize it tell Windows to tell windows to "Show icons and notifications" it is onlyeffective for the named macro that is currently executing. Is there a way to change the tooltip associated with the runnig man so his "name" isn't different for every macro? How can I tell windows to ALWAYS show the running man? Jace

I notice this bug is still present in v4.3.0.1.

Good tip. The developer site says it is compatible w/ "Windows 95/98/ME/NT/2000/XP/Server 2003" and specifically says it is not Vista compatible. No mention either way regarding Win 7. Are you using it w/ Win 7? I'll give it a try and see what happens.

Already submitted the incident, but I referred them to this thread. As an aside, I only had one message window open and confirmed in the debugger that the path to the control I was referencing was the same as the path to the control I was capturing. Couldn't get it to work i the debugger either. That's when I concluded I wasn't imagining things.

Oh, my problem isn't even quite that bad. I'm using OL 2007. I can highlight all the controls and capture the z-order w/ Get Control. My problem is just that it doesn't actually get the recipient off the "To" line. I can get "From" and "Subject" though. Will submit a report to ISS. As always, thanks for the quick reply, and for the SMTP headers tip, Cory. Had not thought of that workaround.

I am attempting to get the value of the "To" line in an email message that's in my inbox. So I open the message and use Get Control to retrieve the text from the control. But the text keeps coming up blank. I can use Get Control to retrieve the "From" line (screenshot001), and the subject (screenshot002), but attempts to get text from the "To" or "cc" lines returns a blank string (screenshot003; actually I think single space). This worked perfectly for so long, but I haven't use the macro for a while and so can't know if an upgrade to MEP caused the change in behavior or something else. Can someone duplicate the behavior? Any ideas on what's wrong? Or even an alternate way to obtain the name/email of a recipient frmo an existing message in the inbox? Thanks. Jace

If (ok, when) my macro hangs at runtime, is there a way to determine what line and macro (e.g. called macro) it is in when I abort it?

Oh, it turns out that one registry turns off some other WIN key shortcuts as well (like WIN-E and WIN-R). So folks who use the registry entry to turn off Win+1, Win+2, etc. in Windows 7 will need to write some macros to restore the functions of whatever other WIN key shortcuts you want to keep.

Thanks Paul. You're quite right. I was so radar-locked on this from the MEP perspective, I completely neglected to look at it from the OS perspective. Thanks for the link. And everyone, let this be a lesson to us all. Google first. Post second. Jace

Before switching to Windows 7, I had a series of macros whose activation were <WIN>+1, <WIN>+2, <WIN>+3, etc. Under Windows 7, those now appear to be reserved system keys for activating applications on the Task Bar. Is there a way to reclaim those key for use as macro activations?

Since it has been a wile, I thought I'd bump this topic and see if there were any further thoughts. Since upgrading the Win7, I now found that the OS claims ownership of the Win-P and Ctrl-Win-P (swell). So while I'm now thinking about other intuitive keystrokes to use for printing the screen, I stumbled across my old thread and thought I'd see if there were any current thoughts on supports remapping of the PrtSc key(s) in MEP.

Yes, it works that way when using RDP. But when using Remote Administrator (Famatech.com), it is different. I guess I thought it had something to do with Macro Express, but apparently the behavior you see nominally using RDP w/ both XP and Win 7 is "normal". Guess I'm outta luck.

Great idea, Paul! But I don't really want to disable it entirely. I just want the Win-L keystroke to get passed to my remote session when it has focus. I think the problem is that, even when the remote session has focus, Win 7 is acting on the Win-L keystroke itself. That behavior is different than XP. In Win 7, the OS seems to pass all other system hotkeys to the remote session when it has focus (e.g. Win-E, Win-R etc). But Win-L locks the local workstation whether the remote session has focus or not. I initially thought your idea would work if I disabled the Lock Workstation function and then wrote a macro to run the Lock Workstation command and use Win-L to activate it. But when I disable the lock capability using the registry, it really turns it off at a fundamental level so the capability is completely unavailable. Maybe I can figure out how to remap the Windows 7 Win-L to something else so I can make it available in a macro. But even that might still cause the local workstation to lock instead off the workstation on the remote session. Thanks for the suggestion though.

Oh, I'm pretty sure it's a change in the way Win 7 does things, but was hoping MEP had a way to compensate. My assumption is that MEP intercepts the Win-L keystroke in XP, and I was hoping it could somehow do the same in Win 7.

When I have a remote session active (I use Remote Administrator, www.famatech.com) and press Win-L to lock the remote workstation, MEP locks the local workstation at the same time. But this only occurs under Windows 7. Under XP, MEP catches the keystroke and passes it onto the remote session as expected (e.g. the local workstation does not act on the "lock" keystroke). I've tried "Restore Keyboard and Mouse Hooks", but the local PC is still acting on the Win-L keystroke. Is there way under Win 7 to make sure that MEP gets the keys like XP does?

Some programs use windows that are not really "windows". QuickBooks does this a lot which can make it tough to navigate reliably using Get Control, and Capture Control. But we limp along. Anyway, sometime QuickBooks unilaterally resizes these "non-windows" (acc'ding to Get Control, they are something called a MauiReport). Can you think of a good way (or any way) set the coordinates and resize these things?

Thanks for all the tips guys. In the end, I piggybacked off the PGM Macros (the PGM library has some great date/time functions already) to come up with the following macro "Convert Date To Decimal" <COMMENT Value="Set String \"DateString\" before calling. Returns \"DateDecimal\""/> <WRITE REGISTRY VALUE Key="HKEY_CURRENT_USER\\Software\\Professional Grade Macros\\Parameters\\ParameterString1" Destination="%DateString%"/> <MACRO RUN Use_ID="FALSE" Name="{ DateTime - Format Input String }" ID="-1" Wait="TRUE"/> <READ REGISTRY VALUE Key="HKEY_CURRENT_USER\\Software\\Professional Grade Macros\\Parameters\\ReturnString1" Destination="%lclDateString%"/> <WRITE REGISTRY VALUE Key="HKEY_CURRENT_USER\\Software\\Professional Grade Macros\\Parameters\\ParameterString1" Destination="%lclDateString%"/> <MACRO RUN Use_ID="FALSE" Name="{ DateTime - Date to Julian }" ID="-1" Wait="TRUE"/> <READ REGISTRY VALUE Key="HKEY_CURRENT_USER\\Software\\Professional Grade Macros\\Parameters\\ReturnDecimal1" Destination="%DateDecimal%"/> The nice thing about the above is that the PGM macro "{ DateTime - Format Input String }" takes a variety of date formats as input strings. So this is pretty flexible. Finally, in my case, I'm seeding DateString from a known-good date (not user-typed input) and so stripped out all the error-checking. Maybe I'll be sorry, but not yet. Usage is as follows: <VARIABLE SET STRING Option="\x00" Destination="%DateString%" Value="12/22/2010" NoEmbeddedVars="FALSE"/> <MACRO RUN Use_ID="FALSE" Name="Convert Date to Decimal" ID="-1" Wait="TRUE"/> <VARIABLE SET DECIMAL Option="\x00" Destination="%Result%" Value="%DateDecimal%"/> I think three lines is as tight as I can make it. The most elegant solution would be if MEP supported passing in/out parameters to macros directly using "Macro Run". Then of course we would not have set input values nor retrieve output values using individual lines of code, but could write something like: Macro Run: Convert Date to Decimal ("12/22/2010", %Result%) Can I get an Amen!?!?!

My string is in the form MM/DD/YYYY. So I was hoping for a native command that would operate on a date in that format or some other elegant way to manage this. Thanks for the tip, though. Converting to decimal and then to date/time could be part of the solution (once I convert MM/DD/YYYY to the relevant decimal equivalent).

I see commands to store date/time vars in strings, and do all kinds of date math. But I can't seem to find a way to convert a string variable to date/time. Is there a way to do this?

I encountered this issue using MEP 4.2.1.1 under both Win XP and Win 7. Turned off the clipboard hook, and it went away for me as well.