LabVIEW
INI file functions don't work in EXE on on some devices
Solved!
@David_R._Asher wrote:
It reads from the INI file only once on startup, which also doesn't work. That VI looks basically the same as the one in the picture, but instead of writing to the INI file, it reads. I'm not sure what some of your abbreviations mean.
Thanks
Opening a config file in two places results in two unique references, so I don't think that could be the issue. Closing one ref wouldn't make the other ref invalid.
But really, making guesses based on a picture isn't going to be helpful.
@David_R._Asher wrote:
Yeah, I don't think it could be a race condition for various reasons, but mostly because the INI file access happens in different states of the same state machine and it always opens, accesses, and closes the INI file in one VI.
I'm beginning to suspect that maybe the path is weird on the tablet. I am using the Open G "Current VIs Parent Directory" function to derive the path and maybe that is doing something weird on the tablet for some reason. I initially assumed that it was ok because the Open INI File VI does not throw any errors, but I'll have to double check what the path is next time I have access to the tablet.
Thanks!
I tried putting in malformed paths, nonexistent paths, all these things made various errors happen when opening the ref like you mentioned, not in the read and/or write VIs. Does the pictured VI have a default case? Is something bad happening in there that would cause a ref to become invalid (such as some flavor of the "default value if unwired" issue)? I don't like asking a lot of questions about pictures with case structures that I cannot parse.
@David_R._Asher wrote:
Other than the fact that you're kinda duplicating functionality which already exists in OpenG (saving/loading panel values), I don't see anything immediately wrong here. As pointed out, one of the other cases (not necessarily the default one) might be the culprit in not passing the reference through correctly.
My first suggestion would be to just try to use the OpenG or MGI panel handling VIs, as that's probably the least amount of work.
If that doesn't work, then at this point, I think your only option is more detailed debugging. You seem to be pretty sure about where the error is coming from, but I would suggest adding in some logging, even at the cost of editing the NI VIs (make a backup of them before you start or temporarily replace them with a copy of your own). See exactly where in the process the error happens, which controls did you manage to save, what is the binary value of the reference (type cast it to a number or strings), etc. This should hopefully help you understand what's causing the issue.
@cy... wrote:
is the error 1 thrown captured by your error handler or by the automatic handling? cos the variant to data error out is not connected to the write ini
While it is true that a possible error from the Variant To Data.vi would not be handled, it would report an error 91 if a problem occurred, and it would return the default value for the data type, so no error would be thrown in the Write Key.vi . I might want to handle that error though. You'd never know if values going into the config file were invalid, otherwise. It's a valid concern because it's a "calculated" path, and maybe for some reason, returning the ref for the wrong VI. I mean, you'd probably know after the fact because your app wasn't running properly, but it might be subtle enough that it appears to be running correctly, but really, it's not.
