There are two different technologies that could be used. To actually license the VBA engine would cost money (you'd have to speak to M$ personally for an exact price). This is the setup used in say Office where you effectively have a cut down version of VB embedded in your program. This would mean you could fully script MPLAB with no external programs. e.g. You could write a VBA procedure to use as stimulus at some point. This would be great for all those who know VBA. However, it wouldn't be so fun for the MChip developers. Unless there whole program is written as ActiveX components they would have to port it all. And somehow MPLAB doesn't look like it's all ActiveX. However, a simpler task (which provides almost as much functionality) is too slowly implement ActiveX interfaces for critical parts of the program. Depending on the exact way the program's designed this could be quite easy or quite difficult. Assuming that MPLAB is modular (which it almost certainly is) and they are using a development tool that supports ActiveX (which most Windows tools do in some way) it should be possible to add ActiveX interfaces for some parts. For instance, by adding an ActiveX interface for the stimulus input you could use the existing stimulus systems, write a script to provide stimulus (in any scripting language M$ supports (they've got a real nice extensible scripting engine with M$ support for VBScript and Javascript and 3rd party support for many others such as PerlScriptibly M$ Perl in Win 2000), CobolScript and anything else people want to implement)) or write a full blown ActiveX DLL (in VB, VC, Borland C, Delphi , anything else with ActiveX). Add an interface for output and you can write custom ActiveX interface to simulate the real devices interface. Add an identical interface to the ICD code, write a simple protocol and add a few debugging macros to MPLAB and you can use the same ActiveX controls while debugging. This canb then be the basis of the final products PC interface. Hence, you design one ActiveX interface and you can use it in simulation, debugging and production. Also, by adding an activeX interface for the programming you could plug in your own ActiveX components for handling other components. Obviously ActiveX enabling the whole thing would be #$%$ing fantastic (at least for developers). However, it might not be so fun for the MChip developers I would say. Also, > All this talk about wanted features from MPLAB makes me wanna whip out VB and > write an application. A lot of this can be accomplished using DDE...I'd be >willing to take a crack at implementing these features. Any ideas? > Tim Hamel Don't know about how possible it'd be with DDE. MChip'd have to have a pretty complex DDE interface wouldn't they (DDE was a bit before my time so I'm not really sure). Looking at Universal MicroProcessor Simulator got me thinking about writing an ActiveX enabled simulator. UMPS is great but the interface could do with a revamp and the ability to add your own components via ActiveX would be great (I think UMPS can do this but it doesn't appear well documented and they must be C/C++ DLLs). The only problem with ActiveX is that you cut out non M$ platforms basically (unless you want to write ActiveX for Unix). A better idea would be to write it in Java. Due to M$s seamless JavaBean<->ActiveX integration you could use JavaBeans or ActiveX for the addins with no problems. You might have some speed problems but it'd be cross platform. Also, you could take advantage of the current trend towards embedded Java. I'd certainly be willing to devote programming time to a Java based simulator. Tom. ----- Original Message ----- From: Anne Ogborn Subject: Re: MPLAB desires > > To include VBA would require a reasonably hefty > > ISV license fee payable to M$, I believe, and > > could potentially threaten the free status of > > MPLAB. > > I thought M$ was giving it away for a small fee to > encourage adoption. Maybe I'm wrong.