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

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?

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.

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.

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.