Can someone explain this program to me ?

[sunshine33]

Thanks LordAdef , Lonewolff

I have a good idea now about how to make those window frames with MASM and some include files .
I am also trying to put a program together with that , that ask's for number input and display the output sum .

[jj2007]

Always good to check the value of EAX after the RegisterClassEx and CreateWindowEx.

Checking the return value of RegisterClassEx will rarely help, but checking CreateWindowEx can avoid situations where your programs hangs invisibly and can only be killed with Task Manager.

If the return value is zero, the call failed for the reason stored in EAX.

Check your logic: if eax is zero, there can be no extra information stored other than "it failed". However, you can use print LastError$() (or Print Err$() in MB) to get the reason (attention, not all WinAPI functions set or reset this value; sometimes, you see an error but the return value of eax is OK, meaning there is no error).

[hutch--]

This much you will find with the bare mechanics of creating a window, get it right and the return values rarely ever matter. Evaluating return values when the code is correct to start with is a waste of space, just do it the right way the first time and the window will work.

[Lonewolff]

Right you are.

Those two functions return zero on fail.

Code Select Expand

invoke GetLastError

This will store the actual error code in EAX.

Evaluating return values when the code is correct to start with is a waste of space, just do it the right way the first time and the window will work.

Hmmm. Yeah, but once you start experimenting with window styles, menus, etc. it is quite easy to trigger a failed call.

Once it's right, it's right. But nice to know what you are breaking when you do make something go wrong.

Can't have enough error checking, I say. Especially when you move into the realms of DirectX and not all graphics cards are created equal. What runs on one system will most certainly go bang on another.

That's where error checking and 'failing back' comes in.

To me it's a great habit to get into. Much rather being overly cautious than to have someone report that the application 'just closed' with no warning.

If any of my applications crash, it will report what went wrong (99% of the time).

[jj2007]

Can't have enough error checking, I say.

Right, but as Hutch wrote above, seek a balance - not every function has to be checked if the code is ok.
What you can do in any case is use macros that check for errors while testing but do not generate code when testing is over. Here is an example that I created for testing my GDI+ functions. Usage example:

invGdip GdipCreatePen1, argC$, i2f(argW$), UnitWorld, addr penName

It has three modes:
- no checking, no extra code generated
- shout foul if the function returns a value other than S_OK
- print the result to the console even if it is OK (for monitoring a sequence)

Code Select Expand

invGdip macro gpCall, args:VARARG
Local tmp$
  ifidn <args>, <#>
call gpCall
  else
if @InStr(1, <args>, <esp>)
tmp$ CATSTR <## line >, %@Line, <: do not use esp as gdi+ argument ##>
% echo tmp$
if usedeb
  .err
endif
endif
push ecx
invoke gpCall, args
pop ecx
  endif
  ifndef invGdipOK
invGdipOK=0 ; >1 means show only failures
  endif
  if usedeb or invGdipOK
if invGdipOK eq 1
% echo gpCall args
endif
.if eax || invGdipOK eq 1
pushad
xchg eax, ecx
tmp$ CATSTR <Print "** line >, %@Line, <, &gpCall">
tmp$
PrintLine At(44, Locate(y)) Spc2$, gdiStatus$(ecx), Spc4$
popad
.endif
  endif
ENDM