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

[smercurio_fc]

---

@dbaechtel wrote:

---

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.

---

I appreciate it just fine, but all too often your posts (I'm referring to other threads as well) end up in just complaining about this or that not being supported in LabVIEW and you choose to simply stop there instead of doing the constructive part and suggest a change in LabVIEW. NI engineers DO look at the ideas in the Idea Exchange, as evidenced by the numerous ideas that were suggested there and *actually* implemented in LabVIEW 2010.

[dbaechtel]

---

@Dennis Knutson wrote:

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.

---

There you go with the personal attacks again.

I did not have endless posts.

I do not think that I ever mentioned the word "proper". Please stick to the facts.

I was still trying to investigate what could be done with the functionality that exists. Often when I post an issue, like this time, someone will eventually come along and mention a workaround. I am not yet ready to post something to the Idea Exchange until I have most of the facts.

Accepted etiquette should be sticking to the technical issues at hand in this forum and laying off of the personal attacks that I have noticed that you are too often prone to.

I do not appreciate the tone that you take in these matters and your lack a patience.

Much more of this and I will report it to NI as abuse and ask them to do something about it.

Take it easy and tone it down. Stick to the facts. Stay on the Technical topic. Lay off the personal attacks.

[Dennis_Knutson]

There are three pages of posts and that is 2 to many when you were given the answer in my first post. You went on and on about what you felt is supposed to be the behavior of the flatten to xml even after you were told the existing function did not work the way you wanted. You went on and on after I told you how to get the strings from the property node. You are the one who refused to listen, complained, and refused to implement the only method that is currently supported. You totally ignored my suggestion to use enums which do have the text/value linking that you stated you desired. It was at that point I called this whole thread stupid. You, are the one who did the exact same thing in your rants about local variables and how they were supposed to work. You are the one who does not seem to respect anyone who gives you an answer you do not like. You are not investigating functionality that exists. You are complaining about the functionality when it is explained to you and how it is inadequate.

Report all you want. See how far you get.

[MichaelAivaliotis]

The main issue is that the "value" for the control is not the array of strings. The value is the index of the selection. So in that respect, the flatten to xml function is doing what it's designed to do. The only control that will give you what you want is probably the Table control. The value for that is the 2D array of strings.

In my designs, I always try to decouple the UI from the application data. In your case I would create an application data cluster that contains the data I would like to save and restore from the xml file. In most cases you will have a 1 to 1 match from the UI to the file. In other cases you need to do some extra work to convert the data you want from the UI into the xml file and vice versa. So I suggest making a VI translater to handle reading from the UI and bundling the data into this data cluster and the other way around.

This translator VI will also make your code more robust and immune to changes in the UI requirements. For example, if your customer or end-user does not like the current UI control and wants something else to manipulate the data on screen then you don't need to change the XML file structure. The main work will occur inside the translator VI.

[Intaris]

I'm pretty sure answering to this thread is inneccessary but I can't help myself.  We all have our weaknesses.

---

@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 CAN do it and have been told already how to do it.  It's just not how you WANT to do it which is entirely a different matter.  You have also been told WHY it doesn't do this.  I see nothing incorrect about the responses you have been given.

---

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.

---

There's nothing stopping you accessing the required properties of the control and saving them to XML.  Whether the inbuilt XML functionality of LV is lacking is a different matter entirely.  You posted the question asking HOW to do something and have since been told how to do exactly that.   Your unwillingness to accept this and go about implementing it is what is getting people annoyed.  You must be aware of this.

---

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.

---

NI offers the Idea Exchange to make suggestions for things like this.  The constructive way to go about things is to accept the knowledge of people here (Dennis is one of if not THE authority on LV here) and try to improve things.  No product is perfect and NI is listening to our suggestions.

Shane.

PS We're nearly all volunteers on this forum.  Economic problems are all around us and many of us may have existential worries.  Still we come here to try to help as much as we can.  We could all turn our backs on this kind of behaviour and leave you and your problem alone but we're doing our best to help.  A bit more civility and respect would go a long way to making you a better LabVIEW programmer.  I'm a pretty good LabVIEW programmer and the only other LabVIEW programmers I know are the members of these forums.  I've never needed to take an NI course because of this.  Treat us well and we'll stand by you.  Disrespect us and you'll end up on your own.