GetGeneralErrorString does not recognizes error -180

[RobertoBozzolo]

As the title says, Programmer's Toolbox function GetGeneralErrorString () does not recognizes error -180 (which relates to ActiveX and FileSelectPopupEx function).

When called with value -180, the function returns "No description available", while GetUILErrorString () returns the correct description for that error.

It seems to me that the error radicates in a incorrect userint.h file:

	/*** errors returned by User Interface Library functions: ***/
typedef enum
{
	UIENoError                                                  = 0,
	UIEManagerCouldNotOpen                                      = -1,
...
	UIEInvalidAngleInMetaFont				= -178,
	UIECellCannotBeMadeActive				= -179,
	UIEErrorLimit						= -180
} UIError;

As you can see, there should be a specific item in the enum for GetGeneralErrorString to work correctly:

char * CVIFUNC GetGeneralErrorString(int errorCode)
{
    int                 absError = ABS_VAL(errorCode);
#if defined(_NI_mswin_) && _NI_mswin_
    int                 tracking = SetEnableResourceTracking (0);
#endif

if (absError < ABS_VAL (UIEErrorLimit))
    {
    (bla bla)

Don't know how GetUILErrorString is implemented, but apparently it does not rely on that same enum...

[Constantin--P]

Hello Roberto,

Indeed the 2 functions use different mechanisms that are not in sync(userint.h should have been updated with UIEFileDialogWrongConcurrencyModel)

I've created CAR ID 647044 for the issue in question.

Constantin

[RobertoBozzolo]

As a side note, when called for error -180, GetGeneralErrorString produces a long list of lost memory blocks (the Resource tracking lists 3000+ of them  , each with the line of the function and the line of RunUserInterface in the call stack).

[Constantin--P]

When you call GetGeneralErrorString with -180(or an invalid error code) the code takes a different path that allocates some memory once and stays allocated while the program runs. You can see exactly where the memory is allocated if you add toolbox.c in your project rather than toolbox.fp(see image below).

So it is a one-time memory allocation that stays allocated while the program runs.

[RobertoBozzolo]

What I don't understant is why you get 4 lost blocks while I get 3000+ !!

As you pointed out, all that memory is allocated in AppendString which is repeatedly called by CVINiErrParseFile () function; it seems to me a correct coding should be made to free all those blocks when no longer needed: even considering a few dozen bytes per block, the total memory lost on one single call of GetGeneralErrorString is important if multiplied by 3000+ ocurrences!

[Constantin--P]

In my screenshot I was suspended at a breakpoint but after everything executes there are about 256 blocks.

The reason for allocated blocks are not freed at the end of GetGeneralErrorString is that you might call GetGeneralErrorString again and need to allocate all again in this case. The occupied memory is not very high, it's about the size of the files in C:\Program Files (x86)\National Instruments\Shared\Errors\<language>(~40k)

[RobertoBozzolo]

Situation on my machine is a bit different from yours, but I suppose can stand with it since at least memory is reused...

Here is the result of CVIDynamicMemoryInfo called before and 2 times after FileSelectPopupEx: almost 4000 blocks and 650kb memory... As you say, it is about the size of that folder, which appears to be populated by various products installed: in my case DAQmx alone adds ~350kb of error file.

Dynamic Memory Information: Before FileSelectPopupEx
Total number of block allocated: 3
Total number of bytes allocated: 9024


Dynamic Memory Information: After FileSelectPopupEx
Total number of block allocated: 3979
Total number of bytes allocated: 668680


Dynamic Memory Information: After FileSelectPopupEx
Total number of block allocated: 3979
Total number of bytes allocated: 668680

[RobertoBozzolo]

Seems in this period I am getting all error checking troubles.... 

DAQmxGetErrorString does not return any string if called for ErrorCode = 0 or DAQmxSuccess which is the same.

It's true that if called with ErrorCode = 0 and ErrorString NULL or BufferSize = 0 it returns 0, so the user is warned not to expect any message, but this forces to a double-call of the function every time just to check whether it will return something or not.

This is not consistent with other libraries (including GetGeneralErrorString) which gracefully return some "No error" or similar message.

[FigueroaAndState]

Hey Man I almost figuered ot out.