Interface To Other Programming Languages

[Les Hazlett]

Hi, I haven't posted for a long time.

 

I have successrully executed other applications from ME, so I understand how to Launch Programs. What I would like to find out is if it is possible to interface to code written in other languages.

 

I am considering an application in which I really need arrays, lists, indexes etc. It would be convenient if I could tie this application into an existing set of ME macros.

 

Is it possible in Macro Express to call a procedure writen in a language like Python or VB, pass it parameters, and get parameters returned to Macro Express? I spent some time searching for various key words here in the Forum but found nothing close.

 

Hope there is someone who has tried this before.

 

Thanks,

 

Les

[MGuyM]

I think the best way to handle something like this is to WRITE the data to a File which you can do rather easily in ME and then when you get to your other application, READ this data into your application. You could then have your Application WRITE the Changed Data to the same File and have ME Read it upon Return.

 

That seems to be the simpilest approach to your problem.

[paul]

I have written a VB server program which interfaces well with ME (it's part of our PGM Library package). It uses the registry to communicate with the server, and I have written it in such a way that new functionality can very easily be added by writing a new VB "DLL". One issue you need to take care of (among several others) is to force ME to wait until your external program has finished processing (I use a semaphore flag for this, again via the registry).

[Les Hazlett]

Thank you both, MGuyM and Paul, for your helpful responses.

 

Paul, I was wondering if the ME macro is actively looking for the semaphore flag. It seems that it would be. If so, does this cause any processor loading concern or is there some simple way to avoid this?

 

Les

[paul]

Here are the comments for the code in question:

Check for completion of process

This is graduated as follows:

For the first 2 seconds, check the semaphore every 50 milliseconds

After that, check every second for a maximum of %N1% seconds

 

The first wait is done using the standard Delay in Milliseconds, while the second (and usually longer) wait is done with the Wait Time Delay 1 seconds command (which uses no CPU). So, no, I don't believe this imposes much of a burden on the system. And timeouts are handled by the second wait which has a user-definable maximum wait period.