Flatten to XML does not save Item Names of ListBox to XML file.

[dbaechtel]

TRY IT YOURSELF !

Build a ListBox. Fill it full of strings. Run the VI. Edit and Select one of the Strings. Flatten the ListBox to XML using the Flatten to XML function. Write the XML data out to an XML file.

Now Read the XML file back in again. TRY to reconstruct the ListBox from only the XML data file provided (as if the VI is initializing during startup) with the appropriate String selected in the ListBox as it was before it was Flattend and all of the other Item Names also loaded into the Listbox.

If you can do that, then please let me know how it was done.

If you can't do it then some functionality is missing somewhere (IMHO).

[dbaechtel]

---

@Dennis Knutson wrote:

This is getting stupid. You are whining about functionality that simply does not exist. Whether it should or not is just irrelevant at this time. We are dealing with the existing data type. I already told you what you have to do to get the strings with a second flatten to xml. And I already told you what you should do if you want the data type changed.

---

There you go with the personal attacks again.

Let's keep this discussion on a professional technical basis, shall we.

[Dennis_Knutson]

It would be professional of you to accept the cuurent functionality and the simple solution. You keep looking for something that does not exist even after being told numerous times. I can understand why you might want it added but to keep saying should, should, should is indeed stupid. Imstead, say, thank you for providing a workaround for now.

[dbaechtel]

I do not yet have a workaround that will allows me to reconstruct a ListBox from only the data in the XML file provided by the Flatten to XML function. That's the problem. I do not have the Strings needed to load the Item Names.

I do not have a ListBox full of Item Names on startup to get the Strings from. I only have the XML data file and the data in it.

How or where can I get the Item Names from which to load the ListBox when only the XML file is available?

[smercurio_fc · Accepted solution]

Perhaps if I repeat it, it might sink in.

You can't.

Read the Help on the Flatten to XML function:

Converts any data type you wire to anything and converts it to an XML string according to the LabVIEW XML schema

Note the words data type. It says nothing about the properties. The strings are a property. That information will not be included in the XML string. This means you have to find another mechanism, such as flattening the Item Names property and then unflattening to a 1D array of strings.

[dbaechtel]

It is Too Bad that so frequently when I am searching for useful and necessary functionality within LabVIEW, that frequently the answer I get back is "You can't do that" or "It doesn't do that."

It is frequently necessary in applications to store away in an XML (or some other formaedt) file all of the data necessary to reconstruct the state of some Controls from some other previous time when the XML data file was written.

It seems easy enough. Just Flatten the Control to XML and then reconstruct the Control later from data in the XML data file.

It is too bad that LabVIEW has not yet developed the functionality to make this process easy for the Developers.

I know it can be done and I will go through all of the time and effort to make a custom soultion for my specific case.

Thanks for all of the insight that you have provided. It has been helpful.

[blawson]

---

@dbaechtel wrote:

It is frequently necessary in applications to store away in an XML (or some other formaedt) file all of the data necessary to reconstruct the state of some Controls from some other previous time when the XML data file was written.

---

You want to restore the state of the controls but all you get from the control's terminal is the data value of the control.  Where does it end?  Should it include the control's enabled/disabled state? Visibility? Color? Position? Font? Size?

The process *is* pretty easy when you recognize that for certain functionality (run-time editable) the value and the state are distinct.

[smercurio_fc]

---

@dbaechtel wrote:

It is Too Bad that so frequently when I am searching for useful and necessary functionality within LabVIEW, that frequently the answer I get back is "You can't do that" or "It doesn't do that."

---

You would get a similar answer in other programming languages as well with other things. "Can't do that" is not unique to LabVIEW.

As noted, if you find functionality lacking then post a suggestion in the Idea Exchange instead of just complaining.

[dbaechtel]

---

@smercurio_fc wrote:

---

@dbaechtel wrote:

It is Too Bad that so frequently when I am searching for useful and necessary functionality within LabVIEW, that frequently the answer I get back is "You can't do that" or "It doesn't do that."

---

You would get a similar answer in other programming languages as well with other things. "Can't do that" is not unique to LabVIEW.

As noted, if you find functionality lacking then post a suggestion in the Idea Exchange instead of just complaining.

---

Actually I think that Serialization of Objects (which is a very similar idea) even directly to XML is much more well developed in just about every other platform I have worked with. I think that LabVIEW is well behind the state of the art on this one.

Also I thought that complaining and sharing opinions are one of the major purposes of the discussion forums like this one.

Constructive Criticism or Complaining, if you will, frequently fuels forward progress and further development. Too bad that many people in this forum don't appreciate that aspect of it.

[Dennis_Knutson]

Constructive criticism is fine but imho, you went beyond that. When faced with something that is not supported, instead of your endless posts about what should be the 'proper' implementation, you should have acknowledged the way to get the strings as xml and then posted to the Idea Exchange. That is where new ideas are proposed and discussed. This has been mentioned before as the accepted etiquette.