Skip to main content

Actions, keyboard, and JXMonthView

4 replies [Last post]
hobson
Offline
Joined: 2009-02-18
Points: 0

On the following topic: https://swingx.dev.java.net/issues/show_bug.cgi?id=1052

So now I think that it is much better idea to post here first, and report a bug later, than throw reports at you about things which come out to be 'features' :)

Still, have some questions about this behaviour: it is possible to tab on calendar, traverse some days/weeks with keyboard, and tab out of it. In this case, seletction gets updated (getSelectionDate() returns new value), but action listeners are not fired, so action is never 'commited', right?
I am sorry if my questions sound silly, but I am kinda new to Swing and its architecture, tho I have some java experience. Unfortunately, I am not much into Swing internals, just know basic things about actions, models, etc.
Now I need to somehow get a notification about single day selection changing when calendar is traversed with keyboard (or, precisely speaking, when I see that 'this little blue rectangle' moves, and next call to getSelectionDate() will return new value indicated by it). Any advice on this?
When I am out of work today, I will try myself at home, Maybe I will learn something new :)

Cheers

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
kschaefe
Offline
Joined: 2006-06-08
Points: 0

> To get notified about selection changes you want to
> install a DateSelectionListener (just to be sure we
> are we are talking about the same thing here: it's a
> stand-alone JXMonthView, right?). ActionListeners are
> only notified of a selection is committed or
> canceled. That's why I closed the issue as invalid.

The catch is JXMonthView should never fire ActionEvents. It doesn't fit. What is the "action" that is occurring? A data selection? We have date selection events and listeners for that. Compare JXMonthView to JTable. Could you imagine a JTable that fired action events? Under what circumstances? Just doesn't fit.

The problem is that JXMonthView was never really intended to be used as a fully-independent component. Sure, you can do that. But it has a bunch of kruft in the API for use as JXDatePicker's editor. I said it a long time ago that I felt JXDatePicker need to have an "editor" in the same way that JComboBox does. Some pluggable thing that allows me to define the interactions that JXDatePicker needs to have with its editor.

Right now, because we've never made that separation, we've kludged JXMonthView. It's API contains inappropriate elements and the ActionEvent-related items are among them.

In short, we need to remove all ActionEvent items from JXMonthView.

Karl

kleopatra
Offline
Joined: 2003-06-11
Points: 0

Good point! Agree, that action-related api is nothing very useful, in fact, it's legacy which survived all revision rounds so far.

Just nit-picking: having or not a actionEvent (and commit/cancel api) on the monthView is as unrelated to picker's editor as is the selection in a combo's drop-down is to the combo's editor :-) Meaning, it's a different issue (on which we disagree ).

Cheers
Jeanette

kleopatra
Offline
Joined: 2003-06-11
Points: 0

always good to bring the more horrendous "features" out into the open. Plus there rarely are any "silly" questions :-) Plus there was no way to know because the api-doc is .. ehem ... sparse ...

To get notified about selection changes you want to install a DateSelectionListener (just to be sure we are we are talking about the same thing here: it's a stand-alone JXMonthView, right?). ActionListeners are only notified of a selection is committed or canceled. That's why I closed the issue as invalid.

The catch is - there always is one : what the hell does that mean, "committed"? Kind of: now-we-are-done-with-selecting-take-the-current-state-as-ready. It's created internally by the ui-delegate and (mostly) targeted for use in the datePicker: only when a change is committed, that change is propagated to the picker's date property. So comes that changing by mouse fires but changing by keyboard doesn't: only navigating by keyboard must not (for the sake of the picker) be regarded as a finalized (aka: committed) change, only an explicit enter should. Navigating by mouse on the other hand is un-ambigous as it happens by clicking the navigation buttons, clearly distinguished from selection which is clicking/dragging in the day/s. So here a committed can be fired on mouseReleased for the latter.

Long-winded way of saying: the bug is elsewhere As part of evaluating the report, I looked at the visual test method which logs the selection/actionEvents. Turned out that the log wasn't overly informative due to the DateSelectionEvent not having a toString implemented. With that in place, it turned out that a selection by keyboard only _never_ is finalized, in fact the selectionModel never even fires an event or type ADJUSTING_STOPPED, all subsequent change events come with the isAdjusting set to true. Being so, selectionListeners don't have a means to decide when a selection change is considered as final.

Fixing that will require some deeper thoughts, we want the picker un-effected. Hmmm ... Ideas wellcome! Anyway, will file a new issue, so we don't forget about it.

Thanks for reporting those nasty glitches, that's the only way they can get fixed :-)

Jeanette

kleopatra
Offline
Joined: 2003-06-11
Points: 0

for your information: the new issue is

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

CU
Jeanette