Classic ABL: How to prevent changing the current record of a browse widget - Forum - OpenEdge Development - Progress Community

Classic ABL: How to prevent changing the current record of a browse widget

 Forum

Classic ABL: How to prevent changing the current record of a browse widget

This question is not answered

Hi,

I need to prevent the user from changing the current row (=record) of a classic ABL browse widget.

The browse must remain enabled as most of the time the user is allowed to  

I coded the test in the value-changed trigger and return no-apply if a certain condition is met, (IRL the test detects pending unsaved changes).

return no-apply on value-changed of a browse widget does not work. the row and record are changed

Is this a bug or expected behaviour. If expected, what is the correct event to prevent changing the current row (record) of a browse widget ?

return no-apply on entry of the browse does not work either, the row is visually changed before the browse in entered

iteration-changed doesn't seem to do anything.

What event should I subscribe to to be able to cancel (return no-apply) changes to the current row+recordbrowse_noapply_valuechanged.w

I'll attach my sample browser on the sports2000

All Replies
  • Attempt to re-add missing screenshot

  • I think it's on VALUE-CHANGED of the browse, something like that, but you can set the READ-ONLY attribute conditionally. That way the browse stays enabled, but you can't change, and therefore submit changed values. I don't have an example to hand, but I've worked with various systems that do just that.

  • Hi James

    thanks for your reply, unfortunately value-changed is too late,

    I hope that this time my screenshot is visible.

    the customer and the browser already show the newly-navigated-to record. browse was on customer 7 before.

    With on entry of browse the behaviour is slightly better, the customer buffer still contains customer 7 but visually the browse is also on the new row.

  • You're right. I think it's ROW-ENTRY, you set the READ-ONLY at that point and the user can't change values. It's been a while!

  • Did a quick Google - this might help: knowledgebase.progress.com/.../P160055

  • In cases like this I prefer to disable the browse and re-enable it once the changes have been either saved or cancelled.