• You are here:  
  • Home
  • Q&A
  • Q&A
  • PowerBuilder
  • Popup Window Move function works differently in PB2017 and PB2019R3

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

Resolved Popup Window Move function works differently in PB2017 and PB2019R3

  1. How-to
0
Votes
Undo
  1. Daryl Foster
    Daryl Foster
  2. PowerBuilder
  3. Tuesday, 15 February 2022 07:20 AM UTC

Hi, I just noticed an issue with the windows restore function I've been using without any problems for the past 10 years in PB10.5 and PB2017.  It seems that the Move function for a popup works differently in PB2019R3 when using multiple monitors.  In PB10.5 or PB2017 I could use w_popup.Move(0,0) and it would always move it relative to the virtual screen position.  Now with PB2019R3 it seems to move it relative to the screen the opening window is on.  e.g if the Parent window is on the first screen the popup will open at 0,0 (i.e the top left of the first/primary monitor).  But if the parent window is on the second screen it will open at 8777,0 (i.e the top left of the second monitor). I've seen a few bugs with similar sounding issues, but they all seem to be resolved.

I just wanted to check whether anyone else has encountered this issue, or whether it is a deliberate change?  I've only noticed it on one particular screen in my application at the moment, but I wanted to check if it is a know issue before investigating further.  I'm using Version 19.2.0.2728

Thanks.

  1. PowerBuilder
Zxing.Net
In web browser control, PB 2019 R3 while printing ...
Responses (2)
Miguel Leeuwe
Miguel Leeuwe Accepted Answer Pending Moderation
  1. Tuesday, 15 February 2022 14:33 PM UTC
  2. PowerBuilder
  3. # 1

I think this might have something to do with recent fixes to avoid a window first opening on a second monitor and then being moved to the first.

Maybe it's a good idea to open a support ticket.

regards

Comment
Daryl Foster
  1. Daryl Foster
  2. Wednesday, 16 February 2022 00:05 AM UTC
Thanks Miguel, yes, that is the bug I saw that looked a bit similar. I'll open a new support ticket because I can reliably reproduce my issue just with plain Powerbuilder code.
  1. Helpful
There are no comments made yet.
Chris Pollach @Appeon
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Tuesday, 15 February 2022 18:38 PM UTC
  2. PowerBuilder
  3. # 2

Hi Daryl;

   FWIW:  I have a Window restore feature in my STD Framework and it works 100% on 2 or 3 or more monitors and then proceeds to center Popup and Response windows accordingly from there (once the initial monitor is known). This logic has been working for about a decade now and it is also working still in all PB2019Rx and the new PB2021 compiled apps as well (including PowerClient and PowerServer based ones).

  I am not sure what / why your code is not working without getting getting deep into your approach.

Note however, that from PB release to PB release, some event "firing" orders can change. Maybe that's the issue (just a thought).

Regards ... Chris

Comment
Daryl Foster
  1. Daryl Foster
  2. Wednesday, 16 February 2022 00:21 AM UTC
Thanks Chris, I might have a look at your code, but I think there it is a bug with the later versions of Powerbuilder. I can reliably reproduce it with simple Powerbuilder code.



If I add this code in the Open event of a popup (or response) window

this.Move(100, 100)

or even if I set the X and Y properties of the popup window at design time to 100, when the popup window opens it will be positioned at 100, 100 relative to the screen the parent window is on, rather than the absolute 100,100 of the virtual screen. I can set it after it has been opened, but it doesn't work if the code is in the Open event or set at design time.



e.g. On my pc, with two 1920 x 1080 monitors, if the parent window is on the first monitor the popup will open at 101,100, but if the parent window is on the second monitor the popup will open at 8878,100
  1. Helpful
Chris Pollach @Appeon
  1. Chris Pollach @Appeon
  2. Wednesday, 16 February 2022 03:02 AM UTC
That could be why my framework monitor restore & window centering within the App works as the framework does *not* use the Window "Open" or a Control's "Constructor" event for coding. All the above work is done in posted user events - "oe_open" and "oe_constructor" respectively This is a very important architecture design because - as I said before - there can be event firing order changes between PB releases. Whereas when the posted user event occurs, the related objects are FULLY instantiated and thus can be then safely manipulated. ;-)
  1. Helpful
Daryl Foster
  1. Daryl Foster
  2. Wednesday, 16 February 2022 10:31 AM UTC
Thanks Chris, our framework has the restore position code in the pre_open event and it's worked fine for years. I have encountered issues in the past with changes in event firing between versions and it's pretty annoying. I'm not sure if that is the issue here though because the same thing happens when the properties are set at design time, so I don't have to do anything in the open event and it still doesn't work like it did previously. That's why I think it's a bug.
  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.