I’m working on a legacy PowerBuilder app, we have upgraded to PowerBuilder 12 but continue to use the “classic” IDE.
I have a grid DataWindow sharing data with a freeform DataWindow, both inheriting ancestors that ensure that when the current row changes in the grid, the freeform scrolls to the same row.
I have started using expressions on the Protect and Background.Color properties of column controls in the freeform to simulate enabling/disabling, as an alternative to using DataWindow.Modify on rowfocuschanged.
So far I have enjoyed this approach, it seems much cleaner, and there is no apparent performance penalty since I am not accessing the database in any of my expressions.
The trouble is, for reasons that I am having a hard time pinning down, these expressions are sometimes causing the aforementioned row synchronization functionality to fail.
In my test scenario, there are two rows in the grid. Selecting row 2 does not cause the freeform to scroll to row 2, despite the fact that debugging reveals that ScrollToRow is indeed being called normally. Then I select row 1 again, can’t be sure if this works or not since the freeform never left row 1 to begin with. Then I select row 2 a second time, and the freeform scrolls to row 2 properly, and henceforth things are dandy.
I fixed this problem once already on a different window by moving code around within one particular expression, no clue why this worked, the changes did not affect the result of the expression. Unfortunately I am not having such an easy time fixing it on my current window. So far, I can solve the issue at a loss of functionality by removing the Protect expression from one particular DateTime EditMask column, or by setting the TabOrder of a preceding DateTime EditMask column to a positive value. The first column needs the Protect expression, and the second column needs to be uneditable. I attempted to give the second column a positive TabOrder while setting it’s Protect expression to 1 but that did not work.
I’m tearing my hair out and hating PowerBuilder something fierce! I’d appreciate it if anyone has any idea what the issue is and how I can continue taking advantage of column expressions while avoiding it. I am loath to going back to manipulating this stuff through Modify from rowfocuschanged.
Here’s the answer in retrospect, taking from and adding to what was developed in comments.
When you set a new row, PowerBuilder tries to set the column to the same column that currently has focus in the current row. This works fine in the basic case, but when the Protect attribute has an expression, things can be a little less predictable. I’m not sure if there is a documented or intended behaviour in the case when the column in the destination row is protected, but my position of safety is that the behaviour is unpredictable, and you probably just shouldn’t do this. As Mike has proved, explicitly setting the column resolves his issue.
The other primary thing to check for if you’re trying to solve a similar issue is to be sure RowFocusChanging isn’t returning a 1 to prevent the row change from occurring.
Good luck,
Terry.