Set "saved" variables externally?

[Rustywinger]

(Greetings gurus)

 

... set a ME variable using a VB application? I am grabbing data from an openbase DB, and currently I just hand it off via the clipboard, it's inelegant and can interfere with other operations.

 

Thanks in advance for any nudges to the general direction that I'm trying to go.

[rberq]

Hand it off by writing it to a dedicated file -- slow and still not elegant, but avoids the problem of other operations using the clipboard.

 

Hand it off via a Windows Registry entry. A bit more elegant.

 

I have tried doing it with a Windows Environment Variable, but couldn't get it to work because the VB application apparently doesn't see the same "environment" that ME sees. You would think Bill Gates would have given us a Windows Global Environment Variable before he ran off to save the world.

[kevin]

You could have your VB program write results to a .mxe file and then use the Load Macro Text File: "Result.mxe" command to have your macro read it. This is the technique used by the example macro in this post: How To: Multiple Field Input Form Example.

 

Each macro command can be represented using 'ASCII' characters. This format can be viewed in the Direct Editor. For example, the macro command Variable Set String %T10% "Test Value" looks like this:

<TVAR2:10:01:Test Value>

The only 'trick' to this technique is to pay attention to the separator character. In this case, it appears after the 'e' in 'Value'. The separator character has a value of 01hex.

 

So, have your VB program write to a file using the ASCII format for macro commands. Then your macro can use the Load Macro Text File command to load the values into the macro. The Multiple Field Input Form Example is an excellent example of how this works.

[rberq]

And if you follow Kevin's suggestion, put comments in the VB program and in the macro until your fingers get tired, because to the next programmer who works with the code it ain't gonna be obvious what you are doing.

[Namino]

Hi,

I'd just thought I'd point out that you could also make a small ram disk for passing variables between MacroExpress and other programs or scripts. Make a ram disk, then save/read text files on it. As far as I know, it's the fastest way to do it and does not wear your hard drive.

I used this free program to make my ram disk.

[Cory]

Namio: Have you done any speed tests between using a physical HDD and a RAMDisk? I'm wondering if there is really any benefit with RAMDisk for small writes since the Windows virtual disk management and hard drive caches often do essentially the same thing. I mean they do write to the drive eventually but the OS caches things like temporary file for quick reads. I suppose it would be easy enough to do a few tests...

 

I've been thinking about this as I am writing more and more Powershell scripts to supplement ME and passing things back and forth quickly can be problematic. I hadn't used RAMDisks since Windows 3.11 but it got me to thinking about them recently.

 

Also is writing to the registry for small amounts basically the same as writing to RAM? I mean the OS has it all spooled up in memory, right?

[rberq]

I don't mean to disparage Namino's idea, it may be great in a private environment that you control. But if you are writing production macros for use on many PCs, the ram-disk software is one more non-standard thing to install and maintain on all those PCs.... If it's not vanilla, somebody's going to be allergic to it.