Announcement

Collapse
No announcement yet.

MainWndProc..

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • MainWndProc..

    A tip and a question. I ran my head into the wall here for a while,
    trying to send a negative lParam value to a control with no result.
    Turned out I had declared all four members in control's MainWndProc
    as DWORD's. Yes I know, I sometimes do such stupid things..

    Anyway, I looked around at some samples in source code Forum and
    discovered I'm not the first one to do this mistake. In several
    samples, members like lParam is declared as DWORD, with the result
    that you never can send a negative value to that member.

    Okay, so that was the tip. Check you message handlers - wParam and
    lParam must always be LONG's (%TRUE is negative = -1).

    Now for the question: Does this also apply to hWnd and wMsg? I
    noticed different examples on this one as well, where both DWORD
    and LONG was used in a mix. What gives? Is there ever a situation
    where using LONG's all the way would risk breaking some message or
    hWnd? This is how I usually do it ( when my mind is working), but
    is it 100% safe in all systems/situations?
    Code:
    FUNCTION MainWndProc(BYVAL hWnd   AS LONG, BYVAL wMsg   AS LONG,_
                         BYVAL wParam AS LONG, BYVAL lParam AS LONG) AS LONG

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

  • #2
    Borje --
    Not agree with you. For OS it's not important DWORD / LONG.
    Code:
      #Compile Exe
      
      Function DefWindowProc (ByVal hwnd As Long, ByVal wMsg As Long, ByVal wParam As Long, ByVal lParam As Long) As Long
         Function = lParam
      End Function
      
      Function CallBackWindowProc (ByVal hwnd As Dword, ByVal wMsg As Dword, ByVal wParam As Dword, ByVal lParam As Dword) As Dword
         Function = DefWindowProc (hwnd, wMsg, wParam, lParam)
      End Function
      
      Function PbMain
        Dim m As Long, n As Dword
        m = CallBackWindowProc (0, 0, 0, -15)
        n =  CallBackWindowProc (0, 0, 0, -15)
        If m = n Then MsgBox "Equal" Else MsgBox "Not equal"
        MsgBox "m=" + Format$(m),, "n=" + Format$(n)
      End Function
    Another question that you should operate correctly inside your sub.

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

    Comment


    • #3
      Confusing, to say the least. In your sample, try following:
      Code:
      FUNCTION CallBackWindowProc (BYVAL hwnd AS DWORD, BYVAL wMsg AS DWORD, BYVAL wParam AS DWORD, BYVAL lParam AS DWORD) AS DWORD
        IF lParam = -15 THEN BEEP
        FUNCTION = DefWindowProc (hwnd, wMsg, wParam, lParam)
      END FUNCTION
      You get no beep, DWORD range starts from 0, so it can never be -15.
      This is what I meant. In a message handler, it never traps negative
      values if member is declared as DWORD. Sending %TRUE (-1) to it of
      course gives same (none) result.


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

      Comment


      • #4

        Borje,

        I think it stems from PowerGen generated code - PowerGen outputs window procedures with parameters as DWORDs.

        Personally, I always use LONGs.

        Regards,



        ------------------
        Kev G Peel
        KGP Software, Bridgwater, UK.
        http://www.kgpsoftware.com
        kgpsoftware.com | Slam DBMS | PrpT Control | Other Downloads | Contact Me

        Comment


        • #5
          Borje --
          It's not difficult to imagine, how PB works.
          I suggest you three correct variants instead of one incorrect

          Code:
            #Compile Exe
            #Register None
          
            Function CallBackWindowProc (ByVal hwnd As Dword, ByVal wMsg As Dword, ByVal wParam As Dword, ByVal lParam As Dword) As Dword
               ' Incorrect
               If lParam = -15 Then MsgBox "Yes 0" Else MsgBox "No 0"
            
               ' Variant 1
               If lParam = CLng(-15) Then MsgBox "Yes 1" Else MsgBox "No 1"
          
               ' Variant 2
               Dim m As Long:  m = -15
               If lParam = m Then MsgBox "Yes 2" Else MsgBox "No 2"
               
               ' Variant 3
               If CLng(lParam) = -15 Then MsgBox "Yes 3" Else MsgBox "No 3"
            End Function
          
             Function PbMain
                CallBackWindowProc 0, 0, 0, -15
             End Function
          BTW. API "True" is 1 (as I remember). But anyway should work
          If lParam Then
          If IsTrue(lParam)

          Don't know like others, but I can't imagine negotive handle (hWnd, hInstance, hBmp and so on).

          [This message has been edited by Semen Matusovski (edited February 04, 2001).]

          Comment


          • #6
            Or :

            Code:
              #Compile Exe
              #Register None
            
              Function CallBackWindowProc (ByVal hwnd As Dword, ByVal wMsg As Dword, ByVal wParam As Dword, ByVal lParam As Dword) As Dword
              
                 ' Variant 1
                 If BITS&(lParam) = -15 Then MsgBox "Yes 1" Else MsgBox "No 1"
            
                 ' Variant 2
                 If lParam = BITS???(lParam) Then MsgBox "Yes 2" Else MsgBox "No 2"
                 
              End Function
            
               Function PbMain
                  CallBackWindowProc 0, 0, 0, -15
               End Function

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

            Comment


            • #7
              Thank you fellows. Everything is clear as mud now, to use one of
              Lance's favourite expressions..

              I'll use LONG's, as I usually do. Yes, Kev, I probably looked at a
              PowerGen message handler from start. Reason why I ran my head into the
              wall was the implementation of EM_SETSEL into a custom-built editor.
              Sending -1 via lParam should tell it to select all, but -1 never came
              through properly. Changed both params to LONG's and now it works fine.

              Will use DWORD for wMsg and hWnd though, to be on the safe side.
              Can't imagine negative values there, but maybe higher than MAXLONG.


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

              Comment


              • #8
                DWORD & LONG are both 4 byte data types, they interpret "-1" differently, but the underlying bit pattern for it is valid in either type.



                ------------------
                Bernard Ertl
                Bernard Ertl
                InterPlan Systems

                Comment


                • #9
                  Borje --

                  lParam is supposed to be a LONG, and wParam is supposed to be a DWORD. You'll get the best results if you do it that way.

                  If you use a DWORD for a handle value like hWnd, the only time you really have to worry about a negative value is %INVALID_HANDLE_VALUE, which is defined as -1 and is returned/recognized by many different API functions. If you change your program to use DWORD handles, you should change the definition of %INVALID_HANDLE_VALUE in WIN32API.INC to &hFFFFFFFF???, which is the DWORD version of the same bit pattern as a LONG with a value of -1.

                  Another complexity is that sometimes, rarely, Windows uses lParam for a handle value, so you have to watch out for that. If you are using DWORD handles you might get unexpected results.

                  As others have pointed out, the BITS functions can be used to covert LONGs to DWORDs and vice versa if you run into a problem.

                  -- Eric


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



                  [This message has been edited by Eric Pearson (edited February 04, 2001).]
                  "Not my circus, not my monkeys."

                  Comment


                  • #10
                    Took a quick look into win32api.inc and saw that SendMessage uses
                    longs all the way. In other words, in PB/DLL, message handlers also
                    should use longs all the way. (I think I'm absolutely sure now..)

                    Yes, I know about difference and non-difference, but when making
                    a control compliant with existing messages like EM_SETSEL, it's
                    important that -1 always works in easy way. Using longs, it always
                    works, in easiest way.


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

                    Comment


                    • #11
                      Borge --

                      I believe that the SendMessage declaration in WIN32API.INC is incorrect.

                      The original 16-bit Windows messages were called lParam and wParam. The w stood for WORD (unsigned, 2 bytes), and the l stood for LONG. Remember, however, that in 16-bit Windows a "LONG" was what we now call an INTEGER. A signed integer, 2 bytes.

                      The same names were carried over to 32-bit Windows. Instead of calling them lParam and dwParam, they kept the old names. But the "Hungarian" prefixes do tell you what the data types are supposed to be.

                      HTH.

                      -- Eric

                      P.S. Thanks to Tom Hanlin for explaining this to me, not long ago.

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

                      [This message has been edited by Eric Pearson (edited February 04, 2001).]
                      "Not my circus, not my monkeys."

                      Comment


                      • #12
                        Interesting, Eric. Question is, if SendMessage and other message
                        calls in win32api.inc uses Longs all the way, what's the use of
                        using Dwords anywhere in message handler? Maybe for compatibility
                        reasons in DLL's?

                        I'll use Longs while I look for another job. This one is not good
                        for my nerves..

                        Thank's Eric. Just saw you answer. I may even understand all this one day..

                        Looking at it again, I now do understand - thanks a lot!
                        ------------------




                        [This message has been edited by Borje Hagsten (edited February 04, 2001).]

                        Comment


                        • #13
                          there is an "interesting" bug with constants - see http://www.powerbasic.com/support/pb...ead.php?t=2833

                          to bypass it i used
                          i = %tvi_root
                          sendmessage htree, %tvm_deleteitem, 0, i

                          but, of course, there is a lot of another solutions.


                          ------------------
                          e-mail: [email protected]

                          Comment


                          • #14
                            > but, of course, there is a lot of another solutions.

                            Yes, and this is both the strength and weakness of PB. Strength,
                            because flexibility allows us to fix anything that behaves strange.
                            I like that, even if adds to development time.

                            Weakness, because since no updates are released between major
                            releases of the compiler, we keep bumping into them again and
                            often forget the solutions between each time. Don't like that,
                            because it adds to development time.

                            This one was not a bug though, other than between my ears. It's
                            easy to see PB developers are confused, because looking at the
                            samples in source code gives us many different variants of same
                            thing, especially what should be simple, like a message handler.
                            Maybe idea for PB to include a small API section in help file that
                            explains some basic things about SDK style programming with PB.

                            Tip to PB people. Minor version updates always gives me a boost
                            in sales. I always sell much more of version x.2 than x.1, x.1
                            than x.0, etc. Reason is because people see the program is "alive",
                            under constant improvement. Some developers even skips x.0 and go
                            straight at x.1 just because of this.

                            It also keep existing users happy, since minor things are fixed
                            in each one. You already make us happy with v6, but we'd be even
                            happier with a 6.1.. (and in heaven with a v7..


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

                            Comment


                            • #15
                              I am a fan of flexibility and using LONG for the WndProc parameters
                              is reliable and flexible. Strong typing runs the risk of making
                              what is basically a simple set of 32 bit parameters complicated
                              and generate errors where theyr is no point in doing so, programmers
                              write to get results, not play with the cypher. Lets leave Delphi
                              and its strong typing to Stephane.

                              About the only problem you can get using LONG generically is when
                              a value is larger than 2 gig which does not happen very often. As
                              long as you are aware of it, PowerBASIC is a fun 32 bit playpen,
                              why mess up something that works well.

                              Regards,

                              [email protected]

                              ------------------
                              hutch at movsd dot com
                              The MASM Forum

                              www.masm32.com

                              Comment


                              • #16
                                Borje --

                                > no updates are released between major
                                > releases of the compiler

                                Sorry, but that's not an accurate statement. Historically, PowerBASIC has released many different minor "maintenance" updates between major upgrades.

                                When an extra long time elapses between updates it's usually because the current version is relatively bug-free, which this one is. And in the past, long intervals have often been followed by updates that were "worth waiting for". Because of PowerBASIC's policy of not pre-announcing updates or upgrades, all any of us can do is be patient. It's my guess that Santa Claus will arrive when the time is right. He usually does.

                                -- Eric


                                ------------------
                                Perfect Sync: Perfect Sync Development Tools
                                Email: mailto:[email protected][email protected]</A>
                                "Not my circus, not my monkeys."

                                Comment


                                • #17
                                  Sorry, but that's not an accurate statement. Historically, PowerBASIC has released many different minor "maintenance" updates between major upgrades.
                                  I think it would be more accurate to say PowerBASIC has "made available" maintenance releases.

                                  I, for one, have NEVER received a "product announcement" that says there is a maintenance release available, although if I have reported problems and there is a maintenance release available, I have alway been supplied ir on a timely basis. Closest thing to a announcement we have is now, with the (archaic) "date of current compiler files" page on this web site.

                                  MCM


                                  Michael Mattias
                                  Tal Systems Inc. (retired)
                                  Racine WI USA
                                  [email protected]
                                  http://www.talsystems.com

                                  Comment


                                  • #18
                                    Please don't mis-understand me. I love working with the PB/DLL
                                    compiler and it is indeed very bugfree, probably the most bugfree
                                    of all compilers I have ever used. Still think some minor update
                                    of the package now and then wouldn't hurt, especially when it
                                    comes to the editor..

                                    (and as I said - it's one good way to boost sales, believe me..)


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

                                    Comment

                                    Working...
                                    X