Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"change" event fired too much on VirtualSelectBox #9071

Closed
woprandi opened this issue Jun 27, 2016 · 11 comments
Closed

"change" event fired too much on VirtualSelectBox #9071

woprandi opened this issue Jun 27, 2016 · 11 comments
Labels
bug Errors
Milestone

Comments

@woprandi
Copy link
Contributor

Hi,

Check this example : http://tinyurl.com/hjol7rx
The event "change" is fired 3 times instead of once

@zaucker
Copy link
Member

zaucker commented Jun 27, 2016

The three change events happen upon the call to setModel(). Once all is
setup, there is only on event per selection change.

If you add the listener after the setModel() call, the three initial events
are ignored (obviously).

I guess the setModel() generates an event for each element added to the
model. I am not sure if this is useful or not or a bug.

On Mon, 27 Jun 2016, William Oprandi wrote:

Check this example : http://tinyurl.com/hjol7rx
The event "change" is fired 3 times instead of once

Oetiker+Partner AG tel: +41 62 775 9903 (direct)
Fritz Zaucker +41 62 775 9900 (switch board)
Aarweg 15 +41 79 675 0630 (mobile)
CH-4600 Olten fax: +41 62 775 9905
Schweiz web: www.oetiker.ch

@slachtar
Copy link
Contributor

I did a lot of hacking to avoid such problem (event being generated with
every element in the model).
The change event should be generated only once.

On Mon, Jun 27, 2016 at 4:19 PM, Fritz Zaucker notifications@github.com
wrote:

The three change events happen upon the call to setModel(). Once all is
setup, there is only on event per selection change.

If you add the listener after the setModel() call, the three initial events
are ignored (obviously).

I guess the setModel() generates an event for each element added to the
model. I am not sure if this is useful or not or a bug.

On Mon, 27 Jun 2016, William Oprandi wrote:

Check this example : http://tinyurl.com/hjol7rx
The event "change" is fired 3 times instead of once

Oetiker+Partner AG tel: +41 62 775 9903 (direct)
Fritz Zaucker +41 62 775 9900 (switch board)
Aarweg 15 +41 79 675 0630 (mobile)
CH-4600 Olten fax: +41 62 775 9905
Schweiz web: www.oetiker.ch


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#9071 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ACaj6iHJY0odlnJkEmV0OaezWfdpLC6kks5qP-oUgaJpZM4I_MkA
.

Slah Lachtar
Tel. (+216) 98 221 575

@woprandi
Copy link
Contributor Author

@zaucker Yeah I could do that but it's not very conceivable since I need a fired event for the default selection.

@johnspackman
Copy link
Member

IMHO this is a bug because the selection property is a qx.data.Array (according to the API docs anyway), and yet the first two change events which are fired do not confirm to the specs for qx.data.Array's change event. For example, in this slightly modified version of Williams example http://tinyurl.com/gpow5tg the log output shows that the event's Data property is empty:

324314 qx.application.Standalone[510-0]: selection changed: {}
2621370 qx.application.Standalone[510-0]: selection changed: {}
2623352 qx.application.Standalone[510-0]: selection changed: {"start":0,"end":0,"type":"remove","removed":[{"$$hash":"760-0","__bb":"760-0","$$initialized":true,"$$user_label":"a"}],"added":[]}

@johnspackman johnspackman added the bug Errors label Jun 28, 2016
@johnspackman
Copy link
Member

johnspackman commented Jun 28, 2016

it looks like this is fixed in the current master - prior to 43d7e91 the VirtualDropDown was firing the events manually

EDIT @woprandi please can you retest on master and let us know how you get on?

@woprandi
Copy link
Contributor Author

@johnspackman Looks nice, but I can't find the master playground URL to check

@johnspackman
Copy link
Member

I'd forgotten that there is one, cajus set one up on http://qooxdoo.github.io/devel/playground

I've just checked though with http://tinyurl.com/hm7p8qa and while it's an improvement it's still wrong. Here's the output:

021947 qx.application.Standalone[493-0]: selection changed: {"start":0,"end":1,"type":"add","added":[{"$$hash":"636-0","__bR":"636-0","$$initialized":true,"$$user_label":"a"}],"removed":[]}
021950 qx.application.Standalone[493-0]: selection changed: {"start":0,"end":1,"type":"add","added":[{"$$hash":"636-0","__bR":"636-0","$$initialized":true,"$$user_label":"a"}],"removed":[]}
021950 qx.application.Standalone[493-0]: selection changed: {"start":0,"end":0,"type":"remove","removed":[{"$$hash":"636-0","__bR":"636-0","$$initialized":true,"$$user_label":"a"}],"added":[]}

it shows that "a" was added twice and then removed, when there should be one added for "a" and that's it.

@woprandi
Copy link
Contributor Author

Strange, I applied the patch for my app and event fires only once now.

@johnspackman
Copy link
Member

I found that sample app triggers the problem on master

@woprandi
Copy link
Contributor Author

Thanks for your help

level420 added a commit that referenced this issue Jul 1, 2016
…ction-event

This fixes issue #9071 where events are fired incorrectly during startup
@level420
Copy link
Member

level420 commented Jul 1, 2016

Fixed with 3bc6ebe

@level420 level420 closed this as completed Jul 1, 2016
@johnspackman johnspackman added this to the release_5_0_2 milestone Jul 6, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Errors
Projects
None yet
Development

No branches or pull requests

5 participants