search

fritzing / fritzing-app

Fritzing desktop application
http://fritzing.org
Other
3.97k stars 826 forks source link

Changing a part's properties very fast causes copies of the part #1431

Closed davidperrenoud closed 1 year ago

davidperrenoud commented 10 years ago

From andre.knoerig@gmail.com on April 21, 2011 06:18:59

What steps will reproduce the problem? 1. Place a part (e.g., a transistor)

  1. Move your mouse cursor over a property that uses the swap mechanism (e.g. 'package').
  2. Use the mousewheel, scrolling up and down fast. What is the expected output? What do you see instead? The part gets copied multiple times (on top of one another). It seems like the swapping mechanism isn't catching up.

This is nasty if you're doing that in a breadboard and not noticing the copy. It will be quite confusing.

Original issue: http://code.google.com/p/fritzing/issues/detail?id=1431

davidperrenoud commented 10 years ago

From irasc...@gmail.com on June 29, 2011 08:48:14

This issue opens up a can of worms. The problem is that when you use the mouse wheel to scroll through the combobox choices, each intermediary result triggers a "combo box changed" event, so when you move the mouse wheel very quickly all those events pile up, with unpredictable results.

The optimal solution would be to change the combobox so that the signals didn't pile up. Additionally, it would be good to block new swaps while a swap is currently taking place.

However, there are a bunch of different combobox classes used all over the place, so at least for the moment I have bottlenecked the problem at the other end: when a combo box changed event tied to the swap function occurs, I set a timer, and if another event comes along within that time, the timer is restarted (the earlier event being essentially discarded).

Another approach would be to disable the mouse wheel for these widgets...

Status: PartlyDone

davidperrenoud commented 10 years ago

From irasc...@gmail.com on June 29, 2011 09:39:17

the base combobox class would subscribe to its own change events, using a timer as above, then only on timeout would it emit external change signals. All classes using current combo boxes would connect to this new set of signals instead of the original set. For extra credit, the base combo box class could detect whether the change was due to a mouse wheel event, and if not could emit events directly with no delay.

Labels: Component-Code

davidperrenoud commented 10 years ago

From irasc...@gmail.com on February 03, 2012 05:19:37

Issue 1820 has been merged into this issue.

davidperrenoud commented 10 years ago

From irasc...@gmail.com on February 04, 2012 01:07:00

Labels: Milestone-0.7.1

davidperrenoud commented 10 years ago

From irasc...@gmail.com on February 04, 2012 13:24:11

r5839 . restored swaptimer.

failiz commented 3 years ago

This is still an issue. I can observe this behaviour with transistors and potentiometers. I would disable the wheel. It does not take to much time to select from a combo box and this behaviour is quite prone to errors. The wheel scrolling moves the view of the inspector up and down. And if the mouse is suddenly over a combo box, the next scroll changes its value. And this can happen without the user noticing it.

failiz commented 2 years ago

@KjellMorgenstern , should we disable wheel events to change properties in the comboboxes?

This issue looks that can be fixed by increasing the timer from 30 to 200 (with 100ms I was still getting duplicated parts). However, I think that updating properties unintentionally can happen when scrolling through the inspector pane. Thus, I am more inclined towards deactivating the wheel scrolling to change properties.

Another solution would be to change the focus policy. So a combobox needs to be pressed in order to scroll with the wheel of the mouse. However, I tried that and it does not work (without adding other code) as when the property changes with the first wheel movement, the combobox looses focus again.

failiz commented 1 year ago

I think this has been fixed in 1.0.0

KjellMorgenstern commented 1 year ago

We disabled the wheel input on comboboxes in the inspector to avoid accidental changes. Plus, we fixed the combination of timers that was used to trigger the part change.

It was reliably reproducible when switching (by pressing a key or a mousewheel) parts slower than 30ms, but faster than 130ms. User would not often do this, but certainly this happened.

So even if you trigger switching parts by other means, the switch will now happen more instant, and will not "forget" to delete the previous part.