08-26-2007 09:39 AM
08-26-2007 09:43 AM
08-26-2007 09:45 AM
08-26-2007 09:46 AM
08-26-2007 09:52 AM - edited 08-26-2007 09:52 AM
08-26-2007 01:41 PM
If nothing else, the amount of work that went both into the code and into the nugget are appreciated. Thank you, Ben and JLV.
Now, to some comments. I'm afraid they will be mostly "anti", but they should be taken in good spirit.
Also, this is just an initial impression. I will be lying if I said I understood everything you did. There is simply a lot of it to take in.
Additionally, there is probably some stuff which I will forget.
The example provided only supports 2-d arrays. Do you think that a 2-d array has a significant number of dimensions to satisfy real world needs?
Enums are not supported by the provided example. How would these be implemented?
Numerics are all saved as a fixed number of significant figures. How to track and specify the number if sig figs?
Unused keys are not deleted. When the number of elements in an array is reduced, the key entries still exist in the file. Can you offer any suggestions on how to how to keep track of what keys need deleting?
The example provided presents an effective but inefficient technique for determining array dimensions. Can you suggest a better method that can survive LabVIEW updates?
08-26-2007 02:01 PM - edited 08-26-2007 02:01 PM
Message Edited by shoneill on 08-26-2007 09:03 PM
08-26-2007 02:24 PM
If I'm not mistaken, Tst's statement that a new version of the AE is required for each typedef is incorrect.
I was refering to the top level VI. The typedef cluster is part of it, so it will have to be duplicated.
True, it goes trhough the UI. However, this isn't typically an operation which is performed during HW interaction, more at program start and stop, so i I think this is acceptable.
Speed can be an issue, but all of these methods have speed problems. I believe the benchmarks MGI published for their method showed it to be much faster, but those are 8.x only.
True, it relies on tricks, but then we all use lots of tricks. As long as they work, who cares?
Yes, "as long as they work". I wouldn't want to find that a certain trick stops working.
Regarding testing, it's fairly robust actually.
I was wondering about Ben's version specifically. I know that control refs and properties work fine, but I was wondering whether this specific implementation was tested and used in actual applications.
I also disagree on the "trial and error" method of getting the type of the control. The ID value is still much more convenient, and is a lot less likely to change than the variant structure.
I knew I forgot something! I would agree. That's the whole point of the ClassID - to not change even if the class changes.
Ps: Tst, you say there are built-in VIs to determine srray size? Can you enlighten us?
I did. They are in vi.lib\Utility\VariantDataType and they are what the MGI VIs use.
LV 7 also had some VIs for this (in vi.lib\Utility\GetType.llb) which used the type descriptor, but the 8.x VIs have more options (including finding the size of the array dimensions).
08-26-2007 04:24 PM - edited 08-26-2007 04:24 PM
....And now that the tool is ready i can just use it !
Very nice! up to now, i was always creating a new load/save params vi, for the specific application, as ben depicted for arrays of cluster for example. was quite annoying. i expect it will be a world easier.
btw, for those who still like to use : make current value defaults, thats how it might be done:
For enums, i generally never let the user update them directly, but always trough an external vi, that saves both the string and the value.
Message Edited by Gabi1 on 08-26-2007 11:27 PM