[easel] Re: [gme-users] Invoking runComponent from GME Addon

Jonathan Sprinkle sprinkle at EECS.Berkeley.Edu
Thu Dec 8 09:24:16 CST 2005

> Jon,
> I think you might have missed the point a bit. What you are describing
> works just fine now without hacks. The GME gui is event-based, any
> changes to the model database will be updated automatically in the gme
> gui, as the it is catching all the events.

Ahh, I have fallen victim to one of the classic blunders: subscribing to the
digest and not reading the messages as they come in...not to mention not
really paying attention to the subject line. :) I see now why I was so
confused why you thought I had missed the point...because I had envisioned
that Daniel's addon was doing what you describe below:

> The second idea is to make the interpreter, that you want to call from
> the Add-on, an Add-on itself. Then it will be called by GME
> automatically. The Constraint Manager is a similar animal: you can call
> it from the GME gui and it is called by events also.
> Akos

My original version of the GME XML Model Migration was a common codebase
spread across multiple interpreters, and linked in as libraries. I think it
would be possible to have the same function included in two different
interpreters, and have that function build as a static library rather than
two independent dlls...thus, your two interpreters would call the common
invocation function in that library, and just link against it (drastically
reducing your build times, too!). This solves Daniel's problem below:

> Hmm, apparently this is more complicated.  GME now thinks it is an
> AddOn and will not let me run it as an interpreter!
> Ideas?
> Daniel.

If the same codebase is run regardless of whether it is run as an addon or
as a standalone interpreter, this will provide automatic---as well as event
driven---behavior, thus mimicking the constraint manager behavior as Akos
alludes to in another msg.

I have done this separation before but in MSVC 6.0, not in .NET, and it
required some massaging of the include files to know which
"ComponentConfig.h" to include, based on which project I was compiling. 

This is all from memory (grimace) but basically, in the two interpreters
(Interpreter1, and AddOn2, as distinct .vcproj in the same workspace) define
project variables BUILD_OBJ1 and BUILD_OBJ2 which are #ifdef'd to determine
which component config to include. Then, when building the standalone
library's project (Common.vcproj in the same workspace), I think I had to
#undef some variables to be able to use the BON classes in a standalone

If I can dig up those files, I will send them to you (Daniel) for your
perusal...i don't think they will compile (or even close to compile) with
the current version of GME or .NET, but by looking at key include files you
may be able to figure out what I tried to to.

Whew, this has gotten long! :)


More information about the gme-users mailing list