02-19-2020 03:30 AM
Hi,
The function UserVarCompile is now obsolete but strangely VSA is not, so you can check whether a user variable file is enabled but you can't compile one.
I make this point because many of my scripts rely on a feature that, when first run, a set of variables will be given default values and then in any subsequent use of the script (assuming DIAdem has remained open, of course) the varaibles will retain the values given by the user during the first run through. This is useful because of the need to analyse multiple files that will use a set of vehicle-specific input values , saving time by preventing the need for the user to enter the values repeatedly.
The following code used to allow for this quite neatly by having a user variable file that stored the defaults enabled on the first pass and then not re-enabling them on subsequent runs:
If Not VSA(SharedPath & "VBS\SpadVar.vas") Then
Call USERVARCOMPILE(AutoDrvUser&"VBS\SpadVar.VAS","new")
End If
How can I acheve the same effect using the latest script language?
Thanks, Simon.
02-19-2020 03:02 PM
Hi Simon,
Just a thought, I have used the new Json read/write functions in 2019 in combination with a dictionary.
That lets me build up all the default parameters and then either pass the dictionary around to functions, or Can encode the dictionary into a json string, that can be then written to a *.json file. For my code I try to use Globals less, and a large parameter dictionary more.
This lets me keep the state from startup to using it latter in the example you presented. But it also allows me to remember settings between the calling of DIAdem. (This comes in handy when are setting a path one day and want the users to just keep those settings the next day. Reduces required clicks and entries.)
As a side note, I also use ini files in my DIAdem code quite, a bit, and have a nice vbs class that helps with if this is of interest.
Paul
02-20-2020 01:05 PM
Hey Simon,
As of DIAdem 2019 SP1, the UserVarCompile() command still works, even though the SCRIPT editor no longer colors it, and even though it shows up in the list of "obsolete" commands. It may eventually stop working, but I haven't heard any discussions about turning it off any time soon. There's a lot of old code out there that still uses those variables, and I'm not aware that the commands are actually causing trouble elsewhere.
It's fine to look for a solution based on newer technology, but I wouldn't say that this is an urgent matter at present.
Brad Turpin
Senior Technical Support Engineer
National Instruments
02-24-2020 05:52 AM
Thanks Brad (and Paul, above).
I was initially concerned that I couldn't find an easy alternative solution. However, I've since (re)discovered GlobalDim, which has a scope beyond script level, meaning I can declare variables that will remain alive whilst DIAdem is running. I can then use ItemInfoGet to determine whether they've already been declared.
On a related note of obsolesence, I would be very grateful if you might look at my post on path behaviour, as this would seem to be a case where a useful feature has been made obsolete without a replacement method being given.
Thanks, Simon.