02-19-2014 12:42 PM
It doesn't look like this is currently possible, but I figured I'd ask anyway. I am using a table control to provide users with the ability to edit and convert data. A lot of the functions requie the data in a numerical format. I have workarounds, but I'm not exactly happy with them.
02-19-2014 01:08 PM
You can make it look like a table has different data types in different columns with a little bit of effort. I posted an example of this: http://forums.ni.com/t5/LabVIEW/array-of-cluster/m-p/1822451#M625032
I recently revisited that code in a newer version of LabVIEW and found that the tab key didn't work quite right due to changes in event handling between LabVIEW versions, so you might have to make some adjustments, but it demonstrates the idea.
02-19-2014 01:19 PM
Interesting code 🙂 It doesn't really help me at all though. My problem is that I don't want to introduce rounding errors in converting between %s and %f all the time. The data needs to actually be stored in the memory as a number.
I'm currently keeping a "duplicate" %f array of data in the memory and using that for calculations, and the table for display. Now that I am half way through the program, I have realized that it is becoming increasingly cumbersome. I could have used an object and bundled the table data and array data together, but doing that now would be... effort 😛
-M
02-19-2014 01:24 PM
A table is just a user interface for an array, and arrays have to contain elements all of the same data type. Now, as nathand said, you could use clusters for your overarching "data type", but you can't go mixing naked doubles, singles, and integers in an array.
Cameron
02-19-2014 01:33 PM - edited 02-19-2014 01:37 PM
...
I realize that a table is just an array. I just want the data type of that array to be floating point, not string. I don't need mixed data, or clusters, or text rings. I need the visual display capability of a table with the data stored in memory as floating point.
-M
Edit: To make this clear, I really do realize this very likely isn't possible. It is in CVI, but not LabVIEW. I wasn't looking for a solution, I was just verifying that I wasn't missing something 🙂
02-19-2014 02:16 PM
Pardon me, I might be just seeing this too naively, but if you used the Double default format for your string->number conversion, you wouldn't get rounding errors until the 15th significant figure. And converting to an Extended number should make the conversion even more precise. I can't make the conversion give me any rounding error at all unless the 16th and 17th digits are "50". Are your users going to want to type in that many digits (I know mine won't)?
Cameron
02-19-2014 02:38 PM - edited 02-19-2014 02:40 PM
You are absolutely correct. This is getting in to "I have a solution but I'm not happy with it". There were two options to deal with the string data type. Option 1 was keep it in memory twice: once as dbl and once as string with precision 2, simply for display. Option 2 was continually convert back and forth.
With option 2, the problem is setting the precision when going from dbl -> string. If I set 15 point precision, the user has to look at 1.143000000000000 for every cell that doesn't have more significant figures, as well as a whole bunch of wasted memory. I can of course make it "smart" by scanning each cell for the decimal place and programmatically setting the floating point for each cell, but that is extra string processing, and still the extra wasted memory.
I do realize that for most applications these wouldn't be considerations. Unfortunately, I am working with (some) older computers combined with the rare data sets that will be large enough to want to take memory restrictions in to consideration.
Edit: Clarity
02-19-2014 02:43 PM
02-19-2014 02:47 PM
02-19-2014 02:50 PM
@Dennis_Knutson wrote:
What feature of the table are you using that s normal numeric 2D array indicator does not provide?
Lots. Headers, selecting multiple columns/rows. Easily deleting columns and rows. Copying / pasting sections of the data... etc. Oh, and array indicators are ugly.