AnsweredAssumed Answered

vrf Annoying problems

Question asked by VRFuser on Jun 7, 2002
Latest reply on Jun 7, 2002 by VRFuser
> Hi all of you
> I have been developing a VEE-based test system under a longer period, and have experienced a lot of problems with VEE Pro 6.01. We usually run on Win2K but also Win98. We have encountered the same problems on differently installed computers.
> Can anyone give me any good solutions to these things:

Let us say I input a big record to a formula box, and use that formula box to test the presence of a specific fieldname. If it exists the result (the field data) goes to the Result outpin. If the field does not exist I use the optional error pin to ping a default value. And finally I junction the default and result values together to assure that the data is available...

I have discovered that doing these kind of operations often result in massive memory loss. My guess would be that VEE forgets to deallocate the interminal data to the formula if the formula fails to execute, or perhaps the last Error information allocates new dataspace for each error, and old errors are not deallocated.

I would hate to do these kind of field presence verifications using a more basic way - to verify that input is really a record, then to unbuild the record and then do string compares for each field to look if field is present... It's a much timeconsuming process and requires much more code.

> REAL32/64
> When we use real, for instance asreal32("18")/10, we get strange rounding problems for some numbers. If I display the results of this formula in a AlpaNumeric display it says 1.8 but if I just look at the "tooltip box" on the line, or try to export the results to a text file, the result is 1.799999952316284. The most annoying case is if we for instance set a DLS400 to a certain noise level - the instrument will recieve :SOURCEA:XTALKA:LEVEL -88.79999952316284 or something which is a invalid syntax. We must use a ToString-object to limit the fracts to 1 digit.
> I have a case when I save a panel as a image. I've tried different output formats, and different color levels, but it seems like the filesize is always the same except for BMP's (GIF/16, GIF/256, JPG). Fact is that JPG- and GIF-files appears to look exactly the same when I open them in a hex viewer independant of colorlevel or JPG/GIF - JFIF, Lead Technologies V1.01...
> The OK buttons work pretty good, but they could be improved. If a button is pinged at the same time as the execution continues (thread splits) the button is not alway lit - this seems to be resolved by setting a 50ms delay in the thread not pinging the button. Also, if I call a sub function from thread parallell to a lit button (a cancel button which should cancel the call/the other thread) the button sometimes works and sometimes not! Any suggestions?

I actually miss these objects in VEE:
- To create a record with a userdefined fieldname (a build record object, but with a modular field name)
- To test presence of a field in a record without using error pins (see above)


I can create a function which is called "init" in a VEE-program. If I create another userfunction, "CallInit", in this program which do a "Call init", and then import this library to a new program and call the "CallInit" I may call the VEE built-in function init().

I understand why it happens, but wouldn't it be better if a function calling another function would start looking for that function in its own library before it starts looking elsewhere? Also: If I import 10 VEE-programs with functions called the same name, the same problem occurs - you never know which library executes the function unless you use libraryname.functionname (which gets stupid because if you call functions within "the own library" you would have to call all like mylibraryname.mylocalfunction to ensure that you never call an outside function).

Can I refer to VEE builtin function with some kind of libraryname.functionname standard? For instance VEEMain.init or something?

Yet another interesting thing; if I try to merge the library with the init-function, this cannot be done - VEE recognizes that the program has a function which also is available as a built in function. INTERESTING!


Has anyone written any kind of C-based "container parser" or "dataset parser" to be able to handle VEE records in DLL's? It could be interesting to see some examples. My solution was to unbuild the VEE record in VEE, store as a textfile and then call the DLL with the filename of the textfile. And the same method for passing data from the DLL to VEE - textfile gets imported and converted to a VEE record, but it would be even better if data could be parsed in the DLL by just passing the record or a record unbuild to a string array describing the record (container) directly to DLL;

A typical textfile could look like this:


> Thanks in advance
> /Tomas
This is the "vrf" maillist, managed by Majordomo.  To send messages to
this maillist, just email to "".  Subscriptions and
unsubscriptions are done through the address "".
If you need details, just send a message containing the text "help"
to "".