Announcement

Collapse
No announcement yet.

MainWndProc..

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

  • Borje Hagsten
    replied
    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..)


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

    Leave a comment:


  • Michael Mattias
    replied
    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


    Leave a comment:


  • Eric Pearson
    replied
    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>

    Leave a comment:


  • Steve Hutchesson
    replied
    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]

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

    Leave a comment:


  • Borje Hagsten
    replied
    > 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..


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

    Leave a comment:


  • Semen Matusovski
    replied
    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]

    Leave a comment:


  • Borje Hagsten
    replied
    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).]

    Leave a comment:


  • Eric Pearson
    replied
    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).]

    Leave a comment:


  • Borje Hagsten
    replied
    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.


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

    Leave a comment:


  • Eric Pearson
    replied
    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).]

    Leave a comment:


  • Bern Ertl
    replied
    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

    Leave a comment:


  • Borje Hagsten
    replied
    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.


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

    Leave a comment:


  • jcfuller
    replied
    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

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

    Leave a comment:


  • Semen Matusovski
    replied
    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).]

    Leave a comment:


  • Kev Peel
    replied

    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

    Leave a comment:


  • Borje Hagsten
    replied
    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.


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

    Leave a comment:


  • Semen Matusovski
    replied
    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]

    Leave a comment:


  • Borje Hagsten
    started a topic MainWndProc..

    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

    ------------------
Working...
X