Duplicate equates in Win32API.Inc

[DienyduToit]

Note that %BN_CLICKED and %STN_CLICKED are both zero, and both arrive under %WM_COMMAND. So, if both of the former two occur in a Select Case structure under %WM_COMMAND, only the first of the two will respond. Other than to allocate a different value to one or the other, one simply has to omit the second Case statement so that it resorts under the first, and then all is well. One could also say

"Case %BN_CLICKED, %STN_CLICKED"

which is the same as "Case 0, 0".

Being stupid, I wasted some two hours before discovering this.

[Lance Edmonds]

Not duplicate equates, but two different messages that have the same numeric value.

BN_ messages come from button controls.
STN_ messages come from static controls with the SS_NOTIFY style.

Generally speaking, you could respond to a %WM_COMMAND message by establishing the ID or hWnd of the control that originated the message... That way the actual notification message would not be considered until after the control was identified:

ie, in DDT psuedocode

SELECT CASE CBMSG
  CASE %WM_COMMAND
    SELECT CASE CBCTL
      CASE %ID_STATIC1
        SELECT CASE CBCTLMSG
          CASE %SS_CLICKED
            ...
        END SELECT
      CASE %ID_BUTTON1
        SELECT CASE CBCTLMSG
          CASE %BN_CLICKED
            ...
        END SELECT
    END SELECT
END SELECT

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[DienyduToit]

Lance, I respectfully beg to differ - this appears to be a slip or weakness in Windows itself. The code --

Select Case CbMsg

Case %WM_COMMAND

Select Case CbCtlMsg

Case %BN_Clicked
(code)

Case %STN_Clicked
(code)
End Select
End Select

-- seems perfectly logical, but the %STN_Clicked is ignored for the reason discussed. No reason why one should not respond to a label being clicked.

This does not create a problem if one knows about it, of course.


------------------

[Lance Edmonds]

Ok, thinking about the code within a %WM_COMMAND handler:

If you separate the control ID's and create a SELECT-CASE or IF-THEN block based on the range of control ID's in the dialog or window, then each "block" within the %WM_COMMAND handler will relate to a particular control.

However, If you base your block structures around the type of control-notification message, then each block of code in the %WM_COMMAND handler will be only for the notification message.

So, if we consider these two approaches, and we move along with the app's development to debugging the action of a particular control (which happens quite often); Is it easer if the message code for each control is located in the same block of code, or is it easier if each handler for a control's notification message appears in a separate block?

I'll leave it to you do decide which approach is easier in the long run. I know which approach I use.

However, I do take your point about message values that become 'obscured' by the use of equates... the problem they cause is exactly like you faced in this thread.

While the concept of having each style of control use a dedicated set of equates, overlap between controls in inevitable. One of the hardest bugs to find (and I've seen this happen) is to accidentally use a style from a different class of control; ie, using a button style in a toolbar style. Because some style equates are based on bit-wise values, and some use a range of consecutive values; then intermixing these two wrongly can produce strange and subtle bugs!

However, from a code-maintainability aspect, it is far easier to determine the style of a control if everything uses equates rather than a hard-coded style value. I guess that there are good and bad aspects of either each approach.

On an mainly unrelated topic, (I promise I'll come back to this topic at the bottom!)...

One thing I have found interesting to do in order to minimize the size of my compiled code (especially for DLL's), is to abandon the use of #INCLUDE "WIN32API.INC", etc, and manually cut & paste in every equate and structure used in the code.

It is a long winded exercise, but you may be amazed at what your code may be referencing - I highly recommend this procedure is done at least once, even if it is just for educational purposes.

In fact, when I go thorough this exercise, it often spurs me on to try to reduce the level of dependancy on some of the stuff in the INC files, and optimize my code further.

That said, I do usually place it into an conditional compilation block:

#IF %USEPBDECLARES
  #INCLUDE "WIN32API.INC"
  #INCLUDE "COMMCTRL.INC"
  ...
#ELSE
...cut and paste of every declaration actually used.
#ENDIF

By employing a conditional compilation block, you can switch back & forward between the two sets of declarations - which is sometimes useful, especially if you just want to add a new function for testing, or you download a new version of WIN32Api.inc from the PB FTP site.

If you are using a slow PC, the biggest benefit is the compilation speed - without WIN32API.INC compilation time is greatly boosted for even medium/large applications!

So, returning to the discussion at the beginning of this message, if you do copy all of the stuff you actually use from WIN32API.INC into your code, you'll (hopefully) end up with a set of equates, and comparing the values of the equates your app is actually using often quite interesting. You'll start to pick up on the nuances like %STN_CLICKED has the same value as %BN_CLICKED, etc.

Whew...! I think that was my longest self-justification response to date! Anyway, food for thought for y'all.


------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Eric Pearson]

> this appears to be a slip or
> weakness in Windows itself.

I think it goes back to the early days of Windows, when the API was based on 16-bit values. There were only 65,536 possible values for all of the myriad things like %BN_CLICKED and %STN_CLICKED, so making every value unique was considered to be impractical, from the standpoint of leaving room for open-ended future expansion.

> The code (...) seems perfectly logical

Ah, I see the problem... you're not using the $DWIMNWIS (Do What I Mean, Not What I Say) metastatement.

-- Eric


------------------
Perfect Sync: Perfect Sync Development Tools
Email: mailto:[email protected][email protected]</A>



[This message has been edited by Eric Pearson (edited June 13, 2000).]

[DienyduToit]

Thank you, Lance and Eric. The learning curve continues, more continue than curve!

Lancce, I took your tip about the #Include "WIN32API.INC and did as below, meaning to have Pb doing the dirty work of finding missing whatevers. NOTHING HAPPENED! All works as before!

'#Include "WIN32API.INC"
#Include "COMMCTRL.INC"
'#Include "COMDLG32.INC"
'#Include "RICHEDIT.INC"
'#Include "MDI32.INC"
#Resource "Basix.PBR"

Yet, I call GetMessage and SendMessage and any number of others. Possibly they are all present in COMMCTRL.INC but in any event, I have left it as per above, and it makes only a small difference to compile time (compile and run) on my ancient 166Mhz Pentium. Haven't checked compiled exe sizes yet.

Btw, for "duplicate equates", read "synonomous equates" ...



------------------

[Lance Edmonds]

Well, you are being fooled by the INC files! Your comment about compile times not changing much is due to the following:

If you look att COMMCTRL.INC, you'll find the following lines:

#IF NOT %DEF(%WINAPI)
    %CCWIN = 1   ' we want the GDI calls defined
    #INCLUDE "WIN32API.INC"
#ENDIF

So, even though you remmed out the WIN32API.INC file, COMMCTRL.INC was putting it straight back in on your behalf! Pretty clever, eh? Conditional Compliation can be very powerful, and sneaky at the same time!

Try it all again, but this time, REM out all of the INC files, and with each subsequent compilation failure, just paste the appropriate declaration/structure/equate from the INC files into your source. Repeat until compilation is successful.

Now, you should definitely find a big difference in compilation speed, and your EXE or DLL may even be a few Kb smaller too.


------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Cecil Williams]

Dieny,

Yet, I call GetMessage and SendMessage and any number of others. Possibly they are all present in COMMCTRL.INC but in any event

The GetMessage() and SendMessage() functions are located in the win32api.inc file. These files that you include are all "TEXT" files and as such can be read by any text editor program. It's a good idea to stroll thru these files just to get a feel for what info these contain.

Cheers,
Cecil

------------------

[DienyduToit]

Lance, your tip about removing the #include for Win#2API.Inc: I have done that, and then spent some hours compiling and recompiling, progressively copying and pasting the missing items into a new #include file of my own.

I can now report back as follows:

.Bas file .Exe file Compile time

Before: 510,668 414,208 8.5 seconds

After: 510,366 401,408 2.4 seconds


I'm not greatly concerned about the size, but that time improvement is truly dramatic. Of course, the Win32API.Inc is over 788K - my new .Inc file is 22,675 bytes! This may grow a little, but at this stage of the game there is unlikely to be much more needed there.

When I asked - late last year, I think - whether PbDLL6 with DDT is "a complete GUI tool", you answered "Yes". This has proved to be totally true - the Delphi screens (of the previous attempt to get this application into Windows) now look pathetic; not the layout, but the painfully jerky way they appear, and ten times worse when they are removed - all those layers peeling off one by one, I guess.

My PbDLL6/DDT screens are instant, clean and respond to user interaction instantly as well. The half-completed Delphi Exe is close to 5 Meg - my Pb module (mentioned above) is less than ONE TENTH of that. Both utilise DLL's written (by yours truly) in PbDLL6, but there is no comparison between the two methods. Delphi's Pascal language is simply a pain (e.g., a floating point variable holding a value of (say) 12 CANNOT be placed as-is into an integer variable - it complains bitterly about "incompatible types" - and treats everyone as a raw beginner). Having been with PowerBASIC from the beginning (from the first Turbo Basic in the eighties) one has, I guess, an unfair advantage.

One never stops learning in this game (I came into it at the beginning of 1957 when computers were few and huge, running on thermionic tubes and eating and spitting out punched cards) and in the present context
I'm a tyro all over again (and my Petzold book shows no signs of arriving, though it is supposed to be due this month), but I AM recreating our old DOS application in PbDLL/DDT and the results are simply beyond belief.

This is thanks in no small way to the help you and others have given freely and frequently. I hope and believe that our final product will be a credit to PowerBASIC as a superlative language which has all the
essentials in its toolkit - and nothing non-essential.


------------------