LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Using of MGI read write anything

Solved!
Go to solution

Hello,

 

Looking for a tool to read and save the ini input I found MGI's read write anything. However, I could not find any sample files. So after a few tries it worked. But I think there might be a more elegant way than mine. Furthermore the enum is still causing problems. Maybe someone here can help me.

 

Best regards

 

 

Download All
0 Kudos
Message 1 of 14
(2,333 Views)

Commenting specifically about the use of MGI R/W Anything:

 

- I've used this library a lot and never needed to wire up the format specifier input.

- I probably wouldn't use "ini" as a section name since I typically also use ".ini" as the file extension.  That's just a preference though

- don't ignore the error outs!

- it's sometimes handy to set the 'Use Supplied' input to True when calling MGI Read Anything.  Then only the cluster elements that are explicitly defined in the INI file get replaced.

 

Overall though, you're basically doing it right.  You made your cluster a typedef and you set your section name explicitly.

 

One thing to note: unfortunately, MGI INI files don't play nice with native LabVIEW INI file functions.  MGI requires *no whitespace* surrounding the assignment '=' sign.  The native functions surround the '=' with single space characters, which make MGI fail for that item.  Once you choose between MGI and native LabVIEW functions for your INI files, make it an all-or-nothing choice.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 2 of 14
(2,327 Views)

One thing to consider if you use the MGI R/W Anything is that as Kevin mentioned, it is very picky about white space. If humans will be modifying the file in a text editor I would probably chose the NI ini VIs. They are more forgiving about the exact format in the file. I have been burned using the MGI R/W Anything when humans have modified the file in a text editor.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
Message 3 of 14
(2,290 Views)
Interesting, I've been using MGI INI files for years and I didn't know about the white space requirement. I often edit them in notepad and haven't had a problem. I guess I've always played by the rules 😄
0 Kudos
Message 4 of 14
(2,279 Views)

Thank you, for yours fast answers.

As mentioned before, there is still a problem with the enum. The saved value is not written back to the enum control element.

Download All
0 Kudos
Message 5 of 14
(2,247 Views)

1) Attach the VI.
Are the Enums the same (data in the same order)? - please list Strings array
I would suspect that if you haven't typedef'd the enum, the enum is probably in a different order in the 2 clusters.
It appears both clusters are type defs.

While I use MGI for configs, I am moving away from storing enums in the config. I store a Ring in the config Write Cluster, and convert it to an Enum for use in the code. (And before anyone else points it out, Enums and Rings default to different values when they hit the limits so you have to write some code for the data change).

This allows me to have a flexible UI and change the (Ring) text for the user - adding and removing new features as I want, but keep the Enum in the BD code and therefore have self documenting code, without the headache of what happens when a feature relying on a value is obsolete and the enum text is no longer available from the file.

James

CLD; LabVIEW since 8.0, Currently have LabVIEW 2015 SP1, 2018SP1 & 2020 installed
0 Kudos
Message 6 of 14
(2,236 Views)

@James: The Vi is in the first post already available.

0 Kudos
Message 7 of 14
(2,211 Views)

 


@Heino wrote:

@James: The Vi is in the first post already available.


🙈 Sorry Heino.

- I can't reproduce this bug. I know I've got the MGI functions, but I also know they've been ever so slightly tweaked on our system so I can't install a virgin MGI toolkit ang get the same effect as the config file functions I have here. So I can tell you with tweaks to a few files (I think last time I loaded there were only 4 file different) the MGI toolkit can be made to play nicely. (Don't have time to look right now, and probably confidential which files we've tweaked)

James

CLD; LabVIEW since 8.0, Currently have LabVIEW 2015 SP1, 2018SP1 & 2020 installed
0 Kudos
Message 8 of 14
(2,185 Views)

Note: if one uses a Package and find it has issues are needs tweaking to work well, you should try contacting the authors of the package so that improvements can be incorporated in the publicly-available version and made available to everyone.

0 Kudos
Message 9 of 14
(2,178 Views)

@drjdpowell wrote:

Note: if one uses a Package and find it has issues are needs tweaking to work well, you should try contacting the authors of the package so that improvements can be incorporated in the publicly-available version and made available to everyone.


Makes sense - but I don't know who tweaked it when - it was before my time here, so I assumed it was tweaked for a specific purpose here.
I'll have a look later this week. I don't think MGI has been updated in a few years (but I could be wrong).

James

CLD; LabVIEW since 8.0, Currently have LabVIEW 2015 SP1, 2018SP1 & 2020 installed
0 Kudos
Message 10 of 14
(2,166 Views)