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
Guest
