Hi Jim,
Glad to see a response and that someone is aware. I thought my emails
were being ignored :) Just kidding... I know everyone is working hard.
Anyway, I agree with you. My objective is to know exactly what value
to commit to the model, which I thought ought to be the last value
set in the slider after the mouse up event.
Now, going into the agent changing the value during the drag issue.
This is an interesting problem I didn't think of. However, from a
simplistic point of view, the physical user interaction should
override any agent process. The problem I see that you may referring
to is (please correct me if my assumption is wrong): say there is a
new event called "oncommitvalue" attached to "commitvalue" attribute.
If the model is set to commit changes based on the oncommitvalue
event, you basically end up sending two requests to the model. One
for the agent sending the event, and the other upon the completion of
the drag. My suggestion would be such that the dragstate would
"disable" or "swallow" oncommitvalue events so that any agent process
will continue to operate, but just simply be ignored until the drag
ends, and when the drag ends, the actual dragstate will fire off the
oncommitvalue event.
Overall, it definitely sounds as if this is a slightly more complex
problem that what I initially though of. Unfortunately, I do need an
immediate solution, which is very unlikely to happen, so I'll
probably end up using an alternative solution to my problem until a
more permanent fix is in place for the slider.
If I come up with a short-term fix, I'll gladly share it. One thing I
thought could be done, but didn't work is as follows:
<slider>
<method event="onmouseup" reference="thumb">
<!-- get the slider's value and do whatever -->
</method>
</slider>
Since <slider> contains an object called track which in turns
contains an object called thumb, we could hook the event to the
thumb's onmouseup event. I tried using reference="track.thumb" which
didn't work either. Anyway of making these work? Am I too off in this
suggestion?
Thanks again,
Daniel
On May 24, 2006, at 1:48 PM, Jim Grandy wrote:
> Hi Daniel,
>
> You at least are the third person to ask about this in the last
> week. I haven't answered since the first exchange because I think
> there's a slightly bigger change proposal to be made here, and I
> keep expecting to have time to write it up :-)
>
> The more generic problem to be solved (in my opinion) is that we
> need a way of telling when a new value should be committed back to
> the model. I think this is broadly what you and others have been
> asking for, because sometimes it is too expensive or inappropriate
> to signal a value change during this sort of live interaction.
>
> To do this properly, though, you want to be a bit careful --
> another agent might change the value during a drag, for example.
> Then there's validation, which haven't really been tightly
> integrated into the components yet but should be.
>
> Anyway, probably all too broadly scoped for your immediate need.
> What we should do in the near term is figure out a "best practices"
> recommendation for this problem and then step back and look at the
> bigger design issues later.
>
> I'll do some thinking about the best short-term approach, and if
> anyone else has recommendation, please speak up.
>
> jim
>
> On May 24, 2006, at 8:02 AM, Daniel Salama wrote:
>
>> Hello,
>>
>> I'm using a slider component and I would like to capture the value of
>> the slider after the mouse button has been released. Is it possible?
>>
>> I added something like this:
>>
>> <slider>
>> <method event="onvalue" args="v">
>> Debug.write("Value ",v);
>> </method>
>> </slider>
>>
>> The problem with this is that the event is called constantly while
>> the mouse button is down and moving the slider. I'm only interested
>> in capturing the last value of the slider after the mouse button has
>> been released.
>>
>> I also tried capturing the onmouseup event but that doesn't seem to
>> be triggered.
>>
>> Help please.
>>
>> Thanks,
>> Daniel
>> _______________________________________________
>> Laszlo-user mailing list
>> [email protected]
>> http://www.openlaszlo.org/mailman/listinfo/laszlo-user
>
_______________________________________________
Laszlo-user mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-user
