RFC - Saving VI's as serialized xml files

[KevinW]

I have had a few years experience programming GUI's using the Qt libraries in C++. This had the VERY useful feature of saving all "source"-stuff in XML.

I wish LV could export a VI's definition to an XML file. Or even operate in an XML mode, where everything is saved in XML, and parsed and re-assembled when running.

This would make source code control much better, and opens up many possibilities, such as "VI-generator"-type tools, amongst other things.

Any possibilities of this coming about?

Regards,

Kevin Williams

[Jim_Kring]

That's a great idea, and one that many of us have been advocating. However, based on experience, I don't see this happening any time in the very near future.

-Jim

[Greg_McKaskle2]

> I wish LV could export a VI's definition to an XML file. Or even
> operate in an XML mode, where everything is saved in XML, and parsed
> and re-assembled when running.
>
> This would make source code control much better, and opens up many
> possibilities, such as "VI-generator"-type tools, amongst other
> things.
>
> Any possibilities of this coming about?
>

Possible? Yes. Will it bring about world peace? Doubtful.

We are in fact investigating different save formats for VIs that
includes XML. The current save format is binary and is very similar to
the memory image of a VI. This format was selected way back when CPUs
were slower, and to optimize loading you basically save off an image
that is as close to memory as you can get. Things change, a
nd we are
interested in more compact formats that take more CPU time to unfold the
objects, but require less I/O time since they are smaller on disk. We
are also looking at using XML since that would allow for external
validation and additional tools that modify a VI on disk. On the
otherhand, XML parsers aren't necessarily the fastest things out there
and when storing several thousand objects in each VI, the downside may
outweigh the benefits for many uses.

Additionally, LV diagrams and panels are often more complicated than
simple dialogs, and it is very difficult for a save format to be immune
to most simple edits. For example, given a VI, how does the save format
differ when the diagram is placed in a For loop? How does it differ if
the font metrics change? How does it differ if a control at the front
of the panel, or a node at the front of the diagram is deleted?

Anyway, this does have the potential of making SCC systems work better
with LV, but I doubt that lo
oking at a VI in XML will be like reading a
book. Time will tell.

Greg McKaskle

[waldemar.hersacher]

Dear Greg,

I do not think that saving VIs in a human readable way like XML will give us any benefit. I prefer a format which allows fast loading and saving VIs, because it is my time sitting before the screen and waiting. The only thing I can make with an XML format is to correct insane objects in the VI. But if I take into account the time to understand the format, find the object and correct it it is easier for all to send the VI to NI support and let them correct it for me (I hope they have the best tool to do it). And now we are past LV 3.0 we have very seldom insane objects.

Speed for loading VIs in development environment and as application concern more to me because not all of the machines LV is running on meet the minimum requirements
. Our slowest development machine is PII 350 with 128 MByte (HW update is sheduled for end of year, which year?). I know customers are using machines with Win95, Pentium 266, 16 MByte RAM for LV6.0.2 applications.

And there is a copyright problem to take into account. We are building LLBs and deploy them to LV programmers along with hardware. This LLBs have password protected diagrams which allow the programmer to convert it to the LV version he has and we do not need to hold a LLB for each LV version. But he is not allowed to make any changes to the VIs in the LLB. NI is doing the same.
BTW App builder is such an object of desire. I would automate it with a VI loading the BLD file (like "Load" will do), run the building task (like "Build"), answer all upcoming dialogs with "OK".

Waldemar