Subscribe via RSS
Toggle Submenu
  1. Categories
  2. Recent
  3. Tags
View Replies (4)

Resolved longptr param in dw other() event

  1. Issue
0
Votes
Undo
  1. Miguel Leeuwe
    Miguel Leeuwe
  2. PowerBuilder
  3. Friday, 24 April 2020 10:32 AM UTC

Hi,

I have this code in a dw's other() event. I've stripped out most of the code, just to illustrate.

// v1 and v2, mjl, 13/04/20: Since win8 and w10 totally ignore the mouse settings when working remotely, I've re-introduced the code to scroll:

CONSTANT Long WM_MOUSEWHEEL = 522
CONSTANT Longptr WM_OUTLOOK_DROP = 111

CHOOSE CASE wparam
		
	CASE WM_MOUSEWHEEL
		RETURN  1 

	CASE WM_OUTLOOK_DROP // email dropped from Outlook?
		RETURN 0
		
END CHOOSE

RETURN 0

There's no problem at all when scrolling with the mousewheel

Now, since the wparam really is a longptr, I decided to define my WM_MOUSEWHEEL also as such.

Result is first I don't see anything on the dw untill I scroll a bit and then I can scroll down, but cannot scroll up.

I've reported this as a private bug, since my video which accompanies it holds private data, but the only answer I've gotten (which I do appreciate), is that on 32bit, longptr's are interpreted as long at runtime. So far, It's not being considered as a possible bug. Fine, the explanation is good, but it doesn't make sense, since I'm comparing a longptr with a longptr in the choose case (after having changed the WM_MOUSEWHEEL constant to longptr).

In our full application based on pfc classes, everything just freezes / hangs.

Has anyone else have the idea that this is a bug or should I just have some more rum on my birthday?

Please watch this video which shows how to reproduce my case:

https://credica-my.sharepoint.com/:v:/g/personal/miguel_credica_co_uk/EVNNppx5VItDk2k3rJqj8X4Bf1a92EZjK6meexudOvLqrQ?e=HMB4Aw

I'll now also publish this as a public possible bug.

 

Resolve invalid (in time) child datawindow in a da...
Themes and fonts
Accepted Answer
Miguel Leeuwe
Miguel Leeuwe Accepted Answer Pending Moderation
  1. Thursday, 30 April 2020 10:50 AM UTC
  2. PowerBuilder
  3. # Permalink

 

Okay, I've come to the bottom of this I think.
It all seemed to be working, because the WM_MOUSEWHEEL should be compared with the "uint message.number", NOT with "wparam". I THOUGHT it worked, but in reality the code for scrolling was never run when using a long.
Please see:
https://community.appeon.com/index.php/qna/q-a/datawindow-mouse-wheel-scrolling-in-rdp-sessions-scrolls-whole-pages-instead-of-3-lines#reply-20261

for the corrected code.

Sorry for all the confusion.

regards.

Comment
There are no comments made yet.
Responses (4)
Miguel Leeuwe
Miguel Leeuwe Accepted Answer Pending Moderation
  1. Monday, 4 May 2020 12:27 PM UTC
  2. PowerBuilder
  3. # 1

After reading that Appeon has fixed this bug, when remotely connected, I found out that it still scrolls 6 lines instead 3 lines.
So I reactivated my old scrollingcode in the "other" event, with you suggested "message.processed = true" and "return 0" and now it scrolls 9 lines !
After changing the return value to 1, (no longptrs), everything works as it should.
I know the help file doesn't mention the return 1 value.

I've reported it as another bug.


regards

Comment
There are no comments made yet.
John Fauss
John Fauss Accepted Answer Pending Moderation
  1. Friday, 24 April 2020 13:51 PM UTC
  2. PowerBuilder
  3. # 2

Hi, Miguel - 

What are you wanting to accomplish by issuing Return 1 from the pbm_other event? Have you tried setting Message.Processed = True/False instead? Setting this property to True is the prescribed technique for letting the default window message processing loop (DefWindowProc) know that your code has processed the message.

Also, a minor point of clarification: A Longptr datatype gets translated to a Long (in 32-bit) or LongLong (in 64-bit) at compile time, not at execution/run time.

Happy Birthday!

Comment
Miguel Leeuwe
  1. Miguel Leeuwe
  2. Friday, 24 April 2020 14:09 PM UTC
Hi John, thank you!

I thought that setting Message.Processed was the "old" way of doing what you do when you do return 1, but I just checked the help file and you're right. Only "return 0" is mentioned. I must have gotten that from "somewhere" or I'm confused with the "key" event, so I'll change the code.

Thanks for the clarification, but I still don't understand why the behaviour of "return 1" is affected by the type of my WM_MOUSE_WHEEL constant.

regards





  1. Helpful
Miguel Leeuwe
  1. Miguel Leeuwe
  2. Monday, 4 May 2020 12:27 PM UTC
Hi John, after reading that Appeon has fixed this bug, when remotely connected, I found out that it still scrolls 6 lines instead 3 lines.

So I reactivated my old scrollingcode in the "other" event, with you suggested "message.processed = true" and "return 0" and now it scrolls 9 lines !

After changing the return value to 1, (no longptrs), everything works as it should.

I know the help file doesn't mention the return 1 value.

regards

  1. Helpful
There are no comments made yet.
Miguel Leeuwe
Miguel Leeuwe Accepted Answer Pending Moderation
  1. Friday, 24 April 2020 10:41 AM UTC
  2. PowerBuilder
  3. # 3

Here's the same video, but with better quality.

https://drive.google.com/open?id=1YzJLa-vihaJDdaokIcDduEhKXG0CInvI

for some reason OneDrive blurs everything (maybe because I'm connecting remotely)

The only upwards scrolling that sort of seems to work when I define the constant as longptr, is because I'm using the keyboard arrow keys.

Comment
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.