Hi Jeff;

   When you migrated to PB2019 Rx, did you also update your PFC to the 2019 version as well?

Regards ... Chris

Greetings, Jeff -

If the resizing logic in your windows is based on the same in the PFC, your ancestor window may likely have a function named of_SetResize (or similar) that instantiates the Resize service non-visual object (NVO), then calls the of_SetOrigSize function in the NVO to inform it of the window's "original" size.

In version 8, this "set original size" logic changed, then in 12.5 the logic was changed back. Since I do not know what version of the PFC your long-departed developer used, I cannot tell if that could be the root source of your resizing issue. I'm including below the code from the of_SetResize function in base ancestor window object, pfc_w_master, so you can compare the code your app is using against the current logic in the PFC:

//////////////////////////////////////////////////////////////////////////////
// Public Function:  of_SetResize
// Arguments:   ab_switch   starts/stops the window resize service
// Returns:     Integer     1 = success,  0 = no action necessary, -1 error
// Description:	Starts or stops the window resize service
//////////////////////////////////////////////////////////////////////////////
// Rev. History: Version
//                 5.0   Initial version
//                 8.0   Modified to initially set window dimensions based on the class definition
//                12.5   11001  Reverting original size logic back to pre 8.0 logic
//////////////////////////////////////////////////////////////////////////////
// Copyright © 1996-2001 Sybase, Inc. and its subsidiaries.  All rights reserved.  Any distribution of the 
// PowerBuilder Foundation Classes (PFC) source code by other than Sybase, Inc. and its subsidiaries is prohibited.
//////////////////////////////////////////////////////////////////////////////
integer	li_rc, li_v, li_vars
int     eger li_origwidth, li_origheight

// Check arguments
if IsNull (ab_switch) then
   return -1
end if

if ab_Switch then
   if IsNull(inv_resize) Or not IsValid (inv_resize) then
      inv_resize = create n_cst_resize
   	
//    /*  Get this window's class definition and extract the width and height  */
//    classdefinition lcd_class
//    lcd_class = this.ClassDefinition
//    
//    li_vars = UpperBound ( lcd_class.VariableList )
//    For li_v = 1 to li_vars
//       If lcd_class.VariableList[li_v].Name = "width" Then li_origwidth = Integer ( lcd_class.VariableList[li_v].InitialValue ) 
//       If lcd_class.VariableList[li_v].Name = "height" Then li_origheight = Integer ( lcd_class.VariableList[li_v].InitialValue ) 
//       If li_origwidth > 0 And li_origheight > 0 Then Exit
//    Next
//    inv_resize.of_SetOrigSize ( li_origwidth, li_origheight )
      
      inv_resize.of_setOrigSize(this.WorkSpaceWidth(), this.WorkSpaceHeight())
      li_rc = 1
   end if
else
   if IsValid (inv_resize) then
      destroy inv_resize
      li_rc = 1
   end if
end If

return li_rc

Something else to keep in mind is that the PFC was developed for PB 5 - many, many moons before Themes were implemented. It therefore stands to reason that if the use of Themes results in "funky" or unusual behavior in object sizing, then code based on an old version of the PFC may not be able to adapt. So far as I know, no Theme-related changes to the PFC have been made to date.

You will likely have to do some investigation and/or trouble-shooting with Themes enabled to determine what window behavior and/or values are different in an executable when Themes are in use, then make the appropriate adjustments in the "set original size" logic to compensate for those differences. Themes are pretty cool and provide nice-looking results for very little coding effort, but I'm not a fan of how they were implemented (my $0.02)

I hope this helps you figure out a solution to your issue.

Regards, John

Hi Jeff，

Firstly, I suggest you try to configure "Change the size of text, apps, and other items" to 100% in the Windows Settings and then see if the issue exists.

Secondly, it is suggested you upgrade PFC to PB 2019：https://github.com/OpenSourcePFCLibraries/2019

Regards,

Ken

HI Jeff;

   There is also a change to the "WorkSpace" properties even in PB2019 R2. For example on the NewWidth & NewHeight as well as the WorkSpaceWidth() and WorkSpaceHeigth() methods when a Theme is active. You can see an example of this in my STD Framework before and after a theme activation, where the framework is controlling a UserObject on the menu's toolbar. The UO is flushed to the right hand side if no theme is active but does not flush right when a Theme is active, as follows:

   This change in "usable space" calculation when a Theme is active issue which is also present in PB2019 R3 and PB2021. I  will create a Support Ticket for this issue later today.

   Note: I am guessing that the above space values may also throwing off the PFC resize calculations as well. More study needs to be done though to confirm this as this is just my guess at the moment.

Regards ... Chris

Hi Jeff,

In the of_setResize() script that John pasted, there is a section that is commented out. Is that same block of code commented out in your version of of_setResize()? If so, try uncommenting it and see if that helps.

That code tells the resize service to use the width and height values of the child window from the class definition (the "painter" values) and should compensate for the anomaly that you observed regarding the width and height of the child window in the open() event.

(FWIW, that section is most likely commented out because Appeon Web / PowerServer Web doesn't support ClassDefinition. Since you are using themes, I'm guessing that you aren't using PowerServer Web.)

I just noticed the subject I entered or this thread is misleading. If admins/moderators have the ability to make it more suitable please do so.