[Isomorphic]

The Time component of the DateChooser is a new feature that has been introduced as part of the 9.0 release. 8.3 does not contain this feature.

[spant]

Is there a patch available for this feature in SmartClient 8.x

We are also looking the time component in the date calendar.

The messages in this post says that it is available in SmartClient 9 version.

Do we have a patch available for the same in Smart Client 8 ?

[billw]

The new version works fine. The only inconsistent thing now is that if the user clicks on Today or another calendar day, the DateChooser is immediately dismissed. If they had intended to change date and time, they must re-open it to change the time. Obviously, this is much better than before where they could not change the time at all without re-selecting the date. But is there a way to configure the DateChooser so that it only dismisses itself when the "Apply" button is clicked? Deriving a class from DateChooser would work if instantiating the component directly--but this is being instantiated via the forms datetimeitem item.

Regards,
Bill W.

[billw]

Thank you!

Regards,
Bill W.

[Isomorphic]

We've addressed both issues - please retest with a nightly build dated May 12 or later

[billw]

Also, the hour should be 1-12, not 0-11, when the mode is AM/PM.

Regards,
Bill W.

[billw]

OK, I've played with the control, and yes, it works as you say. But I believe this is not good from a user interface point of view--the user can't be expected to know they must select the time first, then the day. Here's a scenario:

1. User wants to select a date and time to tomorrow at noon.
2. They click the date first (not knowing they must select the time first).
3. Now, tomorrow's date is selected, but with the current time.
4. They go back in and change the time.
5. They don't click on the date again, because it's already correct, so they just click off of the DateChooser to dismiss it.
6. It is dismissed, and still has the wrong time.

I believe you really need an "OK" button, in addition to Today and Cancel. This will let the user choose the date/time in whatever order they want, and either accept or cancel the operation.

Regards,
Bill

[billw]

It seems confusing to me to have auto-close for one (day) but not auto-close for others (time). Doesn't that mean the user must change the time first, then the day? It would seem better to have OK/Cancel buttons, where OK fires the change notifications and changes the values, and cancel dismisses it and retains the prior value. If you don't want an OK button, clicking off the control could provide the same function and accept the changes. Either way, I can't figure out how to get the time fields to change from the DateChooser.

[Isomorphic]

Nothing. That's already what's happening.

We've tried this out on multiple machines and browsers now.. sorry, nothing further we can do to help, and we'd suggest you try to figure out how you could possibly be getting aberrant results.

[billw]

Yes, I am talking about the code I posted. Changing the hours, minutes or seconds is never reflected in the edit control, and when I get the value from that field when the "submit" button handler is called, the time value never changes. What do I need to do in order to have the user change the time values in the Date chooser and have them reflected in the value of that field?

[billw]

Same behavior on Firefox / MacOS as well.

Also, to note--I do not see either a close button or "OK" button. There is only "Today" and "Cancel". And the change notification does fire whenever the date is changed, and should also for time. Even your Date Example in feature explorer displays the date (by changing a Label content) when the datetime item's change handler is called. That also then dismisses the DateChooser, and reflects the change in the edit control.

[Isomorphic]

Are you talking about *the code you've posted*??

The DateChooser auto-dismisses when you pick a day, and does not auto-dismiss when you change the time, by design. Otherwise you couldn't set more than one time field at once.

In all cases, if the time or date portion has been changed, change fires as expected when the DateChooser closes.

The only way to avoid change firing is to discard your change - which you can do by clicking Cancel, clicking the close button or clicking outside the DateChooser.

This is consistent across Windows and MacOS - we just double-checked.

[billw]

Perhaps you are expecting change events to fire while the DateChooser is still visible? They do not (by design).

But I DO get change notifications when the DateChooser is visible--whenever I change the day. I get NO notifications when I change the time hours, minutes, or seconds. Worse than that is when I do dismiss it (by clicking off of it--not cancel), then click the submit button and retrieve the date, only the day has changed, not the time.

[Isomorphic]

Perhaps you are expecting change events to fire while the DateChooser is still visible? They do not (by design).

[billw]

No, I am not hitting cancel. I am running on MacOS, with both Chrome and Safari and see the same behavior. I get the change notifications only when changing the calendar (e.g. the day). I get no notification at all when changing the hours, minutes, or seconds, and the time shown in the edit control never changes. The ONLY way I get a notification about the time changing is when I manually edit the time in the text box, then tab out of it.