Replies: 6 comments 22 replies
-
In principle, I would prefer to not see too many LabVIEW primitives on the top-level. |
Beta Was this translation helpful? Give feedback.
-
My feeling is all these edits can be done in a way that completely keeps the current behaviour, so no actual change to functionality. |
Beta Was this translation helpful? Give feedback.
-
I have had my eye on those specific spots for some time, I just kept finding bigger things to tackle. My vision for this, which I do have a working branch for, is to turn the position code into a class. This would have a private VI to hold the ini key(s) to read/write, and private data to hold the starting position and VI reference. For direct replacement, this code is ready to go. However, I would like to add functionality to keep the user from updating the ini file manually and resizing the panel. This is where I am stalled, mostly due to being distracted by 1M other things. Additionally, we should make some unit tests for this new class. |
Beta Was this translation helpful? Give feedback.
-
@crossrulz now that your changes have been merged, can I make a start on this? |
Beta Was this translation helpful? Give feedback.
-
@neilpate, Do we even care about writing to the ini file if there was no change in position? I'm inclined to say no, especially since there are a whole bunch of other settings that are written to the ini file unconditionally. See WriteDataToLabVIEWINI.vi. If we eliminate the need to store the position value, then I have no real argument to make this a class. So making 2 new VIs makes sense: One to read the position in the ini file and set the IE VI position and another to write the position to the ini file. I propose we put these two VIs in the ReadDataFromLabVIEWINI.vi and WriteDataToLabVIEWINI.vi. The Read is only called on the first call of Load.vi (poorly named VI), which should occur in the initialization. It will need to be updated to have the IE VI reference passed in to be able to set the position of the IE VI. I am also extremely tempted to turn it into a Natt Sequence (https://forums.ni.com/t5/Community-Documents/Natt-Sequence/ta-p/3970582) or similar (use the INI keys in an array of strings to loop over). The idea here being a sequence loop would be a lot easier to read (eliminate a lot of long and crossing wires). The Write is only called in the Write INI Tokens and VI Tags.vi, which is only called in the IE VI cleanup (first VI in the Flat Sequence Structure). ~~From there we have the choice to have the WriteDataToLabVIEWINI.vi accept the IE VI reference or the position. I lean towards the reference, but could easily be convinced going the other way.~~For parity with the Read, it makes a lot more sense to pass in the IE VI Ref. Going this route will completely eliminate this code (and 2 long wires!) from the main diagram. What do you think? I can also do a quick class elimination of the VIs I already have implemented and get them into the feature branch for you to start from. |
Beta Was this translation helpful? Give feedback.
-
Implemented with #285 |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Currently there is way too much going on in the top level.
I propose to make some simple changes to tidy up some of the code into sub-VIs.
First step is to address stuff like this. Potentially leveraging the fact that there are already VIs to do setting/getting config information from LabVIEW.ini
Beta Was this translation helpful? Give feedback.
All reactions