Recording and Replaying ActiveX Controls

[rdog]

Is anyone aware of a scheme to record events to your application and then replay them via ActiveX or any other MS/NICVI tools?

My initial thought is something like a Microsoft Excel record macro feature, but applied to the application I am making. At the very least I would need to create an ActiveX server for my app then record the events myself when desired by the user. To playback, I would have to create an ActiveX controller for my app and write out code for the events and compile a script using the CVI ActiveX server to accomplish all of this automatically.

It seems like ActiveX is the best solution, but has anyone heard of implementing such a scheme with ActiveX...because the thought of creating our own home grown record macro feature is not comforting.

[Scott Y]

Hello,

If you need to playback your recorded macros from another application, implementing an ActiveX server in your CVI application will certainly be the best approach. You can find more information about creating ActiveX servers in CVI in the tutorial titled Building ActiveX Servers in LabWindows/CVI.

If you will be recording and playing back this macro in only CVI, ActiveX may not be necessary. You should be able to set a "record flag" and in each UI callback in your application record that the button was pressed, or what other action occurred. By keeping track of which callbacks occurred and their arguments you should be able to play back the same operations.

Unfortunately I am not aware of any sample code for this type of application, and I was not able to locate any in our example databases.

Scott Y
NI

[rdog]

Scott, Thanks...I figured as much. Would you care to comment on this scenario...

An application (created by LabWindows/CVI) controls a rack of instruments to test a UUT (not too uncommon of a setup). All I/O is handled by switch matrix and NIDAQ controllers. Would it be better to write separate applications for each instrument (stand alone executables with a GUI) and have a high level Executive control these apps via ActiveX or encapsulate the instrumentation into the Executive?

For the record/playback feature that we desire out of this Executive...it seems like the former option would have more flexibility and interchangebility. If I'm using IVI, either option seems to suffice. But I guess the question is, why create my own interface when ActiveX is specified and is (we hope) here to stay for a while?

Finally, if I do opt for writing seperate apps and using ActiveX...will the context switching between say 10 or 12 applications effect performance on a modern PC (i.e. 2.5GHz, 512MB Ram) running Windows XP? Thanks, Erick

[Scott Y]

The question of if it is better to create separate ActiveX servers for each of your instruments instead of building all of this functionality into a single executable really depends on what is most important in your application.

These are the advantages I see to creating ActiveX servers:

1. Each server can be automated by many different development environments such as LabVIEW, CVI, Visual Basic, C++ and any other language that supports ActiveX.

2. Each server can also run independently of the others. This will allow each server to run as a stand alone application if you design each server that way. This may make developing future systems quicker.

I see these as the disadvantages:

1. Increased overhead. Adding the COM layer certainly will not make the program run faster, and it might slow it down. This will probably not be noticeable unless you are really pushing your computer.

2. Increased complexity. Adding the code necessary to implement an ActiveX server will make your code more complex to write.

If you think the two advantages above are important enough that some (very minor, most likely) decrease in performance and increase in development time are acceptable, then I would suggest creating separate ActiveX servers for each instrument.

If the disadvantages sound like they may cause huge problems, then I would suggest creating a standalone executable.

Scott Y NI

[rdog]

Scott, Thank you...

I was hoping to get one more question out of you.

Is my ActiveX server the actual application, or is it a wrapper around the app with an interface to outside world (using COM)? For example, if I have a bunch of code that already exists and I want to create an ActiveX server out of it...is that redundant? If so, does my application communicate internally using ActiveX?

Finally, at a higher level, I can create applications from ActiveX controllers, correct? So if all of my instruments had ActiveX servers, they could appear inside my high-level Executive application as if they were implemented within it...am I on the right track?

Regarding advantages and disadvantages above...my group has already gone through the disadvantages of not having a standard interface. The overhead of implementing ActiveX seems easier (at this point) to swallow than continuously debugging a poorly written interface.

[bilalD]

You can also create Activex servers that are DLL's. So everything runs in-process, so you don't have the overhead associated with marshalling data across processes. Loading a DLL has alot less overhead than starting a process for an exe. You can implement a server that is multi-thread safe (refer to the building activex server document for information about the threading model that COM supports) to make the application as concurrent as possible. The threading models in COM can become complex though.

You can see examples of CVI activex servers under ..\CVI\samples\activex\servers

[rdog]

I don't mean to prolong this thread too far, but back to the "record macro" feature I was talking about. Is it possible to have an ActiveX Server macro in VBA...meaning when I finished recording, what is the best format to save it in and is there another ActiveX server that can do this for me? I don't want to create a new scripting language and VBA seems to have the simplest interface. It would be nice if my application could manage and run the macros itself (like Excel).

[bilalD]

Recording scripting macros is a feature pretty specific to the specific enviornment for which the macro is being recorded. (as far as I know). So recording an excel will generate excel specific code. I dont know if the tool is generic enough to generate code for just any activex server out there. You might refer to the documentation that comes with Excel to see what kind of limitations their macro recording capabilities have. The only time I've used this is to automate tasks in Excel (or any other packahe that supports macro recording).

But I'm sure you can write VBA code yourself for controlling the activex server that you create. And that run that VBA code via the Excel automation interface. or write a vb script file, and run the script via command line using cscript, which uses te Windows Scripting Host. Check out the following link for more information about WSH

http://www.microsoft.com/technet/scriptcenter/guide/sas_wsh_qlcc.mspx