paul

Here the trick is to examine that part of your macro that contains the new code using the Direct Editor, then write a new macro that inserts this code into your 600-700 macros. Joe and I use this technique to distribute our PGM Library.

"Some sort of way". How do you expect anyone to be able to answer such a vague request? If you can be more specific about what you want to do, then perhaps someone will be able to help you.

I think you're trying to get your macro to "remember" the row it used last time it ran. If that's the case, you'll need to "persist" the row number into a file, or preferably into the registry. At the beginning of your macro, you simply read in the registry value, increment its value by 1, and store the new value back into the registry. You'll also have to work out how to reset the registry value to 0 when you want to start again at row 1.

2. I want a loop to be exactely 150 seconds. The thing is that by adding up all the delays to result 150 seconds dosent work, as it seems that even a click is somehow taking up time. How can I use such a delay variable, that change in such way that the total loop will result in exactely 150 seconds. Right now the loop is allways delayed by about 0.5 - 1 second per loop, and my only hunch is that the mouse click, and drop plus the only 2 mouse positions that I got in the loop are making this extra delay. It's pretty well impossible to guarantee a period of exactly anything if you'tre working in milliseconds! As you don't have control over other processes that happen to be running on your machine, you cannot guarantee the accuracy of whatever timing mechanism you're using; for example, you cannot possibly determine when a garbage collect operation is about to occur. That's why a given process can take different times to run from one invocation to the next. My best suggestion for you is to store the time at the beginning of a loop, then have your macro check that it's not later than that original time plus 150 seconds, then have your macro wait one second, then loop. If you use the timed delay feature, you're restricted to working in seconds, but you're not taking up any CPU; otherwise you can set a delay in milliseconds - and the CPU will remain fully utilized (but my earlier observations on timing accuracy still hold true). 3. How can I alt-tab between programs of the same type. What I mean is, when the macro needs to be done, it will alt tab from my current window to the window it must do the macro. This I have succeded by using the Activate or Lunch, but I have 2 clients of the same thing, so they are having the exact name. What I have observed is that it allways pick the last client I was in. How do I make it pick only 1 specific client? (My clients are named for example "client" and "client" and because the name are the same it just pick up the last one I was in". Also what variable I must use so that after the program is activate and macro is running, when the macro is finished, it will alt-tab again to the last window I was in (for example internet explorer if I was there before the macro switched to "client") You'll need to work with window handles in order to achieve this. ME doesn't offer this level of granularity - you'd have to write something external (not difficult) to do this.

You can schedule a macro to run after a specified number of minutes of idle time (it's called Time Out in ME for some strange reason). I've experimented with this a bit and am not convinced it's reliable, but the feature does exist.

You can use the Mouse Locator tool to move the mouse to the desired pixel manually and see what the value of this pixel is (use the first value, not the second). Then insert this value into your code.

While I haven't understood your requirement completely, I can tell you what the PGM Variable Management functions offer. These allow you to have multiple sets of 99 string variables, not one or more sets of more than 99 variables. Of course, with clever registry manipulation you could have as many variables as you want, e.g. Read RegValue1 into T1 Use T1 Read regvalue2 into T1 Use new T1 etc. Not elegant perhaps, but it could be done.

Are you familiar with the registry keys HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce and HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Runonce? You can use these keys to store the names of one or more routines that must run once when you next reboot.

To ol3ears: I posted a private message to you concerning this message. Did you receive it?

As far as the Save and Restore Variables in PGM Library are concerned, we've effectively extended the number of sets of variables that can be addressed to 16. Thus you could do up to 16 Variable Saves (nested), and the same number of Variable Restores, and it would all work. As far as ME is concerned there are only 2 sets of variables, the ones you are currently working with and the ones you saved when you did a Variables Save command. As far as subroutines are concerned, both Joe and I tend to use variables 1 to 10 (and sometimes 1 to 20) as "temporary" variables - by this I mean that in any subroutine I can readily change these variables as I "know" that none of the higher-level macros have stored anything important in these (and by "know", I'm simply referring to our own internal standards). But, most important, write remarks in each macro to document which variables are used and for what purpose.

I'm going to take a close look at this - but first could you please increase the sizes of the labels and text boxes starting with "Search Pattern 1", plus the command buttons shown under "Set Control Color". I run at 1600x1200 with Large fonts, and your boxes don't reveal enough information!

I created this macro: Variable Set String %T1% from File: "Foccode.txt" Variable Modify String: Save %T1% to Clipboard Clipboard Save Text: "Foccode1.txt" Here is the relevant part of my folder listing, before and after running this macro: BEFORE Foccode txt 341,291 13/07/1999 00:02 AFTER Foccode txt 341,291 13/07/1999 00:02 Foccode1 txt 341,291 15/05/2005 18:36 So it works fine for me - I'm using v3.5c - build 1.

When I get home tonight (Oz time) I'll take a look at the maintenance stuff I built for our PGM Library, and give you the details of what's relevant for your needs. Later OK, now that I've had a chance to look, I'm starting to remember just how complex this stuff was to construct! My export suite allows me to export currently selected macros (I have a function which allows me to select macros in various ways), or all visible macros, or all macros, or a specified number of macros starting from the currently selected macro. Furthermore it allows me to retain the current categories and subcategories of the exported macros for use in the target library. It uses a concept of "core macros" which are sent to a temporary export library, to which control is subsequently passed during the export operation, and switches libraries several times according to dynamically passed parameters (i.e. I can define how many switches and what macro is to start in each of the switched-to libraries). It took a great deal of time and effort to construct, and is not so well documented <g> (it's really for our own internal use). Since the original author seems to have constructed his own solution, it's probably not of great interest here for me to go into more detail.

It's actually relatively easy to block most of the keyboard (except for ctrl-alt-del and a few esoteric Alt-key combinations). However, this has unfortunate side-effects, in that it stops all text type operations, and maybe some others too. It's therefore not very useful - which is why we've not implemented this.

You are right, I have done that but with over 400 machines this is very slow and the timing issue of the connections and windows made this a very bulky, time consuming process. It was my hope that ME could accomplish without using any external apps. Just wasn't meant to be. Thanks. Why not use ME in conjunction with this free and powerful utility? http://www.sysinternals.com/ntw2k/freeware/psexec.shtml

You can't run a second macro until the first has finished, so your approach won't work. One idea might be for your macro to check for the existence of a particular file; when the file exists (or ceases to exist), your macro ends. Then all you have to do is create or delete this file via explorer or any other method, and your problem is solved.

Having done some complex work with pixel detection, I have observed that upgrading a video driver (or, even worse, changing the video controller) can result in different colours, and different pixel locations. For example, I wrote a complex script to detect a particular tray icon, both in terms of its size and the pixels being used. When I updated my video driver, the icon sizes all changed from 22 x 22 to 24 x 24! And colours were different - what was previously, say, 12345678 was now 12345679! Of course, the new command "Move Mouse to Tray icon" makes all my code entirely redundant.

Well, the logic is located in { PgmSvr - Process }, but, as with all "system" functions within our library, this function is password-protected.

All you can do is use the File / Export / Output Macro Information using the Name and Text options, then do a textual compare on the two versions. While not perfect, it's not too bad. I wrote a macro to output all macros to a text file (easy enough to do), as I needed to do this quite often.

I've also asked for such a feature back when this forum was on a newsgroup (global key down/key up events instead of just tied to win/alt/ctrl/shift) as i have a program or two that utilizies multiple key combinations and just typing the keys is not sufficient. I was referring only to those keys Windows itself recognizes as "special" keys, i.e. Win, Alt, Ctr and Shift. If you want to treat other keys as modal (in the sense that they change the meaning of whatever other key is pressed at the same time), you'll have to provide a really low-level keyboard handler (in other words it will become THE keyboard handler for the whole of Windows) - which I imagine is probably impossible to achieve. A high-level keyboard handler has to abide by the rules imposed from below; some keys are not even passed on by Windows (e.g. most Alt combinations).

If you already have software to create and read your tables, e.g. Microsoft Access, Excel, even SQL Server, then you can get ME to drive that software, thus effectively giving you what you want. It's not difficult to write a macro that opens an Access table and returns some data. For Access and Excel, this involves learning some of the object model stuff. For SQL Server, it's simpler - use the osql utility via ME.

Will your addition allow calling previously written VBA Word macros? Yes, easily. In fact one of my works in progress is an Office-capable module, dealing with Excel, Word, etc. Running a pre-existing macro is very straight-forward. This could equally well be done in VB Script, or presumably JScript, by creating the Word object, then linking to existing macros. So, with some tinkering, Floyd's approach could be tailored to handle your requirements.

Windows does provide API calls to allow a folder to be monitored. I have a VB6 program that allows you to nominate a specific folder; when its contents change, an event is raised - at which point a suitable course of action can be programmed. In itself, this has little to do with ME. However... in our PGM Library, I have created a VB6 interface such that adding the functionality you require would not be very difficult. Assuming that I'd written the relevant program module, and assuming that you'd bought the PGM library, you'd simply run a PGM function (i.e. a ME macro) with a specified folder name; whenever anything changed for that folder, the PGM function would receive notification of the type of change (and could obviously provide the file name, etc.), at which point your controlling macro would take the appropriate action. Of course, at this stage the PGM library does not contain this additional functionality, and you have (probably) not bought it <g>!

scripts are easier to understand, e.g. %PIXEL_COLOR% instead of %N1% This would of course require the entire interface to be rewritten - I'm sure Insight Software would be delighted to do this for you.

I suggest two possible ways that MacroExpress people show implement this facility: 1) Allow export of the Macro Express script in text form (I mean the readable scripting format not the Direct Script). Then I can use Beyond Compare to compare text files. You can already do this in ME - File / Export / Output Macro Information, then untick all options except Name and Text. All your macros will be exported to your specified output text file. I've written a macro to automate this process for exactly the purpose you describe.