Bug in PB/DLL 60 :rolleyes:

[Fred Oxenby]

To use %WM_APP message range of application-messages
the exe has to be marked Version 4.
#Option Version4
#Option Version5
does not satisfy M$ and therefore this messages are ignored
in WIN/NT4 and WIN2000
It does however work when run under WIN/98SE
Is there a workaround ...?
Please


-------------
Fred
mailto:[email protected][email protected]</A>
http://www.oxenby.se

[Semen Matusovski]

MSDN talks that messages WM_APP through 0xBFFF are available for use by applications in all OSes, begining from NT 3.51.
Can you give small sample, which not works under NT ?


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

[Fred Oxenby]

All Message-values greater than than &H8000
Message-values less than &H8000 is ok

If your application is marked version 4.0, you can use message-identifier values in the range 0x8000 (WM_APP) through 0xBFFF for private messages.

I said that it worked under WIN98SE but that is true only if
the message is sent from the same thread as the messagepump



------------------
Fred
mailto:[email protected][email protected]</A>
http://www.oxenby.se

[Lance Edmonds]

This may be completely off the mark for what you want to achieve, but if you know the thread ID where you want the message to go, have you tried using PostThreadMessage() ?

I'm not sure how you manage to put this down to a bug in PB/DLL, Fred...

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

[Fred Oxenby]

Lance, I suppose you did not see in the subject.
But to answer your question:

Use #OPTION VERSION4 (default) to compile and make the output file require the target system be running Windows 95/98 or NT 4.

Use #OPTION VERSION5 to compile and make the output file require the target system be running Windows 2000 or NT 5.

This options does not work.
Application compiled using #Option Version5 will still run in WIN95/98, and the resulting exe is equal
byte by byte if using Option4 or Option5.
This subject have been tuched in other threads, but has not been
commented on from PB Support. (No direct question)
In a upcoming new release of my system I have obeyed the new
Micro$oft rules of private messages (%WM_APP) and that breakes my application.
The application does not work on WIN/NT4 and WIN2000.
And the reason is that messages in the range &H8000 - &HBFFFF is
filtered and never reaches the WndProc callback.
And this happens because PowerBasic compiler does not mark the EXE as a "Version 4" executable.
---
This is how I got it down to a bug in PBDLL
---
I am not really interested in bug/no-bug. My interest lies in the
fact that I want to be able to use %WM_APP messages and in some cases prevent
the application to be started on OS less than WIN2000
---
If someone knows how to patch the Exe to tell Windows that it is a "Version 4" executable,
and willing to share their knowledge, you will find a very greatful oxenby on the streets of London..

------------------
Fred
mailto:[email protected][email protected]</A>
http://www.oxenby.se



[This message has been edited by Fred Oxenby (edited June 09, 2000).]

[Semen Matusovski]

Fred --
1) I can't agree with your information about %WM_APP.
This code works fine on my PC, at least, under Win95b & Win2000.

   #Compile Exe
   #Dim All
   #Register None
   #Include "win32api.inc"

   %WM_APP = &H8000&
   CallBack Function DlgProc
      Select Case CbMsg
         Case %WM_APP: MsgBox "ok"
      End Select
   End Function
   Function PbMain
      Local hDlg As Long
      Dialog New %HWND_DESKTOP, "", , , 400, 200, %WS_CAPTION Or %WS_SYSMENU Or %WS_THICKFRAME To hDlg
      PostMessage hDlg, %WM_APP, 0, 0
      Dialog Show Modal hDlg Call DlgProc
   End Function

Probably, you declared %WM_APP = &H8000 instead of %WM_APP = &H8000&.

2) For me a fact, that Option Version doesn't work is positive.
If necessary, I am able to add some statements and analyze results of GetVersionEx by myself.


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

[Fred Oxenby]

If you don't use an identifier with these constants, the compiler will select the smallest integer type that will contain the number. When there is no type identifier, PowerBASIC stores the value as unsigned unless the most significant bit is a sign bit and the leading digit is not a zero. For example, &H8000 is signed, because its most significant bit is a sign bit (1000 0000 0000 0000) and its leading digit is non-zero. On the other hand, &H08000 is unsigned; although its most significant bit is a sign-bit (1000 0000 0000 0000), its leading digit is a zero.

Sure, Semen you are a solid rock...
Just read the book, is a good advice in all situations.
-------
I was fooled by the fact that #Option Version4,#Option Version5
produced exactly the same code, and MSDN description of WM_APP requiring the executeble to be marked Version 4.
This and the fact that redefining %WM_APP to &H7FF0 worked.
------
But still #Option5 is not doing what it claims to be doing.
And I am targeting WIN2000 with my new release so it would be
nice if it worked, and fixed in next release.
------
My apologies to you Lance and PB for me constant joking about the
three no-no's

------------------
Fred
mailto:[email protected][email protected]</A>
http://www.oxenby.se



[This message has been edited by Fred Oxenby (edited June 09, 2000).]

[Lance Edmonds]

Appology accepted!

I've already discussed the #OPTION VERSION5 behavior with R&D and it is going to be addressed so that apps marked with #OPTION VERSION5 will only be able to run on API level 5 platforms (ie, Windows 2000 or better).

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