paul

In my tests, this checkbox in the Variable Set from File Path command doesn't appear to make any difference.

There's no mention of this option in the Help for the command.

Why then, it's correctly documented, isn't it?

If it does nothing (and I get the same results as you), then why on earth should Insight document it?

ISS added a feature to get a Windows handle but no one seems to know how to use that to activate a window and ISS has never given instructions on it.

Oh, that's easy! Try this code:

Program Launch: "notepad.exe" (Normal)
Parameters: 
Variable Set Handle %hNotepad% from a window with the title, "notepad"
Delay: 10 seconds
Window Activate: %hNotepad%

<PROGRAM LAUNCH Path="notepad.exe" Mode="\x00" Default_Path="TRUE" Wait="1" Get_Console="FALSE"/>
<VARIABLE SET HANDLE Option="\x01" Info="notepad" Partial="TRUE" Wildcards="FALSE" Destination="%hNotepad%"/>
<DELAY Flags="\x01" Time="10"/>
<WINDOW ACTIVATE Title="%hNotepad%" Exact_Match="FALSE" Wildcards="FALSE" _IGNORE="0x0006"/>

My understanding (probably wrong!) is that a handle variable can be used anywhere where you might otherwise use a window or control name. But I don't think it helps with MDI windows. AutIt provides more granular control over MDI windows, but it's not straight-forward.

Thanks folks. Below and attached is the failing script, in all 4 forms just to be complete... ;-)

 

I haven't yet tried the suggested workarounds and tests (work very busy) but will as soon as I can get a moment.

I must say I lost interest as soon as I read that you haven't tried the suggested workarounds and tests. If you describe a problem and get specific suggestions on how to solve it, then I don't see any purpose in you seeking more help until you've tried the already suggested solutions. Since you've already failed to take the proffered advice, what on earth could anyone in this forum do further that they haven't already done?

I see a demand for simple add-on programs for users to make up for some of the UI shortcomings in MEP. If anyone's interested please let me know.

I'll rewrite your first sentence above as follows!

I see a demand for add-on programs for users to make up for the shortcomings in MEP.

Have your macros been affected by this restriction? I tested a couple after configuring a screensaver, but they ran normally. So I suppose it means you need to test new macros with and without a screen saver active to be confident?

Almost the first thing I do when installing Windows is to disable screen-savers, get rid of wallpaper, themes, etc. In other words, almost all candy floss! In fact, of the performance options available, I use only "Show window contents while dragging" and "Smooth edges of screen fonts".

So, no, I'm not affected by this restriction.

Some things I've tried w/o success:

- using activate or launch, launch and activate, or window activate

- trying different settings e.g. seconds to wait or title to switch to

- trying on several versions of MEP and Word, trying reinstalls and repairs

- trying w/o other apps running, e.g. with MS Outlook shut off

When I'm really desperate for a particular application to gain focus (in the example I'm using Foobar2000), I do this:

Repeat Until %n[1]% Does not Equal "%n[1]%"
 If Window "foobar2000" is focused
   Repeat Exit
 End If
 Window Activate: foobar2000
End Repeat

You could generalize this so that a shared variable contains the window name, then you could simply initialize the shared variable with your desired window name and call the macro as a subroutine. You could also add a timeout, perhaps displaying a timed message if you can't focus on the desired window in the specified time.

How do others interpret that word 'running'? With the screen saver displayed? Or just set, ready to activate?

 

And presumably that restriction is general, for all macros, not just those with scheduled activation?

I think running means "active" - in other words, the screen-saver is in charge.

And yes, I think the restriction is global.

It is possible, but it involves writing a total of 39 macros (most of which are almost identical)! See Detecting Keys Pressed for details.

Let me reply for this kind of reminder once and for all:

 

 

I understand there is a toilet in my house that I can comfortably shxt there, however I reserve my right to shxt in a public toilet (so that more people get the smell).

 

Again, thanks whoever trying to remind me for the above matter.

 

You are free to keep on the bullshxt to kill this forum, when this forum is die, so as the product.

What an extraordinarily stupid response this is. If a facility is provided in order that you may request a new feature, and you choose to ignore that facility, then why on earth would you expect anyone to take any notice of you; to say nothing about the remarkable lack of manners you choose to exhibit.

I certainly welcome this new release, especially since Insight rarely seems to contribute to this forum these days.

But it is disappointing that a bug I reported quite a long time ago has not been addressed. Has no-one else encountered this problem?

The command "Move Mouse to Tray Icon to xxx" does not work reliably. Here is an example, where I have an icon called xFirefox (renamed using Actual Window Manager in order to provide a work-around to this very problem) in my system tray, and want to move the mouse to it; so I use the command

Move Mouse to Tray icon to xFirefox

being

<MOVE MOUSE TO TRAY ICON Icon="xFirefox" Exact="TRUE" Center="TRUE" Left="0" Top="0"/>

and get this result:

Of course, the mouse should have been positioned one icon left. Please note that sometimes this command works correctly.

This is a user-to-user forum. Can't remember when I last saw a contributon from Insight.

Terry, East Grinstead, UK

Do you have any evidence that Insight still exists?

But IMHO OOP really is procedural at its core. It’s just that they hide blocks of procedures in these things called objects. It’s more just a uniform way of interacting with these blocks and .NET is just a huge library of ready made code one gets to tap into.

I don't think I agree with this.

Consider a procedural method of processing customers, where one simply starts at the top and plods through the code, dealing with customers according to their needs, restarting at the top for each new customer. Conceptually, a customer is represented by fields in one or more tables, and processed by any number of functions, e.g. add, modify, delete, report, archive.

Now consider an OO system where one might very easily decide to create a new customer object instance, perhaps asynchronously, for each of several customers due for processing. Now that seems to me an entirely different model. Conceptually, a customer is represented by its object instance, therefore appearing as a black box to the outside world, with selected methods and attributes made public as the designer sees fit, e.g. add, modify, etc.

Further edit, Sunday 6 November 2011, 00:06: I have it working now! However, it seems that I must locate this new macro (an adapted version of { DateTime Example - Span of Days }, within the PGM file macro file. Is that essential? It would more appropriate in a category of my own large 'FULL.MEX' file, with all my other macros, but it doesn't run successfully if I do that. I tried using the Macro Filename (Optional) box (which I normally leave empty), but that didn't help.

Terry, East Grinstead, UK

I can't see any reason why you can't simply paste the code as desired. Of course, the original macro makes calls to several others, all of which use values in the registry that were originally set up when you installed the product. I don't see that any of these values are needed, but you'll have to work out alternative locations and/or alternative methods in order to circumvent them.

I personally recommend using AutoIt (which is one of the script languages supported by MEP)

AutoIt

because it has the most comprehensive set of user-developed functions (50) for working with Internet Explorer I have ever seen.

Mind you, the amount of work involved to understand and learn the supplied functionality would be prodigious, although getting it to work with MEP would be quite easy.

In the PGM Library, which you can now download for free and which contains source code that is now available to you, is a function

{ Date Time - Span of Days }

which appears to meet your needs.

Are you using the latest version? The change log for v 4.2.1.1 says "17. Optimized the 'Split String' command.

Actually, the current version is v4.3.0.1!

That was my guess but I'm not certian. I do use the reg in my macros so I don't know if it's MEPs access or if it's coming from my macros.

Well, I'm certain it's not my macros! These macros are centuries old, and I've never seen these errors until very recently. And it happens with any macro.

Yes I have many times but it's always reading preferences. I reported it to ISS some time ago as a bug.

I assume these are the preferences that are stored in the registry? I know my machine has a few problems at the moment, none of which I have been able to resolve. This is why I'm currently busy working on a complete reinstall. And it's so much fun!

That must be one of the few errors I haven't had, so can't help I'm afraid. Anyway, I'm still using XP Pro.

 

Based on my own experience of obscure intermittent errors with ME Pro, one guess wouold be a timing issue. If so, almost impossible to pin down unless a clear association emerges with some other process occurring around the same time. Sometimes a hitherto reliable macro will suddenly either fail to run, generate errors, or crash. Although occasionally I've apparently fixed such issues by adding (or increasing) delays.

I should have said these error messages are not macro error messages, they seem to be directly from Macro Express Professional itself. They are occurring about once in 3 macro executions, and they appear for any macro. I have reinstalled MEP, but this had made no difference. I'm hoping someone from Insight will read this and comment.

Has anyone seen this before?

From time to time when running MEP macros (and by no means every time I run a macro), I get 6 error messages which I have to dismiss by clicking on OK for each:

SetPrefString: Error writing to preferences: SetPrefString (this appears twice)

SetPrefInteger: Error writing to preferences: SetPrefInteger (this also appears twice)

SetPrefBinaryProc: Error reading binary from preferences: SetPrefBooleanProc

ClosePref: Error: ClosePref

I do have full read/write access to the HKCU Macro Express 4 key and all its subkeys and values.

I'm on Windows 7. Anyone know how to make a macro that is activated when new Windows Updates are available?

Try this - you may have to experiment:

Assume the macro you want to run is called M1

Using the built-in Windows 7 Task Scheduler, create a new scheduled task:
Trigger: Begin the task: On an event
         Basic
         Log: System
         Source: WindowsUpdateClient
         Event ID: 1

 Action: Start a program
         Program/script: C:\Program Files (x86)\Macro Express Pro\MeProc.exe /AM1

As you can see, there are a lot of trigger log values, and Sources, and Event IDs. I've simply taken a guess that this may work.

Let me know.

What's wrong with using the DOS method you describe, but prompt for the specific criteria you need to apply, as in:

Variable Set String %tChar1%: Prompt
If Variable %tChar1% Equals ""
 Macro Return
End If
Program Launch: "cmd.exe" (Normal)
Parameters: /c dir %temp%\%tChar1%*.mus /b /-p /-w >%temp%\inmain.txt

<VARIABLE SET STRING Option="\x01" Destination="%tChar1%" Prompt="Enter character to filter against" Mask="FALSE" OnTop="FALSE" Left="Center" Top="Center" Monitor="0"/>
<IF VARIABLE Variable="%tChar1%" Condition="\x00" IgnoreCase="FALSE"/>
<MACRO RETURN/>
<END IF/>
<PROGRAM LAUNCH Path="C:\\Windows\\System32\\cmd.exe" Mode="\x00" Parameters="/c dir %temp%\\%tChar1%*.mus /b /-p /-w >%temp%\\inmain.txt" Default_Path="TRUE" Wait="1" Get_Console="FALSE"/>

Can you provide the macro code (or relevant part thereof) please?

Is what you're asking for the same as counting all the files in a given path? After all, in Explorer you can filter out unwanted file types, leading to a different result.

Here's something to get you started. Please note I wrote this in MEP, so it's possible, but not likely, that I've used commands that are not available in ME3. In any case, you will have to change the variable names to the ME3 standards! All variables are integer.

You need to adjust for the following situations:

- My 3 monitors (1280 x 1024) are arranged: #3 on the left, #1 (primary) in the middle, #2 on the right. This means that my screen coordinates are:

  #1) -1280, 0  to   -1, 1023
  #2)     0, 0  to 1279, 1023
  #3)  1280, 0  to 2559, 1023

- Yours are probably different, so you need to change lines 5 - 13

- I haven't bothered with determining whether the current window is maximized or not, so its final state is restored

- I assume all monitors have the same width

Variable Set Integer %nScreens% to 3 ' set this to the number of monitors; if other than 3,
                                    ' you'll have to add or subtract the conditional logic in lines 5 - 13.
Variable Set Integer %nWidth%: Set to the Screen Width
Variable Set Integer %nLeft%: Set to the Current Window's Left
Variable Set Integer %nTop%: Set to the Current Window's Top
If Variable %nLeft% Is Less Than "0"
 Variable Modify Integer: %nLeft% = %nLeft% + %nWidth%
Else
 If Variable %nLeft% Is Less Than "%nWidth%"
   Variable Modify Integer: %nLeft% = %nLeft% + %nWidth%
 Else
   Variable Modify Integer: %nLeft% = %nLeft% - %nWidth%
   Variable Modify Integer: %nLeft% = %nLeft% - %nWidth%
 End If
End If
Window Restore: <Current Window>
Window Reposition: <Current Window> Position: %nLeft%, %nTop%