PowerBuilder expressions on column controls strange behavior

3
votes

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.

2
powerbuilderdatawindow
Checked the return from ScrollToRow()? I'd double check Describe ("datawindow.firstrowonpage") and lastrowonpage to make sure your control doesn't think the DW is already there. A PBDEBUG trace to make sure no other code is firing off (e.g. a RowFocusChanging with a preventing return code) might be an idea (debugger is intrusive, and can change event sequences). Just brainstorming, try SetColumn() to an unprotected column before the ScrollToRow(). (Is there a SetRow() in here anywhere?) Keep in mind 12.5 will give you Enabled attributes, so keep your methods modular and compatible. – Terry
Thanks for your prompt reply! In dw_grid.rowfocuschanged there is code to do dw_freeform.ScrollToRow(currentrow). I added code to capture the return value, and when the issue is occurring it returns 1, but currentrow is 2! I also noticed that my breakpoint in dw_freeform.rowfocuschanging is NOT being hit. I'm going to try your other suggestions. – Mike
So on dw_grid.retrieveend I did a dw_freeform.SetColumn on the only column I have that is always unprotected and it's working, thank you so much! I'm curious, what made you think of that, is there some relation between when the expressions are evaluated and whether a column is set? – Mike
@Terry you should add your suggestion as an answer so Mike can mark it as correct – Colin Pickard

2 Answers

2
votes

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.

1
votes

I've experienced a similar issue wherein not only the fields are being protected but also the background and text colors are changed when the row focus changes.

For some reason, the Datawindow expressions are quite inconsistent especially when there are other styles such as checkboxes. Removing all these expressions from the datawindow object and putting them all in one user event/function in the datawindow control that gets called from the rowfocuschanged() event of the grid list using Post() seems to do the trick. Also, doing this way will give you more control over when do events really fire as opposed to having code on the dw expressions.