Machsupport Forum
Mach Discussion => Mach SDK plugin questions and answers. => Topic started by: j1sys on April 09, 2008, 12:57:45 PM
-
Hello All -
I am 99.99% confident I have found the "Why" on why development can't be done on VS2005/VS2008.
I am 97% confident I can "fix" the problem and will soon be releasing ".h" files and instructions for others to use.
The problem IS that Mach is passing you four VERY important pointers. (Thank you Art/Brian). The problem is that several of these are pointers to CLASSes not STRUCTs.
To track down the problem I turned on "Assembly Code Listing" in both 2003 and 2008 and compared the generated code line by line. (Yes I'm that crazy). I immediately found that most of the offsets on MainPlanner (TrajectoryControl *) are WAY off. The reason is that TrajectoryControl inherits CWnd and CWnd changed in the MFC libraries between versions. There may be other inheritance differences that add to the problem.
To test my theory I cast the pointer to a hand crafted struct pointer to allow acces to the TCPModBusData struct down near the end of the data area. Using the struct I was then able to access and display the cgf array in a simple MessageBox in myConfig. I use this same technique in VS2003 to have a look at the raw data inside Mach for debugging a stand-alone MODBUS TCP Simulation Server I am working on for release to the Mach community. I now have two versions of the data dumping plugin. One compiled in VS2003 and one, with minor changes, compiled in VS2008.
I am in the process of analyzing TrajectoryControl.h line by line with the intent of creating a STRUCT that can be used in place of the CLASS. This should allow greater portability across different version of the compiler. I am INITIALLY only targeting the Data areas. After completion I will then target the public functions. I don't know if anyone is, or IMHO even should, or can be calling functions in the class currently in VS2003.
This is not just a tease. I am making rapid progress daily and wanted to "leak" to the community that we may have a clean solution soon.
My ultimate goal will be to then wrap ALL interfaces with Mach in a both a managed C++ class and a C# class to allow using .NET. Using .NET may be optimistic but I believe I can do it. If I can't do it directly then I will wrap it all in COM and interact that way.
-Ed
Edward D. Bryson
Joshua 1 Systems Inc.
Knoxville TN USA
-
Ed:
Interesting. I did know that it was an issue with the trajectory class's pointers getting corrupted, but I didnt know that CWnd changed size between versions. I wonder if theres a constant to tell windows a version of class. Good Job though, those changes would make things much easier for aspiring plugin authors. Let me know how you make out and Ill update the release resources to reflect it. Ill try to get some tie this week to see if there is soem arcane compiler switch that will take care of it. OR if perhaps an easier solution exists. Seems to be it should be safe to take a class pointer using a CWnd class, seems an awful big hole to leave between versions..
Thanks
Art
-
Good work ED!!!! I need to get 2008 at some point :)
Thanks
Brian
-
For what it is worth..........
I can vouch for Ed, he is the guy I have been taking weekly C++ classes from for doing plugins. I met him as my student in the Mach3 Convention, he noted he was a programmer of some 30 years experience. So, I asked for classes from him. It took him about 1-2 weeks to get up to speed on plugins, and then he started pointing out the issues to me, using LARGE and EXPENSIVE words that I never learned on Seaseme Street...........
At any Rate, I bugged him to bug YOU: Art and Brian about his discoveries, since I figured you fellers would understand the big words since you already paid for them, and I am just learning them, hehehe.
Thanks again Ed, for your potintial fixes to the Plugin community, this will help us all greatly.
The plug in he is helping me do, is to take inputs from a modbus, parpport, or TCP to use as a direct External jogging button. So he got me started and pointed in the right way. So far I have all 6 axis jogging + and - with LEDs that light for that function, through serial modbus using Arturos boards. I will be adding Analog Jog override, jog on-off, Jog-select type, jog-select axis vs. a jog all axis. (i.e. if you pushed the negative direction on each of the six axis then all would move simultanously), and a few other odds, and ends.
He Explained more to me, and I learned more from him in just a few hours, than my own study of days........
As a side note he is building some Hardware that will greatly enhance the Mach community as well, be on the look out for it........
Scott
-
Art, Brian, Poppabear -
I am doing all this with VS Pro 2008, and VS Pro 2003. But I'm targeting, when done, to provide all the pieces that will allow ANYBODY to use the free VS2008 student editiion.
Art/Brian (poppabear wouldn't understand ;^)) - In all of your initial programming I'm sure you didn't ever plan on opening up and allowing plugins. Again thanks for doing it. I will try to provide more help, info, tutorials, templates, functions to the community to support its work and leave you guys to work on the big picture. IMHO classes, especially inherited ones, are not the best choice of how to communicate between master and plugin. Think about COM, Interop and all the Marshaling Options built into the new languages to allow communication with OLD DLLs. They are all based on STRUCTs not CLASSes. In this case we are trying to do the reverse. I understand it will be a VERY big undertaking for you to upgrade your code. I support many legacy customers going back to Manx Aztec C and VC6 for DOS. Just like you like to/need to add a new data field to support a new feature, CWnd needed to be improved. As soon as it added one bool it changed the offset to YOUR classes part of the buffer. That is one of the beauties of inheritence. You can always use a pointer to access the lower classes in the hierarchy. It may be possible to use ALL the headers and libraries from VS2003 plugged into VS2008 but I don't think it is worth the risk or effort. If I remember the code paradigm for C++ it really just passes a pointer to the class data structure as a first hidden parameter but otherwise follows the _CDECL calling format. I should be able to wrap any needed functions in custom static classes and expose an easy to use interface for plugin writers. My worst problems might be exposing the CString text. They may have changed its layout also and it will require some poking around to find the public or hidden pointer that will get me to the raw data.
My plan is to make a struct that has byte arrays of fill space to skip over the areas I can't/won't do on each pass. The following example code snippet is the cheater struct I used to test my theories with TCPModBusData:
struct TrajectoryControlTCPModCon
{
char fill1[2762596l];
TCPModCon TCPModBusData;
};
TrajectoryControl *M3MainPlanner; // original CLASS pointer
TrajectoryControlTCPModCon *M3MainPlannerTCPModCon; // duplicate STRUCT pointer
#define REGTYPE_INPUT_REGISTERS 0x00
#define REGTYPE_INPUT_HOLDING 0x01
#define REGTYPE_INPUT_COILS 0x02
#define REGTYPE_INPUT_DISCRETE 0x03
#define REGTYPE_OUTPUT_HOLDING 0x04
#define REGTYPE_OUTPUT_COILS 0x05
.....
extern "C" __declspec(dllexport) bool InitControl(void *m3Engine, void *m3Setup, void *m3MainPlanner, void *m3View)
{
AFX_MANAGE_STATE(AfxGetStaticModuleState());
M3MainPlanner = (TrajectoryControl *) m3MainPlanner;
M3MainPlannerTCPModCon = (TrajectoryControlTCPModCon *) m3MainPlanner;
return true;
}
//---------------------------------------------------------------------
//
// Config() - Legacy Config Interface
//
//---------------------------------------------------------------------
extern "C" __declspec(dllexport) void Config()
{
AFX_MANAGE_STATE(AfxGetStaticModuleState());
CString txt;
txt = "";
TCPModCon *tcpModCon1 = &M3MainPlanner->TCPModBusData; //just to compare ASM listings
TCPModCon *tcpModCon2 = &M3MainPlannerTCPModCon->TCPModBusData; //---------------------------------------
for (int i = 0; i < 65; i++)
{
TCPModCfg *tmc = &M3MainPlannerTCPModCon->TCPModBusData.cgf;
if (tmc->Enabled)
{
CString valTxt;
int regType = tmc->Input;
txt += "Cgf[";
valTxt.Format("%02d", i);
txt += valTxt;
txt += "]: ";
switch (regType)
{
case REGTYPE_INPUT_REGISTERS:
valTxt = "Input - InputRegisters";
break;
case REGTYPE_INPUT_HOLDING:
valTxt = "Input - HoldingRegisters";
break;
case REGTYPE_INPUT_COILS:
valTxt = "Input - Coils";
break;
case REGTYPE_INPUT_DISCRETE:
valTxt = "Input - DiscreteInputs";
break;
case REGTYPE_OUTPUT_HOLDING:
valTxt = "Output - HoldingRegisters";
break;
case REGTYPE_OUTPUT_COILS:
valTxt = "Output - Coils";
}
txt += valTxt;
txt += "\n";
switch (regType)
{
case REGTYPE_INPUT_COILS:
case REGTYPE_INPUT_DISCRETE:
case REGTYPE_OUTPUT_COILS:
{
int byteCnt = 8;
int bitCnt = 8;
for (int j = 0; j < tmc->nReg; j++)
{
if (tmc->Data[j]) txt += "1";
else txt += "0";
if (--bitCnt == 0)
{
if (--byteCnt == 0) { txt += "\n"; byteCnt = 8; }
else txt += " ";
bitCnt = 8;
}
}
if (byteCnt < 8 ) txt += "\n";
}
break;
case REGTYPE_INPUT_REGISTERS:
case REGTYPE_INPUT_HOLDING:
case REGTYPE_OUTPUT_HOLDING:
{
int wordCnt = 8;
for (int j = 0; j < tmc->nReg; j++)
{
valTxt.Format("%04x", tmc->Data[j]);
txt += "0x";
txt += valTxt;
if (--wordCnt == 0) { txt += "\n"; wordCnt = 8; }
else txt += " ";
}
if (wordCnt < 8 ) txt += "\n";
}
break;
}
}
}
MessageBox(NULL, txt, "PluginCPP", 0);
}
On a side note. I've empiracally tried many different combinations to get the minimal acceptable functions and declarations to make a plugin. Is there any chance of publishing some of the "Load Plugin" code so I can try to get it down to bare bones?
-Ed
-
Hi Ed:
Good Idea. I did similarly with some other code I used. The plugin loader
is pretty simple. It sends a pointer to the functions back to MAch3 so it
calls the DoButton() and the GetLED() etc... as pointers to the plugins
functions. All other calles are simply the pointers your playing with. Since
I didnt know what var's woudl be used, using Com' etc was really hard to
arrange without making every function exported.. Your right, I hadnt planned
on making it open, it just hit me one day so I di dit, unfortunately, this
makes it a bad usage of pointers. Hard to switch over though. Brian will
send you any code you think will help, but I suspect the loader isnt much
good to you, it only exports pointers from the plugin, which should be all
OK in any language, its just the classes that are an issue, and various
plugins use variosu variables , so its really hard to set them all to com.
Id suggest just finding the difference in size and using a subtraction from
the var names maybe.. gotta think about that one.. The original problem was
dll's wernt designed to callback to the originating code base, only to have
routines to BE called..
Thanks for the investigations..
Thanks,
Art
-
Ed, GREAT news. And I'm glad Scott could find somebody so capable to help that is local. Please keep me in the loop on all this and I will write another tutorial on getting started with plugins using VS 2005 and probably 2008. I assume you are talking about the 'Express' free compilers when you mention the student editions? How will you support MFC with those?
-James Leonard
-
James -
My PERSONAL goal is to move away from MFC and use .NET in my plugins. Time critical code (40hz / 10 hz Update) MAY be left in C++ unmanaged but that code should not be doing MFC IMHO. The techniques to get it working at all can still be used by anybody for any purpose. I believe that the $199 VS2008 C++ Standard would include MFC support for those that needed it. We still are going to be constantly fighting the older version MFC vs either the newer version MFC or vs .NET. I'd rather fight the battle all the way and go for .NET.
I am also looking into the redistribution rights and restrictions to see what I could give someone with an Express version to use for MFC. Again for .NET they would already have it. So for simple plugins, if I can make it work and document it, .NET may be the answer.
It will be a moving target with several different solutions based on the needs of the individual. So the fun has just begun.
-Ed
-
Hi Ed,
Ok, sounds very good. I personally have zero interest in .NET so it seems together we can cover both sides of the fence. My primary use of MFC in a plugin would be to simplify support for ActiveX controls on dialogs. For most other uses I am a SDK programmer and working with ordinary modeless dialogs is going well for my CorelDRAW hosted CAD / CAM system.
I researched the MFC / Express compiler issues a LOT initially and AFAIK MFC just isn't available (legally) for usages like this.
-James Leonard
-
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.
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:
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?
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()
These all appear to generate the proper DLL exports under examination with PEBrowserPRO.
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.
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 ;^)
-
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!!
:)
-
thx Ed:
Ill order that book, time I had an upgrade anyway. :)
Art
-
Great, I'm happy to hear about that.
At the moment I'm using Visual Studio 2005 for any project but Mach3. It will be fine to have one VS-Installation only.
Here I've got 3 Plugins uner development which i can transfer to VS2005 to check for function.
Steffen
-
For All -
Lastest update: I've worked almost exclusively on this project for the last ten days and I think I see the light at the end of the tunnel. I just hope it is not a train coming.
I have developed an .msi installer that will install a new Application Wizard called MachPluginWizard on either a Visual Studio C++ 2008 Standard or Visual Studio 2008 C++ Express installation. After installing MachPluginWizard a developer can create a new project with just a few clicks. MachPluginWizard includes the options of selecting the Win32, ATL, MFC, or .NET configuration and creates source code files tailored to the option selected. The ATL and MFC options are greyed out if MachPluginWizard detects that it is running inside of VS 2008 Express. It also selects all needed parameters in the VC project file. Optionally it can include standard code for a simple configuration dialog, Plugin Config menu items installation using exclusively Win32 calls, my new XMLProfile class for .NET, and the Post-Build event to copy the .dll to the C:\Mach3\Plugins directory. MachPluginWizard takes care of all textual edits needed to personalize the code to a plugin name that matches the project name.
The installer also installs my modified .h files in a subdirectory and MachPluginWizard sets the project to search that additional directory.
As I demonstrated to Scott last night, you can click on MachPluginWizard, name the project, accept the defaults, let it create the project, build the project, and then go to mach and see a new plugin raring to go!!
I've probably got another week of testing and tweaking all of the options for all of the environments before I can release it to my beta testers. Then I will work up some quick AVI tutorials on it's installation and operation.
As of now I believe I will not support VS 2005. I believe with all my work to support VS 2008 Express and .NET that anyone can use those tools for free and don't have to buy VS 2008 Standard or better unless they feel they have to use MFC to develop their plugins. The wizards and features I use may not be compatible with VS 2005 and I don't want to add another level of complexity to my plate.
----------------------------------
For Art/Brian -
In the mixed mode .Net version I developed a replacement to XMLProfile that uses .Net XML. Empirically I've tested it with my Mach3 and don't see any problems but want to run a few questions by you:
1) Do you see any problems with using an indented option on the XML file? I've tried it and it seem nots to mess up Mach3. Since you appear to be using the MSXML COM object and it will accept indented I think I'll be OK. It just makes it so much easier to look at.
2) Do you see any problems with plugins written in the new development environment doing the following when it is valid for them to work with XML file:
2a) Create a DOM object
2b) load the XML from the file
2c) interrogate and/or modify the DOM
2d) save the XML to the file (if needed)
3) So far it appears to work. I'm just not sure how this will interact with your handling of the XML file. I don't want to lose any of your changes and/or have you overwrite any of mine. Do you see any problems?
4) I've also added the option to allow plugin writers to create a simple tree structure within their section. They just have to enable it when they constuct the XMLProfile object and then they can use entry names like 'Dlg1/Int1', 'Dlg2/Txt2'. Again, empirically, it appears to not make any problems for Mach3 since the MSXML still loads and saves the file fine. Do you concur?
--------------------
For ALL -
Attached is a screenshot of the Mach3Mill.xml file in the Visual Studio editor with all of mach's sections collapsed and showing the new XML section of a plugin named XMLTest.
-Ed
-
Hi ED:
Sounds like your almost there. :) , lets seee...
>>In the mixed mode .Net version I developed a replacement to XMLProfile that uses .Net XML. Empirically I've tested it with my Mach3 and don't see any problems but want to run a few questions by you:
1) Do you see any problems with using an indented option on the XML file? I've tried it and it seem nots to mess up Mach3. Since you appear to be using the MSXML COM object and it will accept indented I think I'll be OK. It just makes it so much easier to look at.
Id have to see how ( or more likely when) your using it to be sure, but no, I dont think its an issue. The XML I use in Mach3 was a class object I got from somewhere, and modified a bit to work in Mach3. BUT, it has some inherent issues. For example, when used in the main timing loop, items get lost. This has somethign to do with the state of the context at time of call, but Ive never tracked it down, (Im more a master of the workaround :) ), so what I did was to temporarliy close the XML before notifying the plugin that its OK to save or get information from it. The plugin actually has its own opened XML, and MAch3 is not sharing it at all, when the plugin returns from that call, the xml is reopened by Mach3. So in your context , I suspect your fine no matter what, since Mach3 will usually not need any data in the xml, even it it doesnt understand the added entries, as long as the plugin does, no issues exists.
>>>2) Do you see any problems with plugins written in the new development environment doing the following when it is valid for them to work with XML file:
2a) Create a DOM object
No, again Mach3 will not try to read or use the DOM in any way, so as long as the plugin can, it shouldnt matter if it exists in the xml. Id only worry that MAch may, at some point, see the
additional entries as a corruption and skip other tags, but Ive never seen that happen, at worst it woudl simply skip over the entries till it find what its looking for.
>>2b) load the XML from the file
No, again its closed whenever the Plugin has been told it can be used. So when the plugin opens it, its totally owned by the plugin for that brief period of time. :)
>>2c) interrogate and/or modify the DOM
>>2d) save the XML to the file (if needed)
Nope, same as above, as long as the file is valid on close, it shoudl be fine when Mach reopens it.
>>3) So far it appears to work. I'm just not sure how this will interact with your handling of the XML file. I don't want to lose any of your changes and/or have you overwrite any of mine. Do you see any problems?
I think your safe, I use the XML as a simple tagged entry list, nothing nfancy at all, I could have as easily just made it a text file and written my own parser for the data, but xml looked easier. ( I can tell by your questions your by far the expert on xml matters, :)
>>4) I've also added the option to allow plugin writers to create a simple tree structure within their section. They just have to enable it when they constuct the XMLProfile object and then they can use entry names like 'Dlg1/Int1', 'Dlg2/Txt2'. Again, empirically, it appears to not make any problems for Mach3 since the MSXML still loads and saves the file fine. Do you concur?
Yup, totally, in fact I think its a brilliant solution, it makes the xml an extendable file that can be upgraded massively in future to contain much more usefull data , kinda like a hive of its own for Mach3, sounds to me like youve done real well.
Ive been real deep in the code so I havent been watching close, but Brett will let me know when youve posted this, I promise Ill stop and test it out, then post anything I see that may cause some concern in future, I use VS2008 exclusively now in my own projects so it'll be an interesting test. :) ,
Thanks again for all your doing, from my simple plugin solution ( as you know I never planned for one, just kinda added it one weekend when it occured to me) , your creating a much more usefull and extendable solution.. Im impressed.
Thx
Art
-
I tell you this, having got to see it in action, it is SO much easier to do Dialogs and stuff!!! Proffessor ED will be going over his Plugin solution as a 3 hour class at the mach con 2.
scott