• You are here:  
  • Home
  • Q&A
  • Q&A
  • PowerBuilder
  • Window width and height don't match between painter and script

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

Resolved Window width and height don't match between painter and script

  1. Issue
0
Votes
Undo
  1. Dan Cooperstock
    Dan Cooperstock
  2. PowerBuilder
  3. Wednesday, 28 August 2024 19:00 PM UTC

I'm observing a problem where if I create a window with a given width and height (in this case, 2002 x 1500), and then put a messagebox in the window's Open event to display those values, they don't match (I get 2039 x 1604).

Is it adding in PBUs for the borders and title bar perhaps, when it reports on those values in a script? The Help doesn't suggest that, that I can observe.

This is complicating some code I'm trying to write to make sure that the window has enough space for all of the controls in it.

I'm observing this both in PB 2022 R3 (which I'm currently testing my apps in, to see whether I'm ready to convert) and PB 2021.

  1. PowerBuilder (Appeon)
  2. Window
Deleting objects when using IDE GIT
Issue creating a user object that contains a sub u...
Responses (3)
Roland Smith
Roland Smith Accepted Answer Pending Moderation
  1. Wednesday, 28 August 2024 19:50 PM UTC
  2. PowerBuilder
  3. # 1

I'm pretty sure it is taking window border and title bar size into account.

The GetSystemMetrics function can get the sizes in pixels.

https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getsystemmetrics

 

Comment
Dan Cooperstock
  1. Dan Cooperstock
  2. Wednesday, 28 August 2024 20:18 PM UTC
That's weird though that you can set one value for width or height in the painter but then if you check it in a script, it's a different (larger) value! At the very least that should be documented in the Help.
  1. Helpful
David Peace (Powersoft)
  1. David Peace (Powersoft)
  2. Friday, 30 August 2024 07:51 AM UTC
I know Dans' application quite well and it's definitely not using PFC ;-)
  1. Helpful
Chris Pollach @Appeon
  1. Chris Pollach @Appeon
  2. Friday, 30 August 2024 12:37 PM UTC
Hi David;

I was just covering the resize bases as if he was using the PFC, then he must be using the latest version to also account for this sizing change.

Regards ... Chris
  1. Helpful
There are no comments made yet.
Chris Pollach @Appeon
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Wednesday, 28 August 2024 20:28 PM UTC
  2. PowerBuilder
  3. # 2

Hi Dan;

  FYI ... https://docs.appeon.com/pb/upgrading_pb_apps/Window_size_differences.html

Regards ... Chris 

Comment
Dan Cooperstock
  1. Dan Cooperstock
  2. Wednesday, 28 August 2024 20:59 PM UTC
So the actual client area height is 140 PBUs less than window.height?

How does that match my observation in PB2022 that if I declared a window height of 1500, window.height in a script was 1604 (just 104 PBUs more)? Is that the same or a different issue?
  1. Helpful
Chris Pollach @Appeon
  1. Chris Pollach @Appeon
  2. Wednesday, 28 August 2024 21:28 PM UTC
1) I would not trust the numbers in the Window's "open" event. Instead, I would create a "PostOpen" user event posting that from the real Open event. There could still be other resize forces at work in the Open event.

2) The height change only affects the Window Title. So the impact would only be if your computations included that area.

3) Looks like your using the PFC. I believe that there were changes to the PFC 2022 version to address various PB changes in 2022 due to switching to use VC++2022 compiler for the IDE + runtime.
  1. Helpful 2
Dan Cooperstock
  1. Dan Cooperstock
  2. Thursday, 29 August 2024 02:05 AM UTC
I'm not using the PFC - curious what made you think that!
  1. Helpful
There are no comments made yet.
David Peace (Powersoft)
David Peace (Powersoft) Accepted Answer Pending Moderation
  1. Thursday, 29 August 2024 13:38 PM UTC
  2. PowerBuilder
  3. # 3

Hi Dan

It's a feature of PB2022, and I have had assurances from Appeon dev that these numbers will not change in future. However as Chris has said, the issue can be avoided by doing your calculations in the PostOpen Event. Or you have to apply a a fixed offset to your calculations in the Open event. We had a very similar problem with a large system migration that had code in the open event of windows setting the height & width. We had to add a fix number to each to fix the issue. It was easier to add the fixed offset to the existing calculation rather than refactor the code to be in a postopen event.

Fingers crossed, it all works now :)

 

Hope that helps

Cheers

David

 

Comment
Load more comments
Ronnie Po
  1. Ronnie Po
  2. Friday, 30 August 2024 16:07 PM UTC
One wrinkle with postopen is that things are visible by then and your window may blink or jump around. To avoid the blinking I've had to set windows as invisible at design time and then manually show() them in the postopen event. Another workaround...
  1. Helpful
Chris Pollach @Appeon
  1. Chris Pollach @Appeon
  2. Friday, 30 August 2024 16:16 PM UTC
Good point Ronnie!

That's exactly what I do in my STD Framework. ;-)
  1. Helpful
David Peace (Powersoft)
  1. David Peace (Powersoft)
  2. Friday, 30 August 2024 16:17 PM UTC
Yep, do that too....
  1. Helpful
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.