size_t in GUI numeric control

[JGS]

I am trying some CVI behaviour for 32- and 64-bit application. Specific, I want to build the application so that I only need re-compilation for either 32- or 64-bit output. One of these is using signed and unsigned integers as input and outputs in GUI. I would like to set the OS data type directly in the GUI, but the types ssize_t and size_t are not available in the interactive tools. So I build a GUI for 32-bit
- using int as numeric input (hot)
- using unsigned int as numeric outputs (indicator)

After loading the GUI in main-function, I change the control attributes for data type:
- the programming "recall function panel" has the OS dependent integers as option
- SetCtrlAttribute (mainp, PANEL_INPUTVALUE, ATTR_DATA_TYPE, VAL_SSIZE_T);
- SetCtrlAttribute (mainp, PANEL_OUTPUTVALUE_1, ATTR_DATA_TYPE, VAL_SIZE_T);
- SetCtrlAttribute (mainp, PANEL_OUTPUTVALUE_2, ATTR_DATA_TYPE, VAL_SIZE_T);
I get no errors on compilation. As expected, nothing really changes for 32-bit debugging i.e. nor errors. And when running 64-bit debugging it also starts without any (obvious) errors. And it goes beyond the 32-bit limit of 2^31.

Now I try an alternative: I define the GUI for 64-bit e.g. with data types int64 and unsigned int64. When the data types are changed after loading the UIR in main-function, I get non-fatal errors:
- For the first line for the numeric input: the attribute passed is not valid (error -46).
- For the second and third lines for the numeric outputs: Invalid control ID (error -13).
- And afterwards, all three numerics disappeared from the GUI.
These error happens when I run it in 32-bit as well as 64-bit.

The disappearance of the controls looks somewhat as discussed before. However the GUI is new and build in CVI2010.
(http://forums.ni.com/t5/LabWindows-CVI/edit-numeric-control-of-type-int64/m-p/1411662#M50699)

Q1: Is there an restriction on building the GUI with int64?
Q2: Is there a fix where I can use VAL_SIZE_T and VAL_SSIZE_T when building the GUI manually?

I am using:
Windows 7 x64
CVI2010 (10.0.1)

Regards, Jos

[Wolfgang]

Hi,

in a somewhat similar question I have learnt here that at present (up to and including CVI2010) the data type of the control has to be set programmatically...

Wolfgang

[JGS]

Hello Wolfgang,

You confirm that - again - I missed some messages in the forum. And you also confirm that there is something not working as it should.

For now, I have a working solution with UI editor settings for 32-bit and upgrade it in the code to size_t and ssize_t. And I have to wait until NI has added these data types to the UI editor.

Still it bothers me that the controls disappear from the GUI when set with UI editor to "int64" or "unsigned int64". If this is a shortcoming of the UI-editor ... no problem. If this is a flaw in  LoadPanel, I have to check each control extensively. Therefore I do not yet "Solve" this discussion, hoping that NI explicit appoint the cause to the UI-editor only.

Thanks, Jos

[Wolfgang]

Hello Jos,

don't bother about having missed one out of 57000 messages in the CVI forum 

I can add that in the UI editor of the 2012 beta there are two additional data types, called intptr_t and unsigned intptr_t which seem to address this issue

[LuisG]

Hi Jos,

You should be able to use 64-bit integers in numeric controls without any problem, whether you are building 32-bit or 64-bit programs. Can you give us some more details about the errors that you're seeing? Which function exactly is returning these errors? It would be better yet if you could attach a small program that reproduces these errors.

Luis

[JGS]

Hello Luis,

The CWS in the attached zip-file has been build to check DLL loading because other 64-bit software (matlab) gives error on __fastcall.

Purpose: build simple 64-bit DLL with either __stdcall or __fastcall and try these in other software.

Also: build simple GUI-exe for loading DLL in CVI software. (This is my first DLL use without a lib-file ie not nice and probably with some mistakes)

Accidentally an - yet unexplained - error occurs when running the CVI exe:

when using "int" and "unsigned int" in the UI editor, conversion to size_t in "main" works fine

when using "int64" and "unsigned int64" in the UI editor, conversion causes runtime error

The attached workspace has the code for the working version:

build the 64-bit (and 32-bit) release for the DLL

run the (debug) 64-bit version for the GUI-exe ---> no obvious errors

change with the UI -editor the data types for input/output to "int64" and "unsigned int64", and run it again --> error as shown in the screendump

The OS is Windows 7 x64

The CVI version is CVI2010, 10.0.1 (419)

This happens identical on two computers (home and business)

Thanks in advance, Jos

[LuisG · Accepted solution]

Hi Jos,

The runtime error is caused by the fact that those two controls don't exist in the loaded panel. You can see what's happening more clearly if, after you save the file, you close the window and then reload the file. You'll notice that those two controls will now be missing.

The reason the controls are not being saved when they use the 64-bit data types is because the UIR is set to use the CVI 8.1 format. You can see this in the lower-right-hand corner of the UI Editor window. Because 64-bit data types in UI controls were not introduced until version 8.5, these controls cannot be included in an 8.1 UIR.

We have already identified this scenario as a major usability flaw: when you save the UIR in an older format, CVI should show you a warning telling you about all the controls, or other features, that were not saved as a result of saving it in the older format. This has been corrected in a future version of CVI but, until then, this is something that you have to look out for.

To save the file in the CVI 2010 format, you need only select File>>Save As... and then select 2010 as the version in the "Save as type" list.

Luis

[JGS]

Hello Luis.

I have never selected on purpose the generation for the UIR format. Always used "Save As", enter an UIR name and push the save button.

The default type is possible from some work on another CWS that originated from version 8.1.

Although you showed that the flaw is in my own work, thanks very much.

Regards, Jos

[LuisG]

The way it's supposed to work is that when you load a .uir saved in a previous version, and then save it, it should be saved in the current format unless it had, at some point, been explicitly saved in an older version.

For example, if you save a .uir file in CVI 8.1 using the default 8.1 format, and then load it in CVI 2010, when you resave it it should then be saved in the 2010 format.

By contrast, if you save a .uir file in CVI 2009 using the non-default  8.1 format, and then load it in CVI 2010, when you resave it it will continuing being saved in the 8.1 format, unless you explicitly change it to 2010.

This is how it's supposed to work. But it sounds like this was not what happened in your case. My guess is that you ran into this issue.

Luis