Re: xFx How-To #2: creating a simple xFx plugin

[Stuart Booth]

On Sat, 6 Mar 2004 12:25:27 -0000, "Edward Pearson"
<<a
href="/group/xAP_developer/post?postID=gt35arZ33MpadQz_zUlS2pfAeH1plIrjQQXt10LiBU9lGANIhMFL6UueqAIY_XZxEzlTKoGnkhgvzIpp5w02Z_Tv-8pQBYDQUd27eA">edward.mailgroup@b...</a>>
wrote:

>1) what runtime environment(s) should I use? The versions of console
and
>service on your site look quite old - are they up to date?

No, they're not (yet). As you spotted they are indeed old as I'd been
putting bits into the GUI version when time allowed.

One of my tasks for this w/e is to update these in fact - but I've
been busy watching the F1 quali. this morning so I've not started that
job yet.

>2) you seem to be saying that the best runtime to use for a GUI plug-in
is
>currently the slim connector - should I download that one and throw
away the
>slim specific parts (I've not got a slim)?

The GUI runtime is definitely the best to use, but it also requires
more (and entirely optional) work from you to get the best results. In
its most basic form it will just present information, no more, just
like the console version. But if you decide to put the extra effort
into the plugin the GUI runtime has mechanisms that can help expose
that work.

For instance, the configuration dialog for the Slim Connector is very
specific for the connector and comes from the Plugin and not from the
GUI runtime shell. There is a very empty config dialog that the
runtime provides but it is mostly clueless about the capabilities of
the plugin module so it is up to the plugin module to provide that
when the runtime asks for it.

Secondly you can 2x click items in the GUI's display and view much
more detailed information on the events it outputs. In the
SlimConnector these include xAP messages that are sent/received. They
could equally well be error messages (such as displayed by Viewer).

The console version just ignores all this extra stuff. The service
version could log the basic output to an event log for example.

Currently the only way to get the GUI shell is to download the
v1.2.9.3 xFx code and liberate the runtime from the Slim Connector.
This just involves changing the name of the EXE and the .exe.config
file, and deleting the SlimServerConnector.DLL from the Plugins
directory.

However you'll want to get this all working in the debugger I suspect,
so you'd be better off with:
1) the GUI runtime source in your project file, which you set as the
startup project (I need to upload this first!).
2) a few little custom tweaks to the runtime's .config file so that it
can find your plugin DLL module.
3) setup a post-build step on your plugin DLL module(s) so that it
copies the DLL file to a slightly different location for the runtime
to find.

Step 3 above is a slight pain that I haven't entirely solved. Assuming
you use VS.NET:
1) Properties on the plugin DLL module
2) Go to Common Properties/Build Events
3) In the Post-build Event Command Line option I put in something like
"copy <modulename>.* ..\" - this copies the DLL and PDB
files from
...\Plugin\bin\debug to ...\Plugin\bin, and works for release builds
too.
4) In the xAPGUIRuntime.exe.config file from the GUI shell's
development project add the lines:

<add key="xAPPluginsRootDirectory"
value="H:\xAP\Plugins\EchoTarget\bin\;" />

5) If you want to load multiple plugins all at once, change the value
into a semi-colon separated list and setup all plugin modules as
described above.
6) Make the plugin module a dependency of the GUI runtime project so
that when you build/run the GUI runtime it automatically builds its
dependent plugins. These then automatically get copied to where it
expects to find them, and hence get loaded automatically when it
starts, all by hitting the run button in VS.NET.

It sounds painful, but it isn't really, and saves a lot of manual
copying around I find. All I then have to do with the xAPGUIRuntime
project in my development file is alter the path in that key listed in
step 4) above and I can totally reconfigure the runtime (be it the GUI
or the console version) with whatever plugins I want to work with.
Very easy.

Phew, that got long!!

>3) can you please reveal the identity of the "few extra lines of
code"
>needed to get around the "slight buglet in the GUI plugin
runtime" - you
>tease.

Errr, actually I just fixed the bug in the runtime. The "few extra
lines of code" was theory. I'll have to try it to see that it does fix
it. I'd be better off getting the full source up for you to use
yourself, frankly.

Still game for it despite all that? d:-)) Once you've done it once I
think it kind of makes sense and isn't a big problem.

S
--
Stuart Booth <<a
href="/group/xAP_developer/post?postID=FV65g5pld1uItOLkT32jRl2hzTfpoOYpTXly2RP2dBMVBm2uT0D6-yLz76pwL4ukzlYRe-YxyZk1zV0zWozZLWc">stuart@x...</a>>
xAPFramework.net - a xAP software development framework for .net

<a href="http://www.xapautomation.org/";>http://www.xapautomation.org/</a>
<a href="http://www.xapframework.net/";>http://www.xapframework.net/</a>