Message discrepancies

[Sam]

There are some discrepancies between Windows message values and the equivalent IWB message IDs.
WM_CLOSE = 0x0010           where as  @IDCLOSEWINDOW = 0x8002
WM_ERASEBKGND = 0x0014 where as @IDERASEBACKGROUND = 0x800F
WM_MENUSELECT = 0x011F  where as @IDMENUPICK = 0x8003

Also, the actual message that your handler receives has been altered to reflect the change.
For example, if your handler is setup to receive WM_CLOSE, it won't get it. Unless you're working strictly in SDK. It will get the @IDCLOSEWINDOW.

From what I read in the help file, these messages should be equivalent.
I would have posted this in the bugs section, but it seems to be deliberate.
I don't get it.

[LarryMc]

It's a carry over from the very first predecessor of the language by the original author/owner nearly 20 years ago. That was an interpreted version.  I guess it never got changed so as to break all the preceding code as each variation came along.  Also, in the beginning there was no real focus on being totally supportive of programming with the SDK.  It was intended to be for BASIC type programming.

As far I as I know you are the first person who has ever noticed.
Another one is the @IDSIZE message which I believe combines WM_SIZE and WM_SIZING.


So, the reason it's the way it is is explainable and the likelihood of it being change is remote but I can't speak for LarryS.  He may look into the source and decide it would be easy to change (or that he can send both codes) and decide he wants to.  But the down side is it would break all the old windows programs unless everyone updated and then recompiled.

I'll add it to my todo list to make a note in the help file for those constants that are basically functional equivalents but not substitutes.

[LarryMc]

After a little more thought I think I've got a better explanation of why
WM_CLOSE /@IDCLOSEWINDOW
WM_ERASEBKGND/@IDERASEBACKGROUND
are different.

When an IWBasic window is created it not only creates the window with the appropriate SDK command it creates a UDT of WINDOW which holds several pieces of information. Some of it is font, pen, brush type info but it also sets up double buffering of the device context.
When the IWB window is closed all of that cleanup housekeeping needs to be done.  If WM_CLOSE was just passed through it would close the window but leave all that memory still in use.  So, in the IWB default(hidden) message handler the WM_CLOSE message is intercepted and the @IDCLOSEWINDOW message is sent in its place.

I'm not absolutely sure but I think the same thing is happening with WM_ERASEBKGND/@IDERASEBACKGROUND because of the internal double buffering.

[Sam]

I see what you're saying Larry. But, still not clear on why you would change the message value.
Here's the flow as I understand it:
Hook function intercepts the WM_CLOSE message.
Now release the CompatibleDC and any associated variables.
Then just send along the WM_CLOSE message to the window procedure - unaltered.
Wouldn't that work?
Not trying to be a PITA Larry.
It's actually pretty cool that the IWB window handles invalidations automatically. Normally have to do that by hand.

[LarryMc]

Can't say that I disagree with you.
But remember, I'm just a rank amateur when it comes to programming and I was using an entirely different language from a different author when the foundation for all this was being laid.
But I do know enough to know that there is more than one way to 'skin a cat"; especially in programming.