Status Update -

I've spent over 80 hours in the last two weeks working on the .h files that will be needed to accomplish this.

  >> Ugh, I know the trouble involved in this one..

I'm down to testing and working on a minimalist approach to a plugin. I am targeting using VS2008 C++ Express Edition with mixed mode CLR code.

I've got a plugin working in VS2008 C++ Professional. And have one ALMOST working in C++ Express. It loads, can be config'd (with managed dialogs), but blows up Mach with an infinite error message "ART9991" when I enable it.

A question for Brian/Art that would help me in finishing this:

>>Anything.


About the 4 routines concerning COM automation (DLLGetClassObject, etc) - Does Mach USE COM to talk to the plugin or was this just if the plugin needed COM to talk to other software?

>> Not used at all in the context of the plugin. Mach3 basically asks the plugin for the pointer to the functions like Update() etc.. stores them , then calls them at the appropriate time as declared function pointers.
>> No com is used. The plugin also asks Mach3 for the pointers to its main classes and uses those as the data pointers into the h files. ( thus the trouble as youve discovered ).

To me it looks like Mach does ALL simple DLL calls to the plugin. I have setup 'simple' functions like: extern "C" __declspec(dllexport) void Config()

 >> Exactly, only I used the archaic function decalration such as OneShort defined in the .h files to setup the function as opposed to the __declspec

These all appear to generate the proper DLL exports under examination with PEBrowserPRO.

>> Excellent, I hadnt played at all with iut that way, Once I discovered I could define the return type and have it work, I stopped and used that. ( hence the trouble. )

My C++ Pro code is very similar to the example plugins. My C++ Express code can not access AfxDllGetClassObject, etc. since it does not include MFC headers. I'm trying to get around it by returning S_OK. Any ideas on what I can try? Would some other return tell Mach that I don't need automation and have it skip the other calls? Ultimately, with my mixed mode I should be able to use Managed COM for people that need COM.

>> I think just returning S_OK woudl work, just a case of getting it to compile as I think the interface is totally unuded in the context of a plugin. Though to be honest you
probably know more than I as your fresh into delving into that so much lately.

Thanx,

-Ed

p.s. i will be asking for contributions to my new glasses fund after poring over 17,000 lines of assembly code to check out the structs that I replaced ALL classes with  ;^)

>> I suspect Brian will be happy to pay for the glasses en toto..

Hello All

I would like to play a Little with the sdk, to build a plug-in. Unfortunately I have only VS6 and VS 2008. Does anyone have an idea, when the sdk is working under VC2008?

Thanks

Klaus

Ed, is trying to make it where you can do it in other versions, but he still has a ways to go.

Until then, get you an acedemic copy of VS2003, off of E bay, I got mine for about 60.00.

scott

NEWS FLASH - Latest Update

After 4 days of down and dirty programming including several VERY late nighters I have finally broken through into the world of Visual Studio 2008 C++ Plugin Development.

I have a successful test plugin running that has been compiled using VS2008 C++ Standard. I have also downloaded VS2008 C++ Express and installed it in an isolated virtual machine and expect it to work fine (with some limitations) in that environment.

The source code is targeting three different models of development:

C++ Native using standard Windows calls - working in VS-2008 C++ Express or above
C++ Native using MFC - working in VS-2008 C++ Standard or above (approx $175 to buy compiler)
C++ Native/CLR mixed using .NET 2.0+ - working in VS-2008 C++ Express or above

I have spent the most time allowing for option #3. Getting a mixed mode DLL to work allows for C++ native code for the Mach3 interface and the time sensitive code and the ease of development for configuration screens and the like with .NET style objects. This will allow for powerful and beautiful plugins written on a free compiler (VS-2008 C++ Express).

The MFC version requires tools that are NOT included in the free compiler so you must purchase at least the Standard version.

I am working on final testing of all three models in each environment and am also working on a Project Template to automate the generation of a new project without having to copy and edit a lot of fields in the project environment.

I expect to have a set of testing DLLs of a complete simple plugin ready in about a week that will need to be tested on as many machines as possible. So beta testers will be needed.

I expect to have an install package and preliminary users guide for the development tools by mid-March and then the fun can begin.

Just an update for those that may have wondered if I fell of the end of the earth!!!

-Ed

Ed:

   Thats amazing. Great work. Im not a .net programmer so I probably wont take advantage of that part, but it sounds liek youve nailed down
the pointer issues involved. Way to go!.  Who knows, if plugins are easily attached and a proper skeleton is available, great plugins may result.
There really is an endless supply of idea's out there for plugins, so its an exciting possibility, Ill be watching this one with interest and Ill try it out
on my VS2008 as well.

Art

Art -

I'm not a .NET preacher but when you see how easy, logical, and straightforward it is to do dialog boxes and the like in .NET you will be a convert. I switched to C# (which is .NET ONLY) many years ago for business application development. A lot of my time this past year working with Scott on MFC based plugins was getting MFC dialogs to do what he and I wanted them to do. MFC's addition of so many macros for DDX/DDV and the like makes it hard to find the forest for the trees. I'll post parts of the source code of my .NET solution and I think you will see how clean it is to get data into and out of a dialog.

C++ native is still the best thing for time tight code but when interfacing with the nut on the other side of the mouse, keyboard, and screen .NET is, IMHO, the easiest way to go.

just as a tease - here are two snippets of code. The first one is piInitControl (my replacement of myInitControl). It sets up a persistent modeless dialog box that was totally designed in a form designer (which i personally don't like, but i'm a purist that likes to type instead of mouse).

//---------------------------------------------------------------------
//
//   piInitControl() - Plugin extension of InitControl()
//
//---------------------------------------------------------------------

#ifdef PI_INITCONTROL
#ifdef _MANAGED
#pragma PI_MIX_INITCONTROL
#endif
bool piInitControl()
{
   MonitorDialog^   monitorDialog = gcnew MonitorDialog();

   monitorDialog->Show();

   MG::monitorDialog = monitorDialog;

   return true;
}
#endif

The second snippet is the piUpdate() that fills the X,Y,Z DRO boxes every 1/10th of second.

//---------------------------------------------------------------------
//
//   piUpdate() - Plugin extension of Update()
//
//---------------------------------------------------------------------

#ifdef PI_UPDATE
#ifdef _MANAGED
#pragma PI_MIX_UPDATE
#endif
void piUpdate()
{
   MonitorDialog^   monitorDialog;

   monitorDialog = MG::monitorDialog;

   monitorDialog->textBoxX->Text = GetDRO(800).ToString("F4");
   monitorDialog->textBoxY->Text = GetDRO(801).ToString("F4");
   monitorDialog->textBoxZ->Text = GetDRO(802).ToString("F4");
}
#endif

A very simple example but it shows that it works and how easy it is to do.

Attached is a screen shot of the running DLL.



-Ed

Ed:

  Wow. That is easy..

 I gotta admit though, I hate the thought of learnign the new syntax.. Im a dinosaur in many ways.. LOL

 Nice dialog syntax though, looks pretty easy to control..  Very nice work.

Art
 

Art -

The new syntax bugged me too. C# does EVERYTHING by reference so it threw me a bit. The '^' is a new kind of reference pointer that is used for CLR objects. The good and bad of C++ is that they have BOTH the old style and new style mixed together so they had to dream up some new syntax. Hence the use of gcnew vs. new. For garbage collection objects (CLR) use 'gcnew' for old style heap us 'new'.

The cute thing with mixed mode: look at the '= GetDRO(800).ToString("F4")'

I didn't have to write or do a thing. The compiler elevated the intrinsic double that Mach returned to being a System::Double object that includes a formatting ToString() function as a builtin member.

I found a GREAT book that I STRONGLY recommended that ANYBODY that wants to work with my new Plugin Development Environment buy. It covers ALL three modes of C++ development. Each chapter covers Win32, MFC, CLI (another name for CLR or .NET).

Again I HIGHLY recommend it and will be even offering it for sale at the Plugin class at the Mach3 Southeast Convention for the convenience of the attendees but really want them to buy it before hand and read through it.

The book is: Ivor Horton's Beginning Visual C++ 2008

ISBN: 978-0-470-22590-5

Publisher: WROX (a division of Wiley)

It cost $54.99 at Border's

It is called 'Beginning' but it is NOT. This is a deep treatise of the entire language and all it's power and uses.

-Ed

Ed,

GREAT work!  I have a proxy DLL based solution running that supports VC++ 6, 2005 and 2008 in my office.  But since they ARE using proxied pointers from a VC++ 2003 master plugin your solution is probably better.

Looks like I will probably back-burner that project!

-James

Ed = Da Man!!