Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    DateTimeItem

    I am using the very latest development (5/9) version of SmartClient 9 beta, and checking out the DateTimeItem for the Date picker control. Seems that changing the date actually changes the item value, but changing the time values does nothing. Is this control not finished yet?

    Thanks

    #2
    Please show test code

    Comment


      #3
      Here is the code. During initialization, I place a new Date() into the control (form.getItem('startTime').setValue(new Date()). The change handler ONLY fires when I change the calendar fields. Changing the time values never fires the change handler, and when the submit button is clicked, the time stays the same as when initially populated.


      Code:
          var form = isc.DynamicForm.create({
              autoDraw: false,
              width: 400,
              height: "100%",
              title: "Start Time",
              showTitle: true,
              autoFocus: true,
              numCols: 4,
              padding: 10,
              titleOrientation: "top",
              fields: [
                  {
                      name: "program",
                      title: "Program",
                      colSpan: 2,
                      prompt: "Select Program",
                      type: "select",
                      valueMap: ['program1', 'program2']
                  },
                  {
                      name: "startTime",
                      title: "Start Time",
                      type: "datetime",
                      showPickerTimeItem: true,
                      use24HourTime: false,
                      useTextField: true,
                      colSpan: 2,
                      change: function (form, item, value, oldValue) {
                          alert(value);
                      }
                  },
                  {
                      type: "rowSpacer",
                      height: 5
                  },
                  {
                      name: "submitButton",
                      title: "Send",
                      type: "button",
                      align: "center",
                      colSpan: 1,
                      width: 140,
                      click: function () {
                          var d = form.getItem('startTime').getValue();
                          alert(d);
                      }
                  }
              ]
          });
      Last edited by billw; 9 May 2013, 07:20.

      Comment


        #4
        Running your exact code, we're not seeing this problem. Maybe you are exiting the DateChooser by hitting cancel or hitting the close button? This is expected to discard changes.

        Comment


          #5
          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.

          Comment


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

            Comment


              #7
              Originally posted by Isomorphic View Post
              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.

              Comment


                #8
                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.

                Comment


                  #9
                  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.

                  Comment


                    #10
                    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?

                    Comment


                      #11
                      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.

                      Comment


                        #12
                        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.

                        Comment


                          #13
                          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

                          Comment


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

                            Regards,
                            Bill W.
                            Last edited by billw; 10 May 2013, 02:49.

                            Comment


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

                              Comment

                              Working...
                              X