bindingsource:RowModified

Posted by Roger Blanchard on 02-Feb-2009 15:18

It appears that if you change the value of any object used for data input such as ultraTextEditor, ultraNumericEditor, ultraCurrencyEditor that the value of bindingSource:RowModified is FALSE until you TAB out of the control. This causes an issue if I use an ultraToolbar and click a save button defined in the toolbar instead of an UltraButton. I assume this is due to the toolbar does not accept FOCUS so FOCUS is not lost on the object that was changed.

Does anyone know of a workaround?

Coming from ADM2 as soon as you start typing in a SDV the valueChanged event occurs.

All Replies

Posted by Roger Blanchard on 03-Feb-2009 06:48

Does anyone know of a way for the toolbar to take FOCUS when clicking on a tool within the toolbar?

Posted by Admin on 03-Feb-2009 14:07

It really depends on what you are trying to achive.

Saving the last modified field can be achieved by something like

oFocussedControl:DataBindings:WriteValue().

(given that you have bound the text property).

Posted by Roger Blanchard on 03-Feb-2009 14:11

Mike,

Basically if my user is updating a record and then they click the save button on a toolbar the value they entered in the last field is not updated unless they TAB out of the field.

Posted by Admin on 03-Feb-2009 14:15

I know that behaviour very, very well - finding out, which field is focussed (worst case, check the Focussed property of all fields) and then use the WriteValue metohd of the binding object as described in my last post solves that issue.

Posted by Roger Blanchard on 03-Feb-2009 14:18

Ouch!!

Thanks Mike.

Posted by Roger Blanchard on 03-Feb-2009 15:08

Mike,

The following seems to work as well.

THIS-OBJECT:ProcessTabKey(TRUE ).

Posted by Admin on 04-Feb-2009 11:51

Hi Roger, I've been thinking about this for a while now.

On the first sight, that looks promising and easy.

But on the second tought this does not "feel" right - it feels like "abusing" an UI event/UI-near method for the purpose of pure data-handling (fixing the symptom, not the cause).

Second the ProcessTabKey is only available on a Form, not on a UserControl - so from a UserControl, you first need to find the Parent (and recurse while the Parent is another Control, not a Form).

Additionally another (unrelated Control) receives Focus and thus the Enter event handler might get exeguted. In some conditions that might habe side-effects.

Finding the current Control (inside a UserControl or Form) and using the WriteData method of the Binding object(s) just feels better - can't give you any better response than that

Posted by Admin on 04-Feb-2009 11:55

Additionly, if the user presses save and the field do not get disabled, the Focus is no longer where the user did expect it.

Posted by Roger Blanchard on 04-Feb-2009 11:58

Thanks for the comments.

Posted by Peter Judge on 27-Oct-2009 15:17

rblanchard wrote:

Does anyone know of a way for the toolbar to take FOCUS when clicking on a tool within the toolbar?

Just for the record, this behaviour is by (Infragistics') design, as per the comment on this thread.

-- peter

Posted by Peter Judge on 27-Oct-2009 15:22

Finding the current Control (inside a UserControl or Form) and using the WriteData method of the Binding object(s)

I've now also run into this and thought I'd share. Since sharing is caring and all that good stuff.

You can get the Form's ActiveControl, which saves you having to loop through things. In my case, I'm using a UltraTextEditor, which morphs into something completely different (an EmbeddableTextBoxWithUIPermissions if you care). This object's Parent is the "original" text editor with the DataBindings, on which I called WriteData().

Some more info here.

-- peter

This thread is closed