History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: LPP-5292
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: -- --
Assignee: André Bargull
Reporter: Henry Minsky
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
OpenLaszlo

LzInputText updateData method can get stale data

Created: 18/Dec/07 10:17 PM   Updated: 13/Jan/08 03:42 PM
Component/s: LFC - Data, LFC - Text
Affects Version/s: RingDing (4.1)
Fix Version/s: RingDing (4.1)

Time Tracking:
Not Specified

Severity: Minor
Fixed in branch: trunk
Runtime: N/A
Fix in hand: False


 Description  « Hide
A user reported this bug:
I think I have found a decent sized bug in version 4.0.7. All over our application we use databound inputtext but in the newest version it appears that this is no longer supported. If you look at the example below, change the text of the inputtext and then click to the edittext and look at ds in the debugger you see that the dataset doesnt update. The edittext works perfectly but has the border which is not desirable in our UI. Is this a feature of the inputtext that has been removed in this version or is this a bug?
 
<canvas width="100%" height="100%">
 
<dataset name="ds">
 <stuff edit="default edit" input="default input"/>
</dataset>
 
<simplelayout axis="x" spacing="20"/>
 
<inputtext datapath="ds:/stuff" text="$path{'@input'}">
    <method event="onblur">
        this.datapath.updateData();
    </method>
</inputtext>
<edittext datapath="ds:/stuff" text="$path{'@edit'}">
    <method event="onblur">
         this.datapath.updateData();
    </method>
</edittext>
 

</canvas>


==========================================================


 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
Henry Minsky - 18/Dec/07 10:19 PM
The test case as written is not quite right I think. For the inputtext view, the datapath ought to be fully specified as ' datapath="ds:/stuff/@input" ' , otherwise
I don't see how updateData would know where to put the data back into the dataset.

however, there is a real bug in LzInputText.updateData. it is defined as

function updateData (){
    return this.sprite.text;
}

But I don't think there is anything automatically updating the sprite.text attribute.

A workaround for the test case is

<inputtext datapath="ds:/stuff/@input" text=" $path{'@input'}" >
  <method name="updateData">
    this.setText( this.getText() );
    return this.text;
  </method>


    <method event="onblur">
      this.datapath.updateData();
    </method>
</inputtext>


So the fix would probably be to define this as the updateData method for LzInputText in the LFC



Henry Minsky - 18/Dec/07 10:21 PM
I don't understand why the test case works in the second case, on the edittext component; how does it know to place the data back into the "edit" attribute
of the dataset? Is it just because the datapointer happens to be left pointing there via the last $path reference that was executed??


André Bargull - 19/Dec/07 07:02 AM
I've also found the "LzInputText#updateData()"-bug when I was working on LPP-4747, basically you should never directly work on "LzTextSprite#text" whenever your attempt to use code for LzTextSprite and for LzInputTextSprite (, because the "text"-field won't ever be updated for LzInputTextSprite).
So, you don't need to address that issue when you're working on this bug.
(Maybe I'll send today a patch for LPP-4747 out for review, but I don't know when I'll be back from university.)

André Bargull - 13/Jan/08 03:41 PM
> I don't understand why the test case works in the second case, on the edittext component;
> how does it know to place the data back into the "edit" attribute of the dataset?
> Is it just because the datapointer happens to be left pointing there via the last $path reference that was executed??

"LzDatapath#updateData(..)" calls updateData for all dependent children -> that's also the LzDataAttrBind "$path{'@edit'}"

André Bargull - 13/Jan/08 03:42 PM
fixed in changeset for LPP-4747.