Announcement

**acarur01** · 19 Oct 2011, 08:46

From what I am seeing, dateFormatter and inputFormatter is being called a few times. In our case it is actually calling dateFormatter for a third time but with the old value being passed in instead of the new one chosen from the date picker

And to make it even more fun, it is perfectly fine in IE. Firefox it misbehaves. Cleared cache and all. I cannot reproduce as a standalone but any change log you can provide would help me figure out what exactly is wrong.

I also wanted to find out when exactly dateFormatter and inputFormatter is called. If you look at the sample below, on load dateFormatter is called twice. When you click on the date picker, inputFormatter is called once and dateFormatter is called once. Select a value from the date picker and again inputFormatter is called once and dateFormatter is called once.

Code:


isc.DynamicForm.create({
    ID: "dateForm",
    numCols: 4,    
    width: 600,
    fields: [
        {name:"directInputDate", title:"Direct Input Date", type:"date", 
        init: function(){ 
            var dateItem = this; 
             window.cwCountFormatting = 0;
   window.cwCountFormattingInput = 0;            
this.dateFormatter = function(){window.cwCountFormatting=window.cwCountFormatting+1;dateLabel.setContents(dateLabel.getContents() + " date " +window.cwCountFormatting);return this;};
            this.inputFormat = function(string){window.cwCountFormattingInput=window.cwCountFormattingInput+1;dateLabel.setContents(dateLabel.getContents() + " input " +window.cwCountFormattingInput);return string;};
            this.Super("init", arguments);},
        useTextField:true}
    ]
});

isc.Label.create({
        ID: "dateLabel",
        top: 200,
        left: 100,
        width: 400
});


dateForm.setValue('directInputDate', new Date());

**Isomorphic** · 19 Oct 2011, 11:58

There was a change made on October 10 to resolve an issue reported here:
http://forums.smartclient.com/showthread.php?t=19176
This would seem to be the likely culprit from your description.

In short, in date items where the time is visible (so typically DateTimeItems), the standard formatters are ambiguous, in the sense that since they don't display seconds and milliseconds. Therefore when parsing a user entered value these would be set to zero, but when displaying a programmatically set value, the value passed in might actually have non-zero time.
The bug was that a user could simply tab through a field with its value set programmatically to a time that had non zero seconds and the value would be updated to have zero seconds and changed handlers would fire, even though the user hadn't actually changed anything.

We therefore now don't fire the changed handler / update value if the user entered value matches the formatted version of the currently stored value, even if the parser would return a slightly different date.

The code in question is in dateItem.updateValue() -- check for the conditional like this:

Code:

            if (this._value == date || 
                (isc.isA.Date(this._value) && (this.formatDate(this._value) == dateString)))
            {
                delete this._suppressUpdates;
                return;
            }

If you disable this conditional and your code starts working, its likely responsible for the breakage within your application.
However as far as we can tell this logic is actually valid, so we'd need to know how its breaking your use case before we can determine whether we have a logic bug in the framework, or whether your usage is actually invalid and just happened to work before (and suggest a new approach for you...)

**acarur01** · 19 Oct 2011, 12:20

Sorry where do I put this code? Override updateValue and set it to this function?

Also, the date field that is failing has a format like dd/mm/yyy HH

**acarur01** · 19 Oct 2011, 12:34

Ok Found it - when I comment out that check then my date issues work now. What next info could I give you ?

**acarur01** · 19 Oct 2011, 12:39

Also, as a quick fix for us, is there any harm in just commenting out this code (beside the previous bug filed) until we can reproduce as a standalone?

**Isomorphic** · 19 Oct 2011, 12:51

You could just disable this check with no ill effects (other than the issue described in the other thread). However you'd be overriding an unexposed method which would be basically unsupported - we couldn't guarantee that this would continue to behave exactly the same way in future releases, etc.

It would of course be best if you could get us a reproducible case.
It seems odd that this would cause issues in your application -- the check will only suppress update if the user-entered string matches the currently stored date value (formatted to a string).

**acarur01** · 19 Oct 2011, 13:00

The only thing I could tell right now that is different between IE and Firefox is that this updateValue is called twice in both browsers BUT in FF, the first call has _4 as 10/29/2011 00 but the second time this function is called it reverts back to my original date value which was 10/19/2011 00

**acarur01** · 19 Oct 2011, 13:04

Maybe the call stacks would help...

The first callstack is:

updateValue()ISC_Fo...v=52446 (line 2489)
pickerDataChanged(_1=[DateChooser ID:isc_DateChooser_0] { ns={...}, _generated=true, autoHide=true, more...})ISC_Fo...v=52446 (line 2546)
anonymous()ISC_Co...v=52446 (line 64)
dateClick(_1=2011, _2=9, _3=29)ISC_Fo...v=52446 (line 144)
onclick(event=click clientX=980, clientY=292)onclick (line 2)

second is:

updateValue()ISC_Fo...v=52446 (line 2489)
changed()ISC_Fo...v=52446 (line 2451)
elementBlur()ISC_Fo...v=52446 (line 1584)
bubbleItemHandler(_1=[TextItem ID:isc_TextItem_0 name:dateTextField] { ns={...}, textAlign="left", title="Start Date ", more...}, _2="elementBlur", _3=undefined, _4=undefined, _5=undefined, _6=undefined)ISC_Fo...v=52446 (line 681)
elementBlur(_1=input#isc_3B.textItem, _2=[TextItem ID:isc_TextItem_0 name:dateTextField] { ns={...}, textAlign="left", title="Start Date ", more...})ISC_Fo...v=52446 (line 697)
$12x(_1=input#isc_3B.textItem, _2=[TextItem ID:isc_TextItem_0 name:dateTextField] { ns={...}, textAlign="left", title="Start Date ", more...})ISC_Fo...v=52446 (line 1569)
invokeSuper(_1=null, _2="$12x", _3=undefined, _4=undefined, _5=undefined, _6=undefined, _7=undefined, _8=undefined, _9=undefined, _10=undefined)ISC_Co...v=52446 (line 304)
Super(_1="$12x", _2=[input#isc_3B.textItem, [TextItem ID:isc_TextItem_0 name:dateTextField] { ns={...}, textAlign="left", title="Start Date ", more...}], _3=undefined)ISC_Co...v=52446 (line 296)
$12x(_1=input#isc_3B.textItem, _2=[TextItem ID:isc_TextItem_0 name:dateTextField] { ns={...}, textAlign="left", title="Start Date ", more...})ISC_Fo...v=52446 (line 1953)
$764(_1=input#isc_3B.textItem)ISC_Fo...v=52446 (line 828)
$12w()ISC_Fo...v=52446 (line 826)
focusInItem()ISC_Fo...v=52446 (line 1558)
focusInItem(_1=[SelectItem ID:page$content$detail$$content1$detailFrame$FormFrame$itemType name:page$content$detail$$content1$detailFrame$FormFrame$itemType] { ns={...}, eventParent=[DynamicForm ID:page$content$detail$$content1$detailFrame$FormFrame$GridLayout], containerWidget=[DynamicForm ID:page$content$detail$$content1$detailFrame$FormFrame$GridLayout], more...}, _2=undefined)ISC_Fo...v=52446 (line 641)
setFocus(_1=true)ISC_Fo...v=52446 (line 621)
focus(_1=undefined)ISC_Co...v=52446 (line 3060)
hideClickMask(_1="isc_DateChooser_0")ISC_Co...v=52446 (line 1809)
$lj(_1=Object { autoHide=true, mode="soft", ID="isc_DateChooser_0", more...})ISC_Co...v=52446 (line 1857)
checkMaskedFocus(_1=[DynamicForm ID:page$content$detail$$content1$detailFrame$FormFrame$GridLayout] { ns={...}, ID="page$content$detail$$co...me$FormFrame$GridLayout", name="GridLayout", more...})ISC_Co...v=52446 (line 1523)
_focusInCanvas(_1=[DynamicForm ID:page$content$detail$$content1$detailFrame$FormFrame$GridLayout] { ns={...}, ID="page$content$detail$$co...me$FormFrame$GridLayout", name="GridLayout", more...}, _2=undefined)ISC_Co...v=52446 (line 1514)
focusInCanvas(_1=[DynamicForm ID:page$content$detail$$content1$detailFrame$FormFrame$GridLayout] { ns={...}, ID="page$content$detail$$co...me$FormFrame$GridLayout", name="GridLayout", more...}, _2=undefined)ISC_Co...v=52446 (line 1513)
elementFocus(_1=input#isc_3B.textItem, _2=[TextItem ID:isc_TextItem_0 name:dateTextField] { ns={...}, textAlign="left", title="Start Date ", more...})ISC_Fo...v=52446 (line 695)
$12v(_1=input#isc_3B.textItem, _2=[TextItem ID:isc_TextItem_0 name:dateTextField] { ns={...}, textAlign="left", title="Start Date ", more...})ISC_Fo...v=52446 (line 1566)
invokeSuper(_1=null, _2="$12v", _3=undefined, _4=undefined, _5=undefined, _6=undefined, _7=undefined, _8=undefined, _9=undefined, _10=undefined)ISC_Co...v=52446 (line 304)
Super(_1="$12v", _2=[input#isc_3B.textItem, [TextItem ID:isc_TextItem_0 name:dateTextField] { ns={...}, textAlign="left", title="Start Date ", more...}], _3=undefined)ISC_Co...v=52446 (line 296)
$12v(_1=input#isc_3B.textItem, _2=[TextItem ID:isc_TextItem_0 name:dateTextField] { ns={...}, textAlign="left", title="Start Date ", more...})ISC_Fo...v=52446 (line 1980)
$763(_1=input#isc_3B.textItem)ISC_Fo...v=52446 (line 824)
$12u()ISC_Fo...v=52446 (line 821)
focusInItem()ISC_Fo...v=52446 (line 1558)
focusInItem()ISC_Fo...v=52446 (line 2515)
pickerDataChanged(_1=[DateChooser ID:isc_DateChooser_0] { ns={...}, _generated=true, autoHide=true, more...})ISC_Fo...v=52446 (line 2546)
anonymous()ISC_Co...v=52446 (line 64)
dateClick(_1=2011, _2=9, _3=29)ISC_Fo...v=52446 (line 144)
onclick(event=click clientX=980, clientY=292)onclick (line 2)

**Isomorphic** · 19 Oct 2011, 14:18

You haven't really told us what's going wrong - all you've said is:

...something has changed in the date item that has broken our logic in formatting/validating on blur.

The difference between Firefox and IE is likely ultimately due to the fact that natively IE fires 'onblur' / 'onfocus' notifications asynchronously, whereas in Firefox they're fired synchronously. We could spend time debugging exactly why this happens / whether it can be avoided and where the calls to the formatter / parser methods are coming from based on your stack trace but ultimately we don't know what we're looking for.
The fact that the formatter and parser methods fire more than once is not necessarily a bug of any sort. For example - if the user enters a date string, we will parse it to a date, then reformat it to a date-string to ensure that we normalize the format. The code we were discussing earlier in this thread also runs the formatter on whatever the currently stored date is to ensure that the user-entered value really does differ from the stored value. This is valid logic that can lead to the methods running more than once.

You have a breakage in your application of some sort. It could be due to some invalid application logic or to a framework bug.
The best way for us to figure out what the cause is would be to see it. The fact that its not reproducible in a simple standalone test case may imply that some seemingly unrelated part of your application code is having an effect on these items. The process of paring the application code down to a simple test case may actually reveal exactly what the problem is.

If it's really unreproducible outside of your application, at least describe exactly what the problem is as clearly as possible, as well as showing us essentially what components are involved with code snippets, etc.

**acarur01** · 19 Oct 2011, 15:07

I will extract exactly what we are doing into a standalone but in the meantime, the problem is that when I have a default value on a date field and I for the first time click on the date picker and select a new date, it does not change the value displayed on the text field. Instead, it still shows the default value. Another testcase is our custom validation not firing. Our validation is usually fired on blur. So if for the first time the date field is loaded, and there is a default value, I change the string so that instead of 11/11/2001 00 it reads 11/11/200, then I click outside of that date field into another field, we look at the value of the text field and validate against the format and if it is invalid, we show the error icon.

Announcement

Date Item broken

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment