Restore Variable Crash

[Rustywinger]

So I engage a Macro that has worked flawlessly in all versions of MEP prior to 4.1.1.1

 

I assume the variables are empty at this point, since I just started MEP

 

The first command in the first macro I use is to restore variables.

 

Crash-a-roonie.

 

I turned off the restore command, the macro then works. However, the macro needs information saved from previous executions to work properly.

 

I experimented with the restore and concluded that it is only crashing when text variables are being loaded. It will run if it just loads integers.

 

 

I further experimented by creating a macro with only 'Restore all variables" in it.

 

Crash-a-roonie.

 

I added a "Save all variables" to run before restoring, and that worked.

 

So I guess that if the first command MEP executes in a session is a restore before anything has been saved, it crashes.

 

 

Now, I know that save/restore variables isn't the best way to be doing this, etc etc, but this has worked flawlessly before and I really don't want to have to rewrite all my macros at this point in time for alternative methods to a function that clearly should be working.

[Cory]

You need to report this to ISS as a bug.

.........................................................

If you notice in the release notes they attempted to fix the var save/restore bug but evidently they caused another. They need to know about this ASAP.

 

I sure am glad I don’t use Variable Saves

[Rustywinger]

You need to report this to ISS as a bug.

.........................................................

If you notice in the release notes they attempted to fix the var save/restore bug but evidently they caused another. They need to know about this ASAP.

 

I sure am glad I don’t use Variable Saves

 

Rub it in, old man! ;-) lol

 

I actually fixed it by... saving variables before restoring them. Most macros already end with a save so it is just a redundant command.

 

And feel free to report this bug. I don't care to look into it now that I have things working... relatively!

[Cory]

Bha ha ha ha!

...............................

[Grasps for his oxygen mask] cough, sputter, Ha!

 

I report waaaaay to many bugs as it is and to be frank I could care less too!

[rberq]

I actually fixed it by... saving variables before restoring them. Most macros already end with a save so it is just a redundant command. And feel free to report this bug. I don't care to look into it now that I have things working... relatively!

Well, now, not to quibble, but you didn't FIX it, you found a work-around. And if a macro NEEDS the variables from previous macros, adding a SAVE before your RESTORE will simply wipe them out because they are all empty at the beginning of the macro.

 

Actually I don't care any more, either, as I have converted to stowing the values in environment variables. If I get too many large ones, I suppose I'll have to switch to storing in files due to limited memory. What other techniques do you guys use? Using files sounds like it would be slow.

[Cory]

Ha! I was just writing about this in the other thread.

..........................................................................

Here's what I wrote:

BTW I rarely use files to save settings and prefer to do it like most Windows programs do and that is to use the registry. The only INI files I use are settings for distributed macros and those are saved with the macro folder on the network where everyone uses the same INI and MEX file. But even then the individual user preferences are saved locally in the registry so they can all personalize their macro experience.

 

I’ve mentioned it before but worth mentioning again because it’s a cool concept IMHO:) I now create portable macro packages. I create a folder for the macro and insert all the supporting files including INIs in this folder. Then in any macro that needs to use any of these files my first couple commands get the path of the MEX file and look in there for specific INI, log or supporting scripts or executables. This way I have a simple sandbox for development and none of my paths are absolute. EG in the INI file I might have an item “Client Folder Path” and in the dev folder I can point it to a sample copy of the client’s folder to test my stuff. Then when I deploy the MEX when run the macro will pick up the proper clients path from that INI file. And I didn’t have to change a thing! Also if anything ever moves I can usually change it in one place. EG if they move the client’s file archive to a new server.

[rberq]

Cory, you have mentioned INI files a few times, and I'm totally ignorant of them in regards to Macro Express. Does ME do something special with INI files? Or are you just saying you store information in files whose filetype is INI -- but could just as well be CFG or TXT or XYZ????

[Cory]

You need to check out INI files!

............................................

You will love them. All they are is text files but they have a defined structure. They were what was around before the registry and it’s structured very much like it. You have sections, parameters, and values. Section headers are bracketed [Like This] and parameters are paired, one to a line, with values using an equals sign. Also you can comment. Might look like this:

[General]
Username=Cory Jackson
DoB=08/19/1968
Last directory used=C:\Users\Cory\Desktop\
[email settings]
Smtp=mymail.bluepointdesign.com
Sending address= cory@;This is the replyto address.

So you can have thousands of values in one file. Now the difference is that since they’re old as the hills almost every programming language has a way to access them and parse out the values and write values back to them automatically. I could save all this data in a text file in some structure but I would have to create some means of identifying the locations and parsing out the data. With MEP you simply tell it “go to section General, Parameter Username” and it instantly sets your variable to “Cory Jackson”. No muss, no fuss. What’s more once I can tell MEP to write back to the INI “Fred Parker” in one deft command. And if I have a comment like in the last line it will not mess with it. That’s the bit after the semicolon. And if tomorrow I decide I want to add a new value like counter of how many emails were send to the General section a new line will magically appear. Again with one command.

 

You could use your own home brewed text file method (I’ve seen some people who use hundreds of individual text files, one for each value) but why would you? This is much cooler. I know it's very Windows 3.1 but they're very useful in some applications. You can read more about them here.

[rberq]

Thanks for the primer. I was familiar with INI files but just never noticed how to use them in SET and MODIFY variable commands. I have been so busy with ME I have never taken the time to go through every ME command variation, so I keep missing out on neat things like this.

[paul]

I've mentioned it before but worth mentioning again because it's a cool concept IMHO:) I now create portable macro packages. I create a folder for the macro and insert all the supporting files including INIs in this folder. Then in any macro that needs to use any of these files my first couple commands get the path of the MEX file and look in there for specific INI, log or supporting scripts or executables. This way I have a simple sandbox for development and none of my paths are absolute. EG in the INI file I might have an item "Client Folder Path" and in the dev folder I can point it to a sample copy of the client's folder to test my stuff. Then when I deploy the MEX when run the macro will pick up the proper clients path from that INI file. And I didn't have to change a thing! Also if anything ever moves I can usually change it in one place. EG if they move the client's file archive to a new server.

I use a simpler ( IMHO ) approach to avoid using the Variables SAVE and RESTORE commands:

- I have a folder, e.g. D:\MacrosPro, in which may be located a file called MacroParameters.txt, which looks like this:

t,98,Value1
t,99,Value2
n,99,123

This file is created by whatever "program" is calling MEP, as in:

 "E:\Program Files\Macro Express Pro\MeProc.exe" /AMyMacro

which, when Variable Restore is used, is equivalent to

 "E:\Program Files\Macro Express Pro\MeProc.exe" /AMyMacro /VT98:Value1 /VT99:Value2 /VN99:123

 

- I have a macro called MacroParameters which is called instead of doing a Variables Restore command, and contains this code (currently works only for string, integer and decimal values):

If File Exists: "D:\MacrosPro\MacroParameters.txt"
  ASCII File Begin Process: "D:\MacrosPro\MacroParameters.txt" (Comma Delimited Text (.csv))
 Switch( %tContents[1]% )
 Case: t
   Variable Set String %t[%tContents[2]%]% to "%tContents[3]%"
 End Case
 Case: n
   Variable Modify String %tContents[3]%: Convert to Integer (%n[%tContents[2]%]%)
 End Case
 Case: d
   Variable Modify String %tContents[3]%: Convert to Decimal (%d[%tContents[2]%]%)
 End Case
 End Switch
  ASCII File End Process
  Delete File/Files: "D:\MacrosPro\MacroParameters.txt"
End If

 

<IF FILE EXISTS File="D:\\MacrosPro\\MacroParameters.txt" Search_Path="FALSE"/>
<ASCII FILE BEGIN PROCESS Filename="D:\\MacrosPro\\MacroParameters.txt" Format="CSV" Start_Record="1" Process_All="TRUE" Records="1" Variable="%tContents%" Start_Index="1"/>
<SWITCH Variable="%tContents[1]%"/>
<CASE Value="t"/>
<VARIABLE SET STRING Option="\x00" Destination="%t[%tContents[2]%]%" Value="%tContents[3]%"/>
<END CASE/>
<CASE Value="n"/>
<VARIABLE MODIFY STRING Option="\x04" Destination="%tContents[3]%" Variable="%n[%tContents[2]%]%"/>
<END CASE/>
<CASE Value="d"/>
<VARIABLE MODIFY STRING Option="\x05" Destination="%tContents[3]%" Variable="%d[%tContents[2]%]%"/>
<END CASE/>
<END SWITCH/>
<ASCII FILE END PROCESS/>
<DELETE FILE/FILES Path="D:\\MacrosPro\\MacroParameters.txt" Progress="FALSE" Recurse="FALSE" Permanent="FALSE"/>
<END IF/>

 

Works well.

[kevin]

I further experimented by creating a macro with only 'Restore all variables" in it.

Crash-a-roonie.

When Macro Express Pro crashes, it brings up a separate program, the ISS Bug Reporter. The Bug Reporter collects information about the crash and offers to send it to us using one of 4 methods.

 

Please, please, please, when you get a crash, send us the information. The crash report includes information about what the program was doing when the crash occurred.

 

"But," you might say, "it is easy to duplicate the problem. Just try it." Well, that doesn't always work. Often you get a crash and we don't. (Why do you think the problem slipped past our Q/A people? )

 

Once you set up the ISS Bug Reporter it is easy to send subsequent crash reports. Please help us improve the quality of Macro Express Pro by sending us the crash reports.

[rberq]

I use a method somewhat like Paul's, which converts the standard 99 ME3 N and D variables to text strings, appends them comma-delimited into one T variable, and stores the composite T variable into a single environment variable. That's the "save variables" macro. The 99 T variables are saved each into its own environment variable -- just because I didn't want to worry about what delimiter could be used that would never be in any of the T variables. The "restore variables" macro does just the reverse, retrieving the contents of the environment variables and converting strings back to N and D variables. It is surprisingly fast.

 

Actually I have several sets of these save/restore macros, using different environment variable names. That's so that different sets of application-specific macros can operate concurrently without tripping up one another.

 

The only worry is that I might exceed the available storage for environment variables. The other disadvantage is that now, with ME Pro having arrays and user-created variable names, the save/restore macros would have to be modified every time I define a new variable.

 

I do like the idea of passing initial variable values into macros via an INI or TXT file, and I can already think of several places I should have used that technique, had I been smart enough to invent it like you guys did.