Ok Scott, you should be good to go with respect to initiating edits in this way, though it comes at a price: your editor won't be able to use the flip transition. If you sync from SVN, TableViewRowEditor now supports a get/setEditEffect(), so you can specify that it uses no effect (which is now the default), or any of the CardPaneSkin selection change effects. The edit doesn't officially finish until the edit effect transition is complete, so you can't initiate another edit until that happens. In your case, since you want to initiate an edit as soon as the user clicks on another row, you must turn leave the edit effect off to ensure that the prior edit completes immediately.
Give it a show and let me know how it works, -T On Thu, Sep 10, 2009 at 5:57 PM, Todd Volkert <[email protected]> wrote: > Ok, the issue is that the editor is throwing that exception because it > still thinks it's editing (because the close transition is still running). > This will take a little time to fix correctly - I'll let you know when the > fix is in (should be in a day or two). > > -T > > > On Thu, Sep 10, 2009 at 5:29 PM, Todd Volkert <[email protected]> wrote: > >> That's what I get for telling you it'll work to programatically invoke the >> editor without ever having tried it myself :) I'll investigate... >> >> -T >> >> >> On Thu, Sep 10, 2009 at 5:08 PM, Scott Lanham <[email protected]> wrote: >> >>> Thanks Heaps Todd, that works well :-) >>> >>> There is now a problem with the TableView (never a dull moment). Using a >>> stock >>> TableViewRowEditor, when a row is selected using a single click, I am >>> putting >>> the TableView into edit mode using TableView.getRowEditor().edit(). This >>> works >>> fine the first time but if I immediately click on another row the >>> TableViewRowEditor throws a java.lang.IllegalStateException. >>> >>> On Fri, 11 Sep 2009 01:59:08 am Todd Volkert wrote: >>> > Ok, after looking into this, the issue was that TableViewRowEditor was >>> > consuming the mouseDown event at the display level during the >>> tunnelling >>> > phase. I've checked in an update to all editors that should make them >>> > behave correctly now. If you're implementing a custom editor, you'll >>> have >>> > to make a similar change to your editor. More or less, two things are >>> > needed. First, you'll have to let the mouse event propagate downwards, >>> and >>> > second, you'll have to move the owner window to front when the popup >>> > closes. If you're using a stock editor, you'll just have to sync :) >>> > >>> > -T >>> > >>> > On Wed, Sep 9, 2009 at 9:55 PM, Scott Lanham <[email protected]> >>> wrote: >>> > > Thanks Todd, that is exactly right. >>> > > >>> > > On Thu, 10 Sep 2009 11:52:34 am Todd Volkert wrote: >>> > > > If I'm understanding you right, this question is best left to Greg. >>> > > > But I'd just like to clarify the scenario: >>> > > > You mean you have a TextInput (let's call it A) that is outside the >>> > > >>> > > purview >>> > > >>> > > > of the TableView. You enter edit mode on a TableView row, then >>> click A >>> > > > - and the desired behavior is that this will simultaneously save >>> the >>> > > > edits (closing the editor) and focus A? >>> > > > >>> > > > That sounds reasonable - I just wanted to make sure that we were >>> > > > talking about the same scenario :) >>> > > > >>> > > > -T >>> > > > >>> > > > On Wed, Sep 9, 2009 at 9:41 PM, Scott Lanham <[email protected]> >>> wrote: >>> > > > > Hi, >>> > > > > >>> > > > > After a TableView row has being edited using a TableViewRow >>> editor, >>> > > > > if >>> > > >>> > > I >>> > > >>> > > > > click >>> > > > > on say a TextInput, the row finishes editing but the TextInput >>> > > > > doesn't receive >>> > > > > the focus. Is there a way that I can get the component that is >>> > > >>> > > "clicked" >>> > > >>> > > > > on after a row edit to receive the focus? >>> > > > > >>> > > > > Thanks, >>> > > > > >>> > > > > Scott. >>> >>> >> >
