%NM_RCLICK weirdness..

[Borje Hagsten]

Trying to put a finishing hand to my editor control. This involves
implementing some NM_ notifications. In simple test program, no other
includes and suddenly, "%NM_RCLICK has not been declared."

A quick search finds it in COMMCTRL.INC. Don't understand the logic
there. Why is %NM_RCLICK regarded as different from for example
%WM_NOTIFY? Means slight trouble, must use the values (%NM_FIRST-5),
etc. instead. No big deal, but..

So for main thing: Sending %WM_NOTIFY to DDT dialog, negative values
like %NM_RCLICK seems to have to be tracked by using something like
"IF CLNG(@nmh.code) = %NM_RCLICK THEN". When trying without CLNG, no
response - negative %NM_RCLICK has wrapped over.

To me, this indicates that internal DDT dialog callback uses DWORD
for CBLPARAM? Could this really be the case? If so, think R&D maybe
should think again. lParam is often used for negative values, which
DWORD variables obviously cannot handle without wrapping.


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

[Borje Hagsten]

You can forget the last one, tested again and comparing with %NM_RCLICK
do work - I had another problem in my code. Also, looks like DDT engine
do use LONG's - it's the NMHDR code member that is declared as DWORD.

Ah, think I'll go fishing instead..


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

[Lance Edmonds]

DDT does use LONGs for most things, but improved DWORD interchangability is on the wish list.

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

[Tom Hanlin]

There is some sloppiness in the Windows SDK. It is not uncommon for Microsoft
to assign a negative value to a DWORD or vice versa, which works well enough
with current 32-bit C compilers (although it's considered a bad programming
practice). When comparing a LONG to a DWORD, 32-bit C treats both quantities
as 32-bit bitfields, y'see. In such a case, PowerBASIC would expand each value
to 64 bits, so as to compare them properly. These approaches do not produce
the same results.

Usually, this is not an issue, but it happens often enough that you should
keep it in mind. If you're using Win32API equates and are not sure whether
the values might wrap around, the safest technique is to use BITS to force
appropriate wrapping.

For example:

    ' if you defined hFile as LONG:
    IF hFile = BITS&(%INVALID_HANDLE_VALUE) THEN
 
    ' if you defined hFile as DWORD:
    IF hFile = BITS???(%INVALID_HANDLE_VALUE) THEN

------------------
Tom Hanlin
PowerBASIC Staff

[Semen Matusovski]

There is very simple solution - to change INCs (by program way ?).
All constansts shoud be exactly in form &Haaaaaaaa& and it will work with Long and Dword variables.
Let's say:
%INVALID_HANDLE_VALUE = &HFFFFFFFF&
instead of
%INVALID_HANDLE_VALUE = -1
That's all. And forget about ???.


------------------
E-MAIL: [email protected]

[Tom Hanlin]

Afraid not. &HFFFFFFFF& is exactly equivalent to -1&. It is not equal to the
DWORD value &HFFFFFFFF???.

------------------
Tom Hanlin
PowerBASIC Staff

[Semen Matusovski]

Tom --
Don't afraid. Better to test.

    #Compile Exe
    #Register None
    #Dim All
    
    %C1 = &HFFFFFFFF???
    %C2 = &HFFFFFFFF&
    
    Function PbMain
       Dim v As Dword
       
       v = %C1
       If v = -1& Then Else MsgBox "v <> -1&"
       If v = %C1 Then MsgBox "v = &HFFFFFFFF???"
       If v = %C2 Then MsgBox "v = &HFFFFFFFF&"
    End Function

Unf., I know this situation not from theory.

------------------
E-MAIL: [email protected]

[Tom Hanlin]

That's interesting. I'll have to investigate that. I'm not sure that
it's safe to rely on that behavior!

------------------
Tom Hanlin
PowerBASIC Staff