Skip to main content

JXDatePicker et al

39 replies [Last post]
Anonymous

Hi folks,

just started to look into it a bit closer (the very old issue: JXTable
needs a date cell editor :-) - there are some issues (there always are ;-)

Don't want to step on anybody's feet - so who is working on it currently?

Thanks
Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
kleopatra
Offline
Joined: 2003-06-11

okay, started a new thread for the table related focus issues/changes:

http://forums.java.net/jive/thread.jspa?threadID=29410&tstart=0

Jeanette

Kleopatra

Kleopatra schrieb:

>>
>> Can help that - by wrapping the actual commit/cancel into a
>> invokeLater. But where? Currently did it in the BasicDatePickerUI,
>> unhappily. Had to re-write some tests to do the asserts in an
>> invokeLater as well which feels ... bad.
>>
>> Hmmm ... probably should take a break while waiting for the build to
>> bark
>>
>
> build is okay - but in the meantime I moved the invoke into the
> cellEditor (feels better to have it where things go astray). Looked nice
> in my debugging/focus tracing workspace ... which is running 16 ...
> which has different focus issues than 15 ... ARRRGGGGHHH
>

just to keep track of the change process somewhere: reverted to let the
BasicDatePickerUI do the invoke. Feels wrong ... but the only way I
could make the cellEditor behave.

At the very base of all the focus related probs is the fact that the
popup gets focus at all. ComboBox never does, so is easier to handle.
Would love to do it similarly in the picker, buuut ... What's standing
in the way of doing it similarly for the picker is the more involved
keyboard navigation allowed in the monthview: keeping the focus in the
textfield leaves the horizontal navigation keystrokes ambiguous.

Hmmm ... ideas?

Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Kleopatra

Kleopatra schrieb:
>
> just to keep track of the change process somewhere: reverted to let the
> BasicDatePickerUI do the invoke. Feels wrong ... but the only way I
> could make the cellEditor behave.
>

ehem ... wrong: can't make the editor behave at all (in 1.5) ... Combo
has a similar problem: the date picker cell editor visual check now has
a method which shows core table with editable combo as editor. Commit/
cancel in the open popup transfers the focus out off the table. Can't
believe it - that's a bug I routinely hacked around in 1.2 or so!

Okay, that made my day ...

Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Kleopatra

Kleopatra schrieb:

warning: this is about core bug parade, so could well evolve into rant-ish!

>
> ehem ... wrong: can't make the editor behave at all (in 1.5) ... Combo
> has a similar problem: the date picker cell editor visual check now has
> a method which shows core table with editable combo as editor. Commit/
> cancel in the open popup transfers the focus out off the table. Can't
> believe it - that's a bug I routinely hacked around in 1.2 or so!
>

I _knew_ I have been there ... way back in 2001:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4528436

which was closed as a presumed duplicate of a RFE (still open, since 2000!)

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4307147

but could convince Shannon to re-open part of it as new (in 2002)

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4684090

which was closed as duplicate of the later (2003)

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4887999

which eventually got fixed in Mustang. In Apr. 2006, somebody (from the
core team?) commented the issue with: "I'll evaluate if it possible to
backport the fix to 1.5 update release" - but nothing happened? (note to
myself: check local update version - okay, not until u11, is that
the latest?)

Along the way, there's a quite amusing (haha) evaluation comment -
keeping in mind that each and every developer using a table with an
editable combo as editing component must cope with it:

"1.4.0 regression - not a Tiger showstopper.
xxxxx@xxxxx 2004-07-27"

to be found in (which is not yet closed - nobody keeping track of
related bugs?)

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5078516

And at it's very core, the issue is the unsatisfying interplay of table
and compound editors (from 1998, still open ...):

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4109871

BTW, just backported the 1.6 fix (in removeEditor - try to request focus
back to the table) into JXTable. Might not be totally safe, don't know
what else was changed for the fix (and focus is ... near-to untestable
;) so please let me know if it breaks anything. Will commit soon.

Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Kleopatra

Kleopatra schrieb:
>
> BTW, just backported the 1.6 fix (in removeEditor - try to request focus
> back to the table) into JXTable. Might not be totally safe, don't know
> what else was changed for the fix (and focus is ... near-to untestable
> ;) so please let me know if it breaks anything. Will commit soon.
>

done - and enhanced a bit: the fix accounts for popups owned by the
editor. This allowed to remove all focus-related editor hacks, no
invokeLater, no setting the popup and all of its comps to not focusable.

Not yet cleaned - there's some not yet quite understood permanent- vs.
focusOwner "magic" and duplicated logic in the isFocusDescending() and
the CellEditorRemover - but enough for this week.

And: waiting for feedback, don't hesitate to complain if things are broken!

Cheers
Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Kleopatra

jdnc-interest@javadesktop.org schrieb:
> Seems to be another problem with the latest JXDatePicker (though focus is working OK now - I can remove my own code)
> The popup doesn't work with the mouse unless you first give it the focus.
> It works if focus is not in editor field, seems editor field won't release focus with mouse.
> (For me anyway - Eclipse on WindowsXP; Swingx from CVS at Tue, 6.15am GMT)
>

Hmm ... don't quite understand what you mean. The visuals seem to behave
as expected (by me, can be off )

Would you please explain what you experience vs what you expect with a
small example - or some of the visual test methods, f.i.
interactiveActionEvent in JXDatePickerVisualCheck (because there are
several widgets, so focus probs would show).

Thanks
Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

rturnbull
Offline
Joined: 2005-08-27

Sorry.
Works OK in simple example but not in my application.
Must be something I'm doing.
Will investigate further

> jdnc-interest@javadesktop.org schrieb:
> > Seems to be another problem with the latest
> JXDatePicker (though focus is working OK now - I can
> remove my own code)
> > The popup doesn't work with the mouse unless you
> first give it the focus.
> > It works if focus is not in editor field, seems
> editor field won't release focus with mouse.
> > (For me anyway - Eclipse on WindowsXP; Swingx from
> CVS at Tue, 6.15am GMT)
> >
>
> Hmm ... don't quite understand what you mean. The
> visuals seem to behave
> as expected (by me, can be off )
>
> Would you please explain what you experience vs what
> you expect with a
> small example - or some of the visual test methods,
> f.i.
> interactiveActionEvent in JXDatePickerVisualCheck
> (because there are
> several widgets, so focus probs would show).
>
> Thanks
> Jeanette
>
> ------------------------------------------------------
> ---------------
> To unsubscribe, e-mail:
> jdnc-unsubscribe@jdnc.dev.java.net
> For additional commands, e-mail:
> jdnc-help@jdnc.dev.java.net

rturnbull
Offline
Joined: 2005-08-27

> Sorry.
> Works OK in simple example but not in my
> application.
> Must be something I'm doing.
> Will investigate further
>
>
>
I have done further investigation and found the following:

I have routines to open and close fields for input/no input, and I was setting all
the components in the JXDatePicker to focusable(true).
(Building JXDatePicker, button is set focusable(false))
When clicking with the mouse on the button, I was getting a Permanent focus lost, which closed the popup.

Took that out and it now works (Except not getting Permanent focus lost when Tabbing out of Edit field - still need further investigation but nearly working now.

Kleopatra

jdnc-interest@javadesktop.org schrieb:
>>
> I have done further investigation and found the following:
>
> I have routines to open and close fields for input/no input, and I was setting all
> the components in the JXDatePicker to focusable(true).

tssee .. fiddling with focusable in compound components is ... in the
general case as tricky as doing so with enabled. Wouldn't recommend it.

That said, the focus control in the datepicker is not yet quite
complete. f.i. focus somewhere else, click the button (which opens the
popup) use keyboard enter/esc to close - the focus will return to
"somewhere else". That's a glitch I introduced recently (by making the
button unfocusable).

Need to think a bit deeper. The datepicker takes control over its
childrens focus, so it should do so completely, namely: update the
editor's focusable property along with its own. And always enforce the
button's not-focusable. And grab focus before opening the popup (so we
get it after). Or do we want to transfer to next in ftp if the popup
receives a commit/cancel?

Hmmm...

Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Kleopatra

jdnc-interest@javadesktop.org schrieb:
>
> turned out that the combo's uidelegate is the magician: it requests focus for the editor in focusGained. Hard at the border of being dirty .. but c&p'ed into picker ui. So the F2-glitch seems solved.
>

turns out that I have been a bit optimistic ;-) those focus issues are
getting nastier and nastier .. while F2 indeed seems to be okay, a
commit/cancel in the popup of the cellEditor shoots the focus into the
moon (at least it's not the table...)

What seems to happen is that closing the popup transfers the focus
alright back to the picker/editor - but as that's asynchronous, the
cellEditor commit/cancel editing is earlier, removing the picker from
the table before it gets the focus. So that at the time the system tries
to give over the focus, the editor is no longer part of the hierarchy
and no substitute found ... letting it hang somewhere.

Can help that - by wrapping the actual commit/cancel into a invokeLater.
But where? Currently did it in the BasicDatePickerUI, unhappily. Had to
re-write some tests to do the asserts in an invokeLater as well which
feels ... bad.

Hmmm ... probably should take a break while waiting for the build to
bark

Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Kleopatra

Kleopatra schrieb:
>
> Can help that - by wrapping the actual commit/cancel into a invokeLater.
> But where? Currently did it in the BasicDatePickerUI, unhappily. Had to
> re-write some tests to do the asserts in an invokeLater as well which
> feels ... bad.
>
> Hmmm ... probably should take a break while waiting for the build to
> bark
>

build is okay - but in the meantime I moved the invoke into the
cellEditor (feels better to have it where things go astray). Looked nice
in my debugging/focus tracing workspace ... which is running 16 ...
which has different focus issues than 15 ... ARRRGGGGHHH

Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

rturnbull
Offline
Joined: 2005-08-27

Just to add to your woes:
Another minor problem, IMO, is you can't Tab to the button and hit Enter to bring up the popup.

Keep at it, I'm sure you'll get it right eventually :)

Kleopatra

jdnc-interest@javadesktop.org schrieb:
> Just to add to your woes:
> Another minor problem, IMO, is you can't Tab to the button and hit Enter to bring up the popup.
>

hmm .. could you before? The key bound to the togglePopup was the Space
- and it still is :-)

Which looks a bit funny, because it's inserted into the text. Which
reminds me of a open task: we need to come up with robust set of
keybindings and that set must be declared in the LAF instead of
hardcoded in the delegate.

> Keep at it, I'm sure you'll get it right eventually :)

thanks for your confidence :-)

Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Kleopatra

Kleopatra schrieb:

> With that in place,
>
> *BasicMonthViewUI* can use it to
> - set the adjusting to true when a user gesture starts changing the
> selection
> - set the adjusting to false when the user's changes are committed
>

that's where I am right now (including tests ) Going on to ..

> *BasicDatePicker* can use it to

.. is a big step, will try to stay low-intrusion, but probably there's
some rough water ahead.

Sorry for any inconvenience
Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Kleopatra

Kleopatra schrieb:
>
> the stable (value) is guaranteed to be always the same, so opening the
> dropdown from this state will automatically show the same value.
> Commit/cancel gestures in the open popup effect (or not) the synched
> stable value (details might get nasty, but at least basically its not a
> problem ;-)
>

done - at least to the extent that the datePickerCellEditor can live
with it (mostly).

Some details:

*commitXX/cancelXX api*

- formally added to both datePicker and monthView. They guarantee to
fire dedicated action events, so listening clients can distinguish a
cancel from a commit gesture.

- The picker has a "real" editing state (pending changes in the editor),
with actual commit/revert to old state.

- The monthView currently only fires, the revert to old selection is
buried in the monthViewUI (the logic is not yet cleaned). Need to think
a bit longer about the coupling between mouse and keyboard user gesture.

*ActionEvent firing*

- they are fired whenever the user makes a commit/cancel gesture (esc,
enter, keyReleased) and only then. The commit action event is fired
independent on whether the gesture actually changed the date. That's
similar to textfield/combobox. Client code interested in actual changes,
changes can monitor the date property.

- again, all control burden is in BasicDatePickerUI: it listens to
actionEvents from both editor and monthView to pass-on the commit/cancel
to the picker.

Next thing I'll do is to stabilize the pickerCellEditor (and the related
EditorRemover for the JXTable), so it can be moved soon into trunk. With
a wider exposure I expect the bugs to shake out quickly, hope they don't
bury me

Cheers
Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

tiberiu
Offline
Joined: 2006-03-01

> Implementation details
> - the date is stored in a dateSelectionModel
> - the owner of the dateSelectionModel is the
> monthView
> - the textfield has a copy of the date (? its value)
Shouldn't the text field use the dateSelectionModel? And ask it about the selected date? Not a copy of a date. The textfield should be replaced by a special component that uses a textfield and a dateSelectionModel (the same as the one used by the monthView)

> - the synch between the two copies is the
> responsibility of the
> BasicDatePickerUI
In the way I have suggested you do not have two copies of the date but the same dateSelectionModel, so no synch... (am I right?)

> Probably never mentioned it, but public event
> triggering api (like f.i.
> postActionEvent in both JXDatePicker and JXMonthView)
> is a "don't" in my
> book of rules - usually a sign that something is not
> quite optimal
Good.

> Assuming the pickerUI is responsible for keeping the
> everything in synch
> the JXDatePicker itself is doing too much:
> I would prefer to delegate the dirty details
> somewhere else:
OK.

> [code]
> // either directly in the ui
> getUI().setDate(date);
No.

> // or indirectly via the monthView
> monthView.setSelectedDate(date);
Yes. Preferred. This job is already done on monthView. It's ok to delegate it.

> F.i. the code snippet needed to get the selected date
> from the monthView
> That's inconvenient and error-prone for a client
> (such as the datePicker
> or its ui-delegate) which is interested in the first
> only - so I took
> the freedom to add a getSelectedDate
Ok.

Tibi

Kleopatra

Kleopatra schrieb:

forgot yesterday, or maybe was not clear:

> Event type
>
> Picker's date is not a bound property. This hinders typical binding.

it is now - so binding should be okay now (didn't test yet, Shannon is
the middle of a bigger change).

Needed to make some other properties bound as well (like JXMonthView
timezone, picker formats) to fix synch state bugs in those properties -
#554-swingx f.i.

Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Kleopatra

Kleopatra schrieb:

another sequel (while waiting for the latest commit to pass or fail ;-)

>
> What I would like to do is to move the synch control entirely into the
> PickerUI (probably need some additional methods). Not sure if that's
> completely possible - but think so, being optimistic
>

done, though

- it was hard stuff
- it's still dirty

Those "cleaned" dates posed problems without end (not the only ones ..)
While not documented, the picker.setDate() results in the date being
cleaned in the end, that is

[code]
Date date = new Date();
picker.setDate(date);
assertEquals(date, picker.getDate())
[/code]

usually fails. So to keep my sanity, I run all tests with a "cleaned"
date (added a method to the XTestUtils, too lazy to move that into the
DateUtils where it probably belongs) Which might not be entirely safe ...

Plus the picker itself has no notion of the cleaning - should it? It's
done in the JXMonthView, invisible methods. Had to duplicate in the
BasicPickerUI to allow the picker to back-out from setDate if the
passed-in date is the same as the current (needed to cut the update
spiral somewhere) ... haha, this paragraph is totally confusing, better
you read the code Or in snippets:

[code]
// typically backing out.
// not possible because in the end
// the synched date is cleaned (time elements 0)
void setDate(Date date) {
if (equals(getDate(), date)) return;
...
}

// so delegate to the ui:
// needed to do something along that line anyway
// to handle unselectables
void setDate(Date date) {
try {
date = getUI().getSelectableDate(date);
} catch (PropertyVetoException e) {
return;
}
Date old = getDate();
this.date = date;
firePropertyChange("date", old, getDate());
}
[/code]

and now the pickerUI implementation (younger developers leave the room,
please :-)

[code]
@Override
public Date getSelectableDate(Date date)
throws PropertyVetoException {
Date cleaned = date != null ? cleanupDate(date) : null;
if (equalsDate(cleaned, datePicker.getDate())) {
throw new PropertyVetoException("date not selectable", null);
}
if (cleaned == null) return cleaned;
if (datePicker.getMonthView()
.isUnselectableDate(cleaned.getTime())) {
throw new PropertyVetoException("date not selectable", null);
}
return cleaned;
}
[/code]

It's clearly a gross mis-use of the PropertyVetoException but the thing
I'm most worried about is the duplication of the date cleaning .. it
that is changed in the monthview (not that I expect it, but changes are
everywhere always), the picker will blow

Another slightly annoying thing is the mixture of long/date in the api,
even in JXDatePicker which takes a long in the constructor. Why the ...
do we want to keep the long? DateSelectionModel acts on Date
exclusively, shouldn't the views as well? If we really, really, really
want the long to stay (and really really very hard want it) then all
methods must come in both variants ...

Anyway, the tests are passing so far. Waiting for complaints

Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

kschaefe
Offline
Joined: 2006-06-08

> Another slightly annoying thing is the mixture of
> long/date in the api,
> even in JXDatePicker which takes a long in the
> constructor. Why the ...
> do we want to keep the long? DateSelectionModel acts
> on Date
> exclusively, shouldn't the views as well? If we
> really, really, really
> want the long to stay (and really really very hard
> want it) then all
> methods must come in both variants ...
Wouldn't you say the annoying thing is that this will need to be reworked when the new date API comes out? ;)

I think that we should favor Date over long and remove the uses of long.

Karl

Kleopatra

jdnc-interest@javadesktop.org schrieb:

> Wouldn't you say the annoying thing is that this will need to be reworked when the new date API comes out? ;)
>

new date api? ehem ... will happily leave the re-work to somebody else ;-)

> I think that we should favor Date over long and remove the uses of long.
>

my favourite as well - will call for a vote soon (and make sure whoever
votes for keeping the long will be condemned to do the work )

Cheers
Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Kleopatra

Kleopatra schrieb:

coming back to the start at last ...
>
> Looks like there are basically two problems:
>
> - JXDatePicker not firing enough events to make an editor happy
> - table's editorRemover cut's the edit as soon as the monthview gets the
> focus
>

solved (as described and at first approximation) and committed. The
DatePickerCellEditor is not registered by default, I'm not that bold .

One remaining issue I noticed, is that F2 does not move the focus into
the picker's editor. That's an old problem with compound components,
I'll have to dig to find the exact state right now. Combo doesn't suffer
because it's a VIP (special cased throughout swing) when used in a table
as editor.

Ducking out of the way (so the tomatoes will not hit me), I'm hungry, as
usually at this time of the day

Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

kleopatra
Offline
Joined: 2003-06-11

> Kleopatra schrieb:
>
> One remaining issue I noticed, is that F2 does not
> move the focus into
> the picker's editor. That's an old problem with
> compound components,
> I'll have to dig to find the exact state right now.
> Combo doesn't suffer
> because it's a VIP (special cased throughout swing)
> when used in a table
> as editor.
>

turned out that the combo's uidelegate is the magician: it requests focus for the editor in focusGained. Hard at the border of being dirty .. but c&p'ed into picker ui. So the F2-glitch seems solved.

A still unsolved (not specific to the usage in a cellEditor) mystery is that the popup isn't closed when clicking into another picker/editable combo:

https://swingx.dev.java.net/issues/show_bug.cgi?id=565

seems to be related to some tricksery of picker/combo to keep the popup open (when clicking into the owning combo controlled components like arrowbutton, inputfield) .. please see the code/bug comment for details.

Hmm ... ideas?

Cheers
Jeanette

rturnbull
Offline
Joined: 2005-08-27

Seems to be another problem with the latest JXDatePicker (though focus is working OK now - I can remove my own code)
The popup doesn't work with the mouse unless you first give it the focus.
It works if focus is not in editor field, seems editor field won't release focus with mouse.
(For me anyway - Eclipse on WindowsXP; Swingx from CVS at Tue, 6.15am GMT)

(Don't like this new forum where posts show after the post you are replying to, instead of at the end :( )

rah003
Offline
Joined: 2004-05-26

> (Don't like this new forum where posts show after the post you are replying to, instead of at the end :( )

You can change that easily. On top of the screen click on "Your Control Panel" then on "Your forum settings" and select "Thread page view" type "Flat".

rturnbull
Offline
Joined: 2005-08-27

> > (Don't like this new forum where posts show after
> the post you are replying to, instead of at the end
> :( )
>
> You can change that easily. On top of the screen
> click on "Your Control Panel" then on "Your forum
> settings" and select "Thread page view" type "Flat".

Thanks.
Didn't know about that.
It actually was set to 'Flat', but I had to set it to something else, log off, log on, set it back to 'Flat' before it took.
Fine now. Thanks Again

Correction:
Maybe it wasn't set to Flat.
Perhaps that's just the first option in the combobox

Message was edited by: rturnbull

Kleopatra

Kleopatra schrieb:

>
> just started to look into it a bit closer (the very old issue: JXTable
> needs a date cell editor :-) - there are some issues (there always are ;-)
>
> Don't want to step on anybody's feet - so who is working on it currently?
>

no complaints so far - and now it's too late, I'm digging

A summary of my understanding so far

- the datepicker's (primary? are there secondaries?) purpose is to allow
for easy input of a single date
- client code is interested in the date only and wants to be notified
when the date changed, f.i. to allow binding
- the picker combines and controls two views of the date:
* the (formatted) text field showing a formatted string
* the monthView showing the date in a (time) context

Implications:
- the textfield and monthview must be kept in synch at all "stable" times.
- there might be "unstable" phases, f.i. while
* typing in the textfield
* changing the selection in the dropdown via keyboard (arguable)
- the picker must fire an event when the date is changed, at least when
the "stable" date changed.

Implementation details
- the date is stored in a dateSelectionModel
- the owner of the dateSelectionModel is the monthView
- the textfield has a copy of the date (? its value)
- the synch between the two copies is the responsibility of the
BasicDatePickerUI

Some comments, as usual in no particular order nor weight:

Event type

Picker's date is not a bound property. This hinders typical binding.
Instead it fires actionEvents - but not always: the overall action
firing behaviour is similar to that of a formatted textfield, but
different from both simple textField and comboBox. Plus the carried
event is rather uninformative - no way to detect what really went on.

Competing actors

Assuming the pickerUI is responsible for keeping the everything in synch
the JXDatePicker itself is doing too much: f.i. by setting the value of
the editor directly. Personally, I'm slightly weary of code like the
following in the *view*:

[code]
Date selectedDate = monthView.getSelectedDate()
if (date == null && selectedDate != date) {
monthView.clearSelection();
getEditor().setValue(date);
} else if (someother state) {
...
}
[/code]

I would prefer to delegate the dirty details somewhere else:

[code]
// either directly in the ui
getUI().setDate(date);
// or indirectly via the monthView
monthView.setSelectedDate(date);
[/code]

my (currently still wild) guess is that (most of?) the problems with
event notification are due to a certain spread of accessing the
internals of the editor and the monthView. My gut (slightly unreliable
at the moment, getting hungry ) tells me to leave modificatin of the
editor's value entirely into the ui-delegate: it does all the
creation/adding/listening anyway.

Code duplication due to low-level api

F.i. the code snippet needed to get the selected date from the monthView

[code]
SortedSet selection = _monthView.getSelection();
Date selectedDate = selection.isEmpty() ?
null : selection.first();
[/code]

That's inconvenient and error-prone for a client (such as the datePicker
or its ui-delegate) which is interested in the first only - so I took
the freedom to add a getSelectedDate

What I would like to do is to move the synch control entirely into the
PickerUI (probably need some additional methods). Not sure if that's
completely possible - but think so, being optimistic

Opinions, please? Looking forward to any feedback, critics, outlines of
where I missed the point ...

Okay, have a nice weekend, hunger is winning
Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Kleopatra

Kleopatra schrieb:

same procedure as always, muttering to myself ;-) Seems to the fate of
all [FYI] even if unmarked.

On the other threads (discussion incubator variations of the date input
from Ray, Markus) a slight glitch in usability surfaced: if the editor
is editing (that is, has uncommitted changes) and the drop-down is
opened, the drop-down is not synched with the current value but with the
last committed. So the month view is near to useless, especially if the
last committed is far-off.

Ray detected a suspicious line of code in the BasicDatePickerUI when
opening via mouse on the button:

[code]
// in mousePressed
if (!datePicker.isEditable()) { // this line is wrong, remove !
// commit
}
togglePopup(...)
[/code]

which looks like the intention was to commit before opening. But chances
are that there are no pending changes on a non-editable datePicker (not
entirely true, could have set the editor's text programmatically, but
mostly). So a first go was to invert the logic - force a commit on a
editable picker ... which fires an actionEvent on opening, which stops
an edit in a pickerCellEditor the moment the popup is opened.

Now I could hack around that in the cellEditor, but it might be
unintuitive behaviour in more general contexts as well. After all,
user's intention on opening the popup is the go on with the edit, not to
commit what is currently there.

So I think we need to have a closer look at the state transitions
involved. Both the editor and the dropdown (taken isolated) have
basically similar transisition semantics:

[code]
one path from stable to editing:

stable --(startEditing)--> editing

two paths back from editing to stable:

<--(cancel)---
stable editing
<--(commit)---

[/code]

startEditing is typing/setting text in the editor, and navigate with the
keyboard in the dropdown.

When combined, the situation is a bit more complex:

the stable (value) is guaranteed to be always the same, so opening the
dropdown from this state will automatically show the same value.
Commit/cancel gestures in the open popup effect (or not) the synched
stable value (details might get nasty, but at least basically its not a
problem ;-)

the editing (value) is not synched automatically, so opening the
dropdown with a pending edit should enter the editing state of the
dropdown and try to synch the (possibly invalid) intermediate values of
editor/monthView. Then an explicit commit gesture in the monthview has
the same effect as if started from stable.

The question is the cancel: should it revert to the old stable or revert
to the editing value of the editor (that is, have no effect on the
editor)? Reverting to stable might annoy a user who opened the
monthView to get an overview of where she is in calendar-space and
clicks back into the textField to continue the input. Do nothing might
annoy a user who really wants to back out all the way, she would have to
double press the escape. Hmm ... maybe configurable? Similar to the
focusLostBehaviour of an formattedTextField?

In summary: the state transitions between editor-editing and
monthView-editing need to be clarified. Currently we go from
editor-editing to monthView-stable. The first attempt to synch on the
editing value led to a commit - which might be wrong, IMO.

Okay, that's enough for a Saturday.

Thanks for listening!
Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Kleopatra

Kleopatra schrieb:
>
> same procedure as always, muttering to myself ;-) Seems to the fate of
> all [FYI] even if unmarked.
>

DRY - so won't.

To keep you informed of what I'm doing (mostly silently)

> the stable (value) is guaranteed to be always the same, so opening the
> dropdown from this state will automatically show the same value.
> Commit/cancel gestures in the open popup effect (or not) the synched
> stable value (details might get nasty, but at least basically its not a
> problem ;-)
>

first off, it's actually a three-party synch:
- picker.getDate
- picker.getEditor().getValue
- picker.getMonthView().getSelectedDate()

must all be the same in the "stable" state.

In fact, they aren't - I filed (and partly hot-fixed) several issues,
details are in the tests.

Trying to do so revealed bunch of more or less heavy stumble-stones:

As I mentioned earlier in this thread: synch control a bit "smeared"
across collaborators. The "right-way-out" is to move the control into
the ui delegate. In regard to date selection, it'll listen to
appropriate events from the monthView's model. This is hampered by

- action events from monthView not fired reliably (would be a mis-use
anyway to rely on them, because the synch would be missing programatic
selection changes)
- the only way to keep track of selection changes is a
dateSelectionListener, but: no way for the listener to decide when the
selection is underway as opposed to stable.

Which leads to the DateSelectionModel api: at it's base it's similar to
a ListSelectionModel (except for the type of the selected items) - so I
think it should have analogous methods. Missing are (incomplete list):

[code]
// allow clients to mark a change as under-way
void setAdjusting(boolean);
boolean isAdjusting();

// notion of lead/anchor
// good for multiple selection
void setAnchorSelectionDate();
void setLeadSelectionDate();
// from DefaultListSelectionModel
void moveLeadSelectionDate();
... + getters

// while a bit of convenience,
// these will reduce the need to copy
// of the whole set of selected dates
Date getMinSelectionDate();
Date getMaxSelectionDate();
[/code]

For now I'll go with the first block. This will require to add new event
type/s to the DateSelectionEvent and let the model use it. Excisting
client code is not effected - while not aware of the new state, it
shouldn't hurt.

With that in place,

*BasicMonthViewUI* can use it to
- set the adjusting to true when a user gesture starts changing the
selection
- set the adjusting to false when the user's changes are committed

*BasicDatePicker* can use it to
- listen to dateSelection changes (currently doesn't, that's part of the
synch problems)
- if adjusting, do nothing
- if not adjusting, update picker's internals
- listen to action events (now does, but in the popup only, that's
another part of the synch probs) and route them to the picker (something
I personnally don't like, but can be left for later cleanup)

At least, that's the plan :-) Considering, that the only thing I wanted
to do was to officially support a datePickerCellEditor, this turned into
quite a task ..

Feedback highly welcome!

Back to weaving the security net (unit tests are my friends :)
Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

kschaefe
Offline
Joined: 2006-06-08

> Kleopatra schrieb:
> >
> > same procedure as always, muttering to myself ;-)
> Seems to the fate of
> > all [FYI] even if unmarked.
> >
>
> DRY - so won't.
I only interject when I have something to say. Besides your ramblings are always so entertaining. :)

[snip]

> Trying to do so revealed bunch of more or less heavy
> stumble-stones:
>
> As I mentioned earlier in this thread: synch control
> a bit "smeared"
> across collaborators. The "right-way-out" is to move
> the control into
> the ui delegate. In regard to date selection, it'll
> listen to
> appropriate events from the monthView's model. This
> is hampered by
If we have a UI delegate, as we do in this case, we should rely on the delegate as much as possible.

> - action events from monthView not fired reliably
> (would be a mis-use
> anyway to rely on them, because the synch would be
> missing programatic
> selection changes)
> - the only way to keep track of selection changes is
> a
> dateSelectionListener, but: no way for the listener
> to decide when the
> selection is underway as opposed to stable.
>
> Which leads to the DateSelectionModel api: at it's
> base it's similar to
> a ListSelectionModel (except for the type of the
> selected items) - so I
> think it should have analogous methods. Missing are
> (incomplete list):
>
> [code]
> // allow clients to mark a change as under-way
> void setAdjusting(boolean);
> boolean isAdjusting();
>
> // notion of lead/anchor
> // good for multiple selection
> void setAnchorSelectionDate();
> void setLeadSelectionDate();
> // from DefaultListSelectionModel
> void moveLeadSelectionDate();
> ... + getters
>
> // while a bit of convenience,
> // these will reduce the need to copy
> // of the whole set of selected dates
> Date getMinSelectionDate();
> Date getMaxSelectionDate();
> [/code]
I like these suggestions, but I'm not too sure about the last two. They don't seem to play well with SelectionMode.MULTIPLE_INTERVAL_SELECTION.

> For now I'll go with the first block. This will
> require to add new event
> type/s to the DateSelectionEvent and let the model
> use it. Excisting
> client code is not effected - while not aware of the
> new state, it
> shouldn't hurt.
Looking at ListSelectionEvent for advice, I'm not sure new types are necessary, but new internal state might be. Copying getValueIsAdjusting from ListSelectionEvent into DateSelectionEvent would handle (what I think your problem is) without new types and clearly allows me to determine if my state is adjusting and what that adjustment is (the actual event "type").

> With that in place,
>
> *BasicMonthViewUI* can use it to
> - set the adjusting to true when a user gesture
> starts changing the
> selection
> - set the adjusting to false when the user's changes
> are committed
>
> *BasicDatePicker* can use it to
> - listen to dateSelection changes (currently doesn't,
> that's part of the
> synch problems)
> - if adjusting, do nothing
> - if not adjusting, update picker's internals
> - listen to action events (now does, but in the popup
> only, that's
> another part of the synch probs) and route them to
> the picker (something
> I personnally don't like, but can be left for later
> cleanup)
>
> At least, that's the plan :-) Considering, that the
> only thing I wanted
> to do was to officially support a
> datePickerCellEditor, this turned into
> quite a task ..
>
> Feedback highly welcome!
Well, you've got mine.

Karl

Kleopatra

Hi Karl,

> I only interject when I have something to say. Besides your ramblings are always so entertaining. :)
>

your comments are always highly welcome - saved me the one or other
time from overshooting!

>>
>> // while a bit of convenience,
>> // these will reduce the need to copy
>> // of the whole set of selected dates
>> Date getMinSelectionDate();
>> Date getMaxSelectionDate();

> I like these suggestions, but I'm not too sure about the last two. They don't seem to play well with SelectionMode.MULTIPLE_INTERVAL_SELECTION.
>

not too sure about those myself, they are here by analogy only. It might
be helpful to limit the overall range from earliest to latest without
actually accessing it. Don't know if really needed .. and I will not
tackle it without a real need, much too lazy for that ;-)

>> For now I'll go with the first block. This will
>> require to add new event
>> type/s to the DateSelectionEvent and let the model
>> use it. Excisting
>> client code is not effected - while not aware of the
>> new state, it
>> shouldn't hurt.
> Looking at ListSelectionEvent for advice, I'm not sure new types are necessary, but new internal state might be. Copying getValueIsAdjusting from ListSelectionEvent into DateSelectionEvent would handle (what I think your problem is) without new types and clearly allows me to determine if my state is adjusting and what that adjustment is (the actual event "type").
>

Hmm ... I don't think that ListSelectionEvent is overly helpful here, it
doesn't have the notion of EventTypes at all. My use-case are clients as
BasicPickerUI: it might be helpful for them to get a dedicated
start/stop adjusting event. It's my gut welling up analogy: always was
irked by that the start was missing from the cellEditor notification :-)
For now, I added it, will revert if not helpful.

>> Feedback highly welcome!
> Well, you've got mine.
>

cool, now I feel a lot less left-alone.

Thanks
Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

rturnbull
Offline
Joined: 2005-08-27

> >> Feedback highly welcome!
> > Well, you've got mine.
> >
>
> cool, now I feel a lot less left-alone.
>
> Thanks
> Jeanette
>

You are definitely not alone. Your good work is very much appreciated (by me at least, and I am sure the great majority).
I'm sure many are quietly watching from the sidelines. (This post has had 236 views so far.)
Sometimes things are a little to complex for some of us to make meaningful comments on.
And always remember, you'll be told if you do something wrong :)

Kleopatra

Ray,

thanks for your kind words!

> And always remember, you'll be told if you do something wrong :)

yeah, that's sure

Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

osbald
Offline
Joined: 2003-06-13

Not currently working on it but I've a copy of a very simple JXDatePickerCellEditor in my incubator. Needs some work to bring it up-to well-behaved celleditor spec.

- Richard

Kleopatra

jdnc-interest@javadesktop.org schrieb:
> Not currently working on it but I've a copy of a very simple JXDatePickerCellEditor in my incubator. Needs some work to bring it up-to well-behaved celleditor spec.
>
>

cool - will look at it at once :-)

Thanks for the pointer!
Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Kleopatra

Kleopatra schrieb:
> jdnc-interest@javadesktop.org schrieb:
>> Not currently working on it but I've a copy of a very simple
>> JXDatePickerCellEditor in my incubator. Needs some work to bring it
>> up-to well-behaved celleditor spec.
>>
>>
>
> cool - will look at it at once :-)
>

Done - and played a bit (copied to kleopatra/foreign/osbald and renamed
- no JX for non-components ;-)

Looks like there are basically two problems:

- JXDatePicker not firing enough events to make an editor happy
- table's editorRemover cut's the edit as soon as the monthview gets the
focus

The first must be solved in the datePicker - added some tests and a
visual (commented) comparison between textfield/formatted/datePicker
behaviour on enter/click/esc to the JXDatePickerIssues. Probably related
to #235-swingx.

The second is solved by a custom editorRemover which looks out for
JPopupMenus and switches the walk over to its invoker (thanks to Hans'
blog). It's still experimental in incubator, will move it over to trunk
as soon as I'm reasonably sure nothing's blown.

CU
Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

kschaefe
Offline
Joined: 2006-06-08

The build was broken by your last check in, Jeanette. Can you please check in the missing file:
org.jdesktop.test.ActionReport

Thanks,

Karl

Kleopatra

jdnc-interest@javadesktop.org schrieb:
> The build was broken by your last check in, Jeanette. Can you please check in the missing file:
> org.jdesktop.test.ActionReport
>

oops .. done. Sure my bad to forget .. but shouldn't the failure
notification bang on my mailbox?

Sorry for the mess!
Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

kschaefe
Offline
Joined: 2006-06-08

> oops .. done. Sure my bad to forget .. but shouldn't
> the failure
> notification bang on my mailbox?
Never seemed to email me whenever I submitted a failing test.

Jan, you seem to be the one in charge of this, can we set up email notification?

Karl

Kleopatra

jdnc-interest@javadesktop.org schrieb:
> Never seemed to email me whenever I submitted a failing test.
>

usually I get it (whenever it fails, even if I'm not the culprit as
today :-) - funny thing here is that I didn't get the failure
notification, but shortly after the commit of the missing class, I got
the all-good-again notification. Maybe the server was down?

> Jan, you seem to be the one in charge of this, can we set up email notification?
>

I'll second that - notification to all committers should be part of the
standard setup.

CU - my day is over now, out into the evening sun
Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net