XMessageBox Error == 8

[tropfen]

Hello,

using the following source
iSt=xMessageBox("xxx","yyy",MB_ICONINFORMATION)
iSt Value of iSt is changed to 8

Looking at the SYSTEM_ERROR_CODES in MSDN it means:
ERROR_NOT_ENOUGH_MEMORY

Is this correct? It is an interessting place to get such error message. Or do I have to use a different Errorlist?

I am using IVF 10.0.26, XEffort 1.2.21, MS VS2005

Thanks in advance
Frank

[jimdempseyatthecove]

Frank,

The iSt (return value from MessageBox) is the ID code from the message box not the GetLastError code word. 8 is the MessageBox return code IDCLOSE.

I notice you are using xMessageBox, I imagine it is eventually calling MessageBox.

Jim Dempsey

[tropfen]

Hello, Jim

if the message is IDCLOSE, then i cannot understand the error during debug. The programm stops at this place and a message window is open saying "access violation during read"(free translation from the german message). And no MessageWindows was open containing my message.

In release mode the programm is doing nothing.

If XMessageBox is calling MessageBox and how we have to ask jugoslav.

Thanks in advance
Frank

[Jugoslav_Dujic]

Frank, XMessageBox was broken in Xeffort 1.2.21 (i.e. it did nothing); the last version 1.2.22 was issued in August only to fix that bug.

I'm not sure why it returned 8 rather than 0 or -1 (it calls DialogBoxIndirectParam, not MessageBox), but it's fairly moot anyway.

[jimdempseyatthecove]

Jugoslav and Frank

I've experienced an GetLastError of 8 in a completely different way. This may or may not be related. In an application of mine I could setup a test scenario that would do a few things then issue a DeleteFile(pFileSpec). For each run the the test program I would get a success, then next run fail (with error code 8), then next run success, then next run fail (with error code 8). I couldn't figure out the problem. When at error break point, then with seperate app (Windows Explorer or DIR from CMD window) the file specified for deletion was indeed deleted.

Additionally, in examining the C RTL code for DeleteFile, one can see that if an error occures that the WinNT error code is passed into a translator and eventually gets placed in the global symbol "errno". This is the error number location when programming in standard C.

When receving a non-zero return code from DeleteFile and obtaining 8 from GetLastError then inspection of errno yields 0. i.e. no error!

Very strange and contradictory.

Since the delete occures and errno is 0 my code will ignore the quirk.

It is potentially possible that the file system preloads an 8 into the last error, then is supposed to clear it just before exit (return to application). My guess is there is a return path where the error code is not reset.

If you think this is preposterous Intel IVF in V9.nn, for many Fortran RuntimeLibrary calls, wouildnot set the error code (STATUS=var)to 0 if no error (it would leave it as-is). This required clearing the status prior to the call.

Jim Dempsey