jrgreenman

At last I have found the magic Windows registry value that was causing this behavior. It is called "Foreground Lock timeout" and can be modified per this thread:

http://social.answers.microsoft.com/Forums/en-US/w7performance/thread/1199682e-2415-4a7a-bf21-f57a972122ee

I hope that helps others who were suffering as I was.

Jace

None of these references should be relevant to your problem - I've just checked them all. The If test you found is used to determine whether the user is me, in which case I do, or do not, invoke certain logic. It should not be causing your problem.

 

In order to prove this, I wrote a simple macro to see if T:\myfilename exists (I don't have a drive T:).

The macro worked correctly and did not complain about no disk in a drive. I'm running Windows 7 x64 Home Premium.

Like some other folks, I got the messages to stop by putting a blank CD into my drive. And after a few reboots, I was able to remove the CD, and the messages have not come back...yet.

I'm still stuck with the "no disk in drive" prompts. Nothing in those registry locations refers to "D:"

Anyone? Buehler?

Edit: Might be on to something. Just found this in an export of my macro info:

D:\PGMFunctionsLibrary\PgmFL_Pro.mex

Looks like there are a bunch of references to D:\ in the PGM functions library.

Edit #2: There are 145 references in PGM Functions. Anyway to remove them all at once? Surely, I don't have to edit all the PGM macros and remove them individually.

BTW, they are all located in the "If Macro" command and refer to a "Macro filename" on the disk.

I am very familiar with this particular issue as it's caused us a lot of grief since Microsoft started implementing this back in Windows 2000.

 

Essentially, the idea is that a program should not come up into the foreground unless you started it from Explorer (i.e. the start menu, an explorer window, etc.). That way your workflow is not interrupted when a background program launches another program.

 

Since Windows 2000, each version of Windows has a slight change to how this is implemented. We have some code in place to work around this, but it's not always 100% perfect.

 

Add to that fact, Vista and 7 added an additional quirk with the thumbnail previews of windows when you hover over their taskbar entries. In this case, the preview window is not marked as hidden and it has the same name as the window you're previewing. So, when we go to do our activation code, Windows will sometimes give us the preview window instead (most likely that's where your activations are going).

 

One way to get around this is to follow up your launch command with a "Window Activate" command. We've found this to be the most reliable solution as it gives Windows a moment to finish cleaning up after a program launch and then give us the correct window handle to activate.

 

Could you try that and let me know if it works any better?

I tried both "Window Activate", following a Program Launch command, as well as "Launch Program and Activate Window", and while so far they appear to work in two other test cases (launching "calc" and "winword") neither works for launching "notepad".

I'll continue testing and see if adding in some Window Activate commands will bring some reliability back to my macros, but the failure of Notepad windows to respond to the "Window Activate" command under Win 7 x64 is puzzling, and suggests some other programs might misbehave in a similar fashion.

Thanks you for your response and especially the validation. Nice to know I'm not nuts...or at least that this isn't the reason why I am.

Works perfectly for me under Windows 7 Home Premium.

BTW, I suggest removing the " - untitled" portion of the window name, leaving it simply as Notepad.

I've create a "Steps Recorder" file that shows the behavior. Here's the macro information I exported from MEP 4.1.7.1:

Name: Notepad
Icon: (Default)
HotKey: Win+N
Scope: Global
<LAUNCH PROGRAM AND ACTIVATE WINDOW Title="Notepad" Exact_Match="FALSE" Wildcards="FALSE" Path="C:\\WINDOWS\\notepad.exe" Mode="\x00" Default_Path="TRUE" Wait="0" Wait_For_Program="12"/>

And here's a thread complaining about the same thing (Windows 7 x64):

http://social.answers.microsoft.com/Forums/en-US/w7files/thread/a55aec2b-ee7e-40f2-bc8b-8f4728671ca4

So while MEP is affected by (or affecting) the behavior, it may not be causing it. Still, am wondering if anyone else has encountered it and if/how they solved it.

steps.zip

Terry,

Ever get this sorted? Im running MEP 4.1.7.1 and just moments ago started seeing the same thing. Something is referring MEP to my DVD drive.

Jace

I'm also having pretty major migration issues (mostly setting focus to windows) going from XP and Win7.

But so as not to be off-topic , "Text Type <DELETE>" is one of the things that's actually working for me on Win 7.

When I run this macro under Win 7 Home Premium, notepad starts, but does not gain focus:

<LAUNCH PROGRAM AND ACTIVATE WINDOW Title="Untitled - Notepad" Exact_Match="FALSE" Wildcards="FALSE" Path="C:\\WINDOWS\\notepad.exe" Mode="\x00" Default_Path="TRUE" Wait="2" Wait_For_Program="12"/>

Works fine under XP. Confirmed on two different Win 7 machines and two different user accounts.

Same thing for "Window Activate" command. It has no effect.

Jace

I am setting a variable from a Section/Key in an ini file and am trying to detect if either the Section or the Key is missing from the file (as opposed to being present but containing a blank value).

There are five "On Error" conditions in "Set Value from INI file", but none of them seem to be related to detecting missing Section/Key.

Thoughts?

If I set break points in two macros and, during execution, the first (where I start the debugger) calls the second one, and then press F9 in the first one, execution does not stop at break points in the second macro.

I'm on ver 4.1.6.1.

Anyone else see this behavior?

Has anyone had any luck using MEP alongside any of the clipboard managers? I use Clipmate all the time, but haven't managed to get it to play nicely with any macro app.

Sadly, no.

My "workaround" is to start my clipboard manager, Yankee Clipper, only when I know I need to cut/paste multiple items. Then I shut it off.

I'm not sure if I ever submitted a bug report about it, but will do so. If you submit one too, maybe the issue will get some quick attention.

Great tip Terry! That worked perfectly. I'm all set.

I used HxD Editor (free). While Hex Workshop may be more feature rich, it's also $90.

Thanks again for the quick reply and good advice.

Jace

I'd personally first try a hex editor like Hex Workshop from http://www.bpsoft.com/downloads/

I'm no programmer but I've successfully used its Replace facility on MEX in similar situations. The crucial requirement appears to be that the Find and Replace strings should be identical in length. Happily that's true in your proposed case. (I'm sure someone more familiar with binary files could do it with unequal strings too. I'd appreciate a primer if so!)

 

I suspect it's confidential, but if not you could alternatively email the MEX to terrypin@dial.pipex.com and I'll send you a revised version to try.

 

--

Terry, East Grinstead, UK

I just upgraded from QuickBooks 2007 to 2010 and have about 60 macros that have the window title "Quickbooks 2007" embedded in them. I'd like to change them all to "QuickBooks 2010".

Is there some combination of import/export or some other kind of global search/replace I can use to fix everything all at once?

I am having a similar issue with the use of Set Variable from Prompt command. While the prompt dialog posts right away, and the title bar of the dialog indicates it has focus, it does nto really have focus. Two things indicate this

1. I easily observe that the cursor is still blinking in the prior window even though the title bar of the prompt dialog is the focus color.

2. When I Text Type after the dialog appears to have focus, the text is inserted in the prior window.

Sometimes it will take 5 seconds or more for the cursor focus to move to the prompt dialog. BUT if I wiggle my mouse or cross a window boundary, the focus moves immediately.

Not sure it's strictly related to what else is being discussed here, but definitely something fishy going on.

Yes. Generally everything will work but there are still some old and very important bits that are not changed until the reboot. There is a way to avoid the reboot but honestly it's more work than rebooting and it's more for mass deployments. Details in the ISS KB I believe.

I found this: http://www.macros.com/faq//5.12.html

But it references rebooting after an "uninstall". I guess the same thing would apply though. If mexhook.dll is locked it won't get replaced with the new version (assuming mexhook.dll changed w/ a new rev) until after a reboot.

MEP (ME3 too) always ask to reboot after they are installed. But I've noticed that everything seems to work fine if I don't.

Typically, I'll reboot at some later time anyway, but is a reboot really necessary after installing an update to Macro Express?

The release notes for 4.1.0.1 reference the following enhancement:

 

"Made a modification to make the emailing of attachments more reliable."

 

What exactly is that enhancement and how do I take advantage of it?

Forget it. I briefly thought it referred ot something in Outlook, but I now think this refers to the MEP emailing subsystem (which I don't use).

The release notes for 4.1.0.1 reference the following enhancement:

"Made a modification to make the emailing of attachments more reliable."

What exactly is that enhancement and how do I take advantage of it?

check into ClipMate. It' a real handy utility to boot. Mainly I just use it for multiple copy and replace like that stupid Office Clipboard promised but never delivered.

I use one called Yankee Clipper (they also have a free version), but some months ago I found it (and another one called Clip Magic) interferes with some macros. I never figured out the cause, but perhaps it has something to do w/ keyboard hooks. I think clipboard management utilities try to be first in line to see keystrokes like MEP does.

But I'll try ClipMate and see if that one behaves any better.

Notepad++ can show you hidden characters

Sure enough Notepad++ reveals a trailing CRLF if one copies a cell from Excel. Live and learn.

Thanks for the help.

Without getting into VBA I think Kevin's solution is best. However you could do as Kevin suggests and then create a macro to clean up a couple of minutes later. Or have a macro that runs from a rule in Outlook. You know, "Check messages after sending". Also have you considered using MEP's built in email feature?

Hm. For some reason, yet again, I didn't receive an email notification when this reply was posted. I've confirmed my email address in the system is good, and even rec'd a couple notification last month. But this is the second one this week where I've not rec'd one. Strange.

Anyway, I implemented Kevin's suggestion, but am rethinking it because I've found some use cases where things get a little wonky. First, I found that I frequently manually create docs to be attached and don't want to have to manually traverse to the temp directory (many layers down in the folder hierarchy) to place them there. Second, I often create multiple files and then subsequently attach them to different emails one-by-one. If the macro deletes *.* in the temp directory (I don't believe I have the file name any longer because for subsequent runs, it won't know what the actual name of the previously created file(s) was/were), the rest will disappear once I act on the first file. Same issue w/ the "clean up later" option. If I don't act on all the files before the housekeeping macro runs, I'd lose the files I'd created, but not yet acted on.

Regarding Outlook rules, I don't see one that allows me to delete files in the file system after a message is sent (using OL 2007). Even so, I'm hoping to find a more efficient way to handle this without running the rule after each email message that goes out.

Still, those were all good suggestions and got me brainstorming some more. If you think of anything else, feel free to lob.

Sorry for the delayed reply. Not sure why I never saw this post. No matter.

It sounds like that would leave the attachment in the temp folder until the NEXT time the macro is run, yes? So the most recent attachment would always be in there until the next time the macro runs?

While I'd prefer to not leave the file lying around (it could contain sensitive empoyee information), the logic flip indeed oughtta do the trick.

Thanks for the tip.

Joe's your man on this one.

I reached Joe (he was on vvacation or something) and he steered me to the latest version of PGM (now free) which includes the source code. The new version doesn't exhibit the behavior I referenced in my original post. So I'm in good shape now.

But along the way I found that this line of code in the { String Example - Parse } causes problems:

<VARIABLE MODIFY STRING Option="\x0F" Destination="%T[97]%" ToReplace="\\" ReplaceWith="\\x5c" All="TRUE" IgnoreCase="FALSE"/>

Could be that whatever required the PGM guys to include this was fixed in MEP somewhere along the way.

Removing that line of code allows the { String Example - Parse } macro to work correctly.

Thanks to everyone who helped steer me in the right direction.

Thanks for the info Cory. Much appreciated.

Thanks Cory. I've been spinning my wheels a bit and can't seem to find a hex editor that'll show me what's in the clipboard. Can you recommend one?