| | [ Return to Bugs & Features | Roadmap 1.1 | SVN ⇄ GIT ]
STR #1494
| Application: | FLTK Library |
|---|
| Status: | 1 - Closed w/Resolution |
|---|
| Priority: | 4 - High, e.g. key functionality not working |
|---|
| Scope: | 3 - Applies to all machines and operating systems |
|---|
| Subsystem: | Core Library |
|---|
| Summary: | Buttons in menubars get "clicked" when dismissing a menu |
|---|
| Version: | 1.1-current |
|---|
| Created By: | ianmacarthur |
|---|
| Assigned To: | matt |
|---|
| Fix Version: | 1.1-current (SVN: v5605) |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
No files
Trouble Report Comments:
| |
| #1 | ianmacarthur
09:13 Nov 11, 2006 |
| Observed with revision 5539 on linux and OSX.
To see the error, run the menubar demo, click on the "File" memubar item, then run along the menubar until the last item "button" is selcted.
Now click "somewhere else" to dismiss the menu - the checkbox "button" changes state.
I had expected that clicking outside the menu button would dismiss it with no change of state, so the observed behaviour is unexpected, and I'd think potentially hazardous, since it seems it could action something the user was specifically trying to cancel...
--
Ian | |
| |
| #2 | mike
12:49 Nov 11, 2006 |
| I'll see what we can do about this, but I suspect the problem has been in the menu code since v1.0. | |
| |
| #3 | ianmacarthur
13:00 Nov 11, 2006 |
| Yes - I had never noticed it before, but I was doing some specific tests today and saw this.
I guess it has been there forever, so if no one noticed before, it probably does not matter... Still. I'd hazard that it is "technically" wrong :-) | |
| |
| #4 | danh
09:13 Jan 04, 2007 |
| Actually, this works in 1.1.6. And it's pretty annoying, as most 'File' menu's have Exit is the last (and easiest to accidentally trigger) option.
It has something to do with the changes in FL_Menu.cxx, after line 589... in 'case FL_DRAG:'. I replaced that logic with code from 1.1.6, and the problem went away. | |
| |
| #5 | matt
17:20 Jan 09, 2007 |
| Actually, danh, this is only true if the last button is a check box on the menu bar. Personally, I think that a check button on the main menu bar is a very silly idea to begin with, because it can be replaced with a shorter manu bar and a seperate check button, which makes the function of the button a lot more obvious. I'd prefer the disable this feature alltogether, but don't feel a desperate need to change old code.
Maybe we should simply remove this button from the demo? | |
| |
| #6 | mike
17:59 Jan 09, 2007 |
| +1 on removing the check box in the menu bar. | |
| |
| #7 | ianmacarthur
11:14 Jan 10, 2007 |
| Removing the button works for me... +1
Alternately, if we really feel the need to demonstrate the option of having a check-box on the menu-bar to end-users, I suppose moving it "not-last" place would work, and "mask" the bug! But do not think that is a good idea... | |
| |
| #8 | spitzak
00:16 Jan 11, 2007 |
| Does not draw the button correctly anyway, it draws it with sunken squares. It probably should have a checkmark.
Plain items work as momentary buttons, which is on purpose, as this allows the menubar to be a "toolbar" as well. I changed the demo to show this more clearly.
However leave the bug open, as the fact that the checkmark does not work is a minor bug. | |
| |
| #9 | matt
01:31 Jan 18, 2007 |
| Fixed in Subversion repository.
I believe I fixed this well by making top-menu button-style entries behave more like a regular button: when the mouse leaves the field, the highlighting goes away, so dismissing all menus by clicking somewhere will not trigger the menu item. Please verify. | |
[ Return to Bugs & Features ]
|
| |
