PureBasic Forums - English

Posted: **Fri Mar 29, 2013 12:32 am**

I have a small ap that worked fine under PB 5.0 but doesn't work compiled under 5.11. The culprit appears to be "#WM_LBUTTONUP" which is no longer detected. "#WM_RBUTTONUP" isn't either.

Did I miss a change?

Thanks,
Bill

Code: Select all

; No button up detection

If OpenWindow(0,0,0,200,200,"",#PB_Window_SystemMenu|#PB_Window_ScreenCentered)
  Repeat
    
    eventid=WaitWindowEvent()
    Select eventid
        
      Case #PB_Event_CloseWindow
        quit=1
        
      Case #WM_LBUTTONDOWN
        Debug "Left button Down"
        
      Case #WM_LBUTTONUP
        Debug "Left button up"
        
      Case #WM_RBUTTONDOWN
        Debug "Right button down"
        
      Case #WM_RBUTTONUP  
        Debug "Right button up"
        
    EndSelect
    
  Until quit
EndIf

Posted: **Fri Mar 29, 2013 12:43 am**

http://www.purebasic.fr/english/viewtop ... 13&t=53112

(Wait)WindowEvent() was never documented suggesting it can be used to retrieve Windows messages.
It works but can stop to do so for some messages at any moment as you just discovered.
Better to use a callback (that's the "clean" way) or just switch to the new native PB message in your case if you prefer to do so.

Posted: **Fri Mar 29, 2013 1:37 am**

Thanks for the quick reply, Luis. Much appreciated.

Bill

Posted: **Fri Mar 29, 2013 12:02 pm**

I have replaced #WM_LBUTTONUP with #PB_Event_LeftClick, which does the same.
Only in some cases i use both: #PB_Event_LeftClick, #WM_LBUTTONUP where i have to receive events from various gadgets which doesn't accept #PB_Event_LeftClick.

Posted: **Sat Mar 30, 2013 3:54 am**

If I understand Luis' answer, and the link he provided, any use of the #WM messages from (Wait)WindowEvent() is asking for trouble. The frustrating part of this is that these messages have been used for years and examples abound throughout these forums. Documented or not, they worked and became part of the code base we learn PB from. Now, some work, some don't.

Bill

Posted: **Sat Mar 30, 2013 5:01 am**

offsides wrote:Documented or not, they worked and became part of the code base we learn PB from. Now, some work, some don't.

The #WM messages were NEVER part of the official documentation, and both Fred and Freak have warned us in these forums, over and over, NOT to rely on them in future. For those of us who took the risk, that's their choice. (Including myself, mind you).

Posted: **Sat Mar 30, 2013 3:03 pm**

The #WM messages were NEVER part of the official documentation, and both Fred and Freak have warned us in these forums, over and over, NOT to rely on them in future. For those of us who took the risk, that's their choice. (Including myself, mind you).

Well, I think the note on the first page of the documentation "The Win32 API is fully supported as if they were BASIC keywords" does suggest #WM messages are supported - that might not be the intention of course.

Bill (offsides) is correct in his observation of their use - there are many code examples on the forum, some posted by PB power Users, using the #WM messages.

I haven't seen a warning about their use by Fred/Freak - perhaps that should be in the documentation.

Edit: Strange thing, can't get #WM_LBUTTONUP to work in your example but I just found it used in one of my apps, similar loop, works fine

I'm going to move that code into a CallBack though.

Posted: **Sat Mar 30, 2013 3:06 pm**

API commands are different to Windows messages. (Disclaimer: I;m drunk right now)./

Posted: **Sat Mar 30, 2013 3:39 pm**

API commands are different to Windows messages. (Disclaimer: I;m drunk right now)./

A newbie is not necessarily going to 'get' that, they will see "The Win32 API is fully supported" - from there, it's reasonable to assume that Windows messages are supported, and indeed they are - but not necessarily with WaitWindowEvent().

Posted: **Sat Mar 30, 2013 6:06 pm**

offsides wrote:Documented or not, they worked and became part of the code base we learn PB from. Now, some work, some don't.

For some the advantage compared to the callback (apart less code) it's you can process both #PB_Events and #WM_* messages easily in the same loop.
Keep in mind that now, with the new PostEvent() command, you can use the "clean" callback method and still process the messages in the PB event loop, if you choose to do so.

At least that's my take, I haven't experimented with PostEvent() until now

Example:

Code: Select all

Enumeration 
 #My_Event_LeftClick_Down = #PB_Event_FirstCustomValue
 #My_Event_RightClick_Down 
EndEnumeration

Procedure wc (hWnd, uMsg, wParam, lParam)   
 Select uMsg
    Case #WM_LBUTTONDOWN
        PostEvent(#My_Event_LeftClick_Down)
    Case #WM_RBUTTONDOWN
        PostEvent(#My_Event_RightClick_Down)
 EndSelect     

 ProcedureReturn #PB_ProcessPureBasicEvents
EndProcedure


If OpenWindow(0,0,0,200,200,"",#PB_Window_SystemMenu|#PB_Window_ScreenCentered)
 
 SetWindowCallback(@wc())
 
 Repeat
   
    eventid = WaitWindowEvent()
    
    Select eventid
       
      Case #PB_Event_CloseWindow
        quit=1
       
      Case #My_Event_LeftClick_Down
        Debug "Left button Down"
       
      Case #PB_Event_LeftClick
        Debug "Left button up"
       
      Case #My_Event_RightClick_Down
        Debug "Right button down"
       
      Case #PB_Event_RightClick
        Debug "Right button up"
       
    EndSelect
   
 Until quit
EndIf

Obviously in this case you get only the message/event type and not the associated lParam / wParam, but if needed they can always be squeezed in the Data param of PostEvent(). This is ok if you just want to use them in readonly mode. If you have to block the message or do other tricky things the right place it's still the callback.

So you have many choices:

use the undocumented #WM_ returned by (Wait)WindowEvent() and possibly the undocumented EventlParam() / EventWParam()

use the SetWindowCallback() and process only the #WM_ messages there (the #PB_Events still in the PB loop)

use the SetWindowCallback() and forward the #WM_ messages you want to process as PB events through PostEvent() (like in the above example) when it's easier / more comfortable to do so.

Hope this helps.

Posted: **Sat Mar 30, 2013 7:07 pm**

Hope this helps.

Luis, indeed it does. Thanks.

I suppose what we're seeing here is, as PB evolves and more functions are added, the new functions can interfere with existing functionality. When the existing functionality is "undocumented", well, sorry...

Maybe this explains why PB now explicitly prohibits all in-line boolean operations. In many basics of yore (TRSDOS, GWBasic, QBX(BC7), etc., such as (ie. test = (a<b<c)) was built in. PB has Bool(), but it won't work on my example.

Anyway, thanks again, Luis and all who helped on this.

Bill

Posted: **Sun Mar 31, 2013 4:29 am**

Here is my two cents worth, code added for middle button.

Code: Select all

Enumeration 
 #My_Event_LeftClick_Down = #PB_Event_FirstCustomValue
 #My_Event_RightClick_Down
 #My_Event_MiddleClick_Down
 #My_Event_MiddleClick_Up
EndEnumeration

Procedure wc (hWnd, uMsg, wParam, lParam)   
 Select uMsg
    Case #WM_LBUTTONDOWN
        PostEvent(#My_Event_LeftClick_Down)
    Case #WM_RBUTTONDOWN
        PostEvent(#My_Event_RightClick_Down)
    Case #WM_MBUTTONDOWN
        PostEvent(#My_Event_MiddleClick_Down)
    Case #WM_MBUTTONUP
        PostEvent(#My_Event_MiddleClick_Up)
 EndSelect     

 ProcedureReturn #PB_ProcessPureBasicEvents
EndProcedure


If OpenWindow(0,0,0,200,200,"",#PB_Window_SystemMenu|#PB_Window_ScreenCentered)
 
 SetWindowCallback(@wc())
 
 Repeat
   
    eventid = WaitWindowEvent()
    
    Select eventid
       
      Case #PB_Event_CloseWindow
        quit=1
       
      Case #My_Event_LeftClick_Down
        Debug "Left button Down"
       
      Case #PB_Event_LeftClick
        Debug "Left button up"
       
      Case #My_Event_RightClick_Down
        Debug "Right button down"
       
      Case #PB_Event_RightClick
        Debug "Right button up"
       
      Case #My_Event_MiddleClick_Down
        Debug "Middle button down"
       
      Case #My_Event_MiddleClick_Up
        Debug "Middle button up"
       
    EndSelect
   
 Until quit
EndIf

Posted: **Mon Apr 01, 2013 3:49 pm**

Wouldn't feel good with this quick & dirty solution, but seems to be a workaround for 5.11 (and maybe PB 5.21 bring back the lost window events)

Code: Select all

; (No) button up detection

If OpenWindow(0,0,0,200,200,"",#PB_Window_SystemMenu|#PB_Window_ScreenCentered)
	Repeat

		eventid=WaitWindowEvent()
		Select eventid

		Case #PB_Event_CloseWindow
			quit=1

		Case #WM_LBUTTONDOWN
			Debug "Left button Down"
			
		Case #WM_LBUTTONUP,#PB_Event_LeftClick
			Debug "Left button up"

		Case #WM_RBUTTONDOWN
			Debug "Right button down"

		Case #WM_RBUTTONUP,#PB_Event_RightClick
			Debug "Right button up"

		EndSelect

	Until quit
EndIf

PureBasic Forums - English

Mouse "UP" no longer works in 5.11

Mouse "UP" no longer works in 5.11

Re: Mouse "UP" no longer works in 5.11

Re: Mouse "UP" no longer works in 5.11

Re: Mouse "UP" no longer works in 5.11

Re: Mouse "UP" no longer works in 5.11

Re: Mouse "UP" no longer works in 5.11

Re: Mouse "UP" no longer works in 5.11

Re: Mouse "UP" no longer works in 5.11

Re: Mouse "UP" no longer works in 5.11

Re: Mouse "UP" no longer works in 5.11

Re: Mouse "UP" no longer works in 5.11

Re: Mouse "UP" no longer works in 5.11

Re: Mouse "UP" no longer works in 5.11