1. Glenn Scamman
  2. PowerBuilder
  3. Tuesday, 4 June 2024 22:10 PM UTC

We have noticed that sometime recently, some of our grid datawindows are scrolling to the top automatically when we switch to a different sheet and then come back to it.  We are using PB 2022R3 build 3356, and we have a MDI application that utilizes the Tabbed View.  We may have a window with a grid datawindow and several thousand rows retrieved. The user may have scrolled down near the bottom, selected a row, and then decided to check information on a different sheet by clicking on the tab of another window on the tabbed view.  When they click back, the row in the grid dw hasn't changed, but the dw has scrolled to the top...causing them to have to scroll to locate the row again to bring it back into view.

I can't find a pattern to it yet, because some windows do this and some don't.  The rowfocuschanged event is not firing.  The scrollvertical event is not firing.  We are using PFC.  It is not all datawindows that use the PFC rowsselection service or the base service.  Some do, some don't. 

Has anyone else noticed this behavior? I would have to try another app to see if it is specific to the tabbedview approach.

Thanks,

Glenn

John Fauss Accepted Answer Pending Moderation
  1. Wednesday, 5 June 2024 00:42 AM UTC
  2. PowerBuilder
  3. # 1

Hi, Glenn -

I've not seen or heard of this behavior before. I suggest examining any/all code in the window's Activate event in any/all ancestor windows. By testing with the PFC's SQL Spy service enabled, you should be able to quickly rule out a DW retrieve as the cause, although RowFocusChanged would likely fire if that were the case.

Does this happen only in the compiled/deployed app and/or when running from the IDE?

Can you test with the TabbedView feature temporarily disabled?

I would also look for a DW ScrollToRow function call anywhere in the window (and ancestors), and in the DW's (and ancestor DW) code.

If the errant behavior can be replicated easily and quickly after starting the MDI application, you might also consider running, then analyzing a Profile Trace... not for performance reasons, but to get a better grasp as to what DW methods are being called and in what sequence. With a little effort, I believe you can add a feature to dynamically start/stop profile tracing activity in the application via code in the app - Maybe something to consider for cases like this.

Best regards, John

Comment
  1. Chris Pollach @Appeon
  2. Wednesday, 5 June 2024 17:20 PM UTC
Me either John.
  1. Helpful
There are no comments made yet.
Ronnie Po Accepted Answer Pending Moderation
  1. Wednesday, 5 June 2024 18:28 PM UTC
  2. PowerBuilder
  3. # 2

Hey Glenn,

Just a random thing to check out FWIW: pfc_u_dw has code in the getfocus() event that triggers pfc_controlgotfocus() in the parent window. Maybe something along the way is doing the scrolling?

Comment
  1. Glenn Scamman
  2. Wednesday, 5 June 2024 22:09 PM UTC
Ronnie,

I thought I'd already went down that path, but I'm not sure, so I'll check again tomorrow.

Thanks,

Glenn
  1. Helpful
  1. Glenn Scamman
  2. Friday, 7 June 2024 14:03 PM UTC
Ronnie, I did look at those events again. The ancestor PFC logic simply is handling the display of microhelp for the control getting focus. We have not coded anything in the descendants of these events. I see nothing that would cause dw rows to change or scrolling.
  1. Helpful
There are no comments made yet.
Glenn Scamman Accepted Answer Pending Moderation
  1. Wednesday, 5 June 2024 20:13 PM UTC
  2. PowerBuilder
  3. # 3

John,

  • Retrieves are definitely not happening to cause the scrollling
  • Yes, the problem happens whether run through an exe or through the IDE
  • Turning off TabbedView and switching to a menu-style navigation does eliminate the problem. I noted that when TabbedView is on, using Cntl+Tab also causes the issue (as well as mouse-clicking the tabs).
  • I did not find any ScrollToRow calls, except for those in some services not being utilized.
  • I ran several profile traces, but did not see anything out of the ordinary. There were many control-got-focus type events and resize events, but nothing ever indicated scrollling, except for the actual scrolling I did to setup the scenario.

 

Because of all of the resizing calls, I decided to turn off the PFC resize service on some of the windows having the issue. That did eliminate the problem. So, the problem seems to be a combination of resizing and the TabbedView interface. In particular, these windows have the main datawindow with a ScaleToRight&Bottom setting.  However, it still is not affecting all of the windows with this style, which is curious, so there is probably still another factor involved.  I'll scan the resize service to see if I notice anything that would be questionable.

Comment
  1. John Fauss
  2. Wednesday, 5 June 2024 21:15 PM UTC
Thanks for the info, Glenn. Do you happen to know what version of the PFC your application uses? Although there have NOT been many recent changes to the PFC, I know the Resize service was enhanced around the PB 12.5 version. To check if you have at least that level of code, open the pfc_n_cst_resize NVO in pfcwnsrv.pbl and look at the revision history comment in the of_resize function. There should be an entry listed for version 12.5.

Another question: Are the DW's being affected by this behavior in print preview mode (showing the thin blue margin line)? Do they all use the same style (grid, for example)?

Our PFC-based app still uses PB 2019 R3, so we obviously do not utilize the tabbed view feature. I do not know if there have been any recent changes to the PFC objects to support tabbed views. Perhaps Bruce Armstrong would be kind enough to enlighten us, if he sees this comment?
  1. Helpful
  1. Glenn Scamman
  2. Wednesday, 5 June 2024 22:08 PM UTC
John, the version info on the PFC object function pfc_n_cst_resize.of_resize() says it is version 8.0. I believe this is fairly recent, because we were hampered by the TabbedView resize issues, and chose to update the PFC version in efforts to fix, but ultimately Appeon had to push a maintenance release to get maximize/restore action to resize the non-active tabs in TabbedView apps. I have a hunch that that fix may have caused this new issue, but I can't confirm that. I could try to compile with previous compiler and runtime environment, but that would take some time.



The DW's are NOT in printpreview mode. These DW's are all grid DW's.



We have also discovered a new issue that is probably related to this one, but involves Freeform style dw's in a TabbedView app when resize service is on and the setting is ScaleToRight&Bottom, but only when the dw is not the top dw on the screen. But I'll start another issue discussion in case its not related.
  1. Helpful
There are no comments made yet.
Glenn Scamman Accepted Answer Pending Moderation
  1. Friday, 7 June 2024 18:59 PM UTC
  2. PowerBuilder
  3. # 4

After a lot more trial and error, to narrow down the cause of the problem, it is related to resizing specifically.  The TabbedView interface is simply kicking off resizing events when tabs are changed.  Unnecessary in my opinion, but not necessarily an issue.  And its not the PFC resize service either.  I turned off the resize service, and made the dw control resizeable.  As soon as I drag an edge of the dw control to resize, certain grid-style data window objects will immediately scroll to the top.  (Similar to this issue, on free-form dws with an edit field that is multiple lines high, data sitting in the edit control over the field will be discarded as soon as the dw control is resized).

What I have not figured out is what is it about specific dw objects that is causing this to happen. I've tried combinations of hidden columns, checkbox styles, dddw styles, tab orders, sort attribute on and off, etc.  Using the same window, one dw object will do it, another will not.  Frustrating.

Comment
There are no comments made yet.
Glenn Scamman Accepted Answer Pending Moderation
  1. Tuesday, 23 July 2024 21:26 PM UTC
  2. PowerBuilder
  3. # 5

An update to this issue:

I finally found which attribute is causing the issue.  When the detail band's auto-size height feature is ticked, a datawindow will experience this issue of undesired scrolling. I logged this as a bug with Appeon, and they were able to reproduce the problem.  Appeoon engineering will be working on a fix for this problem.

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.