MainWndProc..

[Borje Hagsten]

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..)


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

[Michael Mattias]

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

[Eric Pearson]

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>

[Steve Hutchesson]

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]

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

[Borje Hagsten]

> 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..


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

[Semen Matusovski]

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]

[Borje Hagsten]

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).]

[Eric Pearson]

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).]

[Borje Hagsten]

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.


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

[Eric Pearson]

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).]

[Bern Ertl]

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

[Borje Hagsten]

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.


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

[jcfuller]

Or :

  #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

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

[Semen Matusovski]

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

  #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).]

[Kev Peel]

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

[Borje Hagsten]

Confusing, to say the least. In your sample, try following:

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.


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

[Semen Matusovski]

Borje --
Not agree with you. For OS it's not important DWORD / LONG.

  #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]

[Borje Hagsten]

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?

FUNCTION MainWndProc(BYVAL hWnd   AS LONG, BYVAL wMsg   AS LONG,_
                     BYVAL wParam AS LONG, BYVAL lParam AS LONG) AS LONG

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