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. Friday, 24 April 2020 10:41 AM UTC
  2. PowerBuilder
  3. # 1

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.
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. Monday, 4 May 2020 12:27 PM UTC
  2. PowerBuilder
  3. # 3

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.
  • Page :
  • 1


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