> OK, First of all, I assume that all the things you observe here are not true > for the regular FLTK pulldown menus? i.e. does clicking on the decoration of > the main menu correctly dismiss the popup?
You are assuming correctly. I have checked the menubar example thoroughly and it worked like a charm. > The Menu stuff is filled with workarounds to make it resemble the original > Forms behavior as much as possible. I would love to provide a popup window > that behaves as you need it, but especially the missing PUSH event makes > Fl_Button implementations somewhat useless in the popup window, assuming you > need the click-popup-drag-release functionality. > Click-popup-release-click-release should always work. > >> The only way to make sure that they are highlighted appropriately while >> hovering is to use a loop: for all children: child(i)->handle(FL_LEAVE) >> in the popup window handle before sending the actual event to the >> children. While this is a work-around it does not seem to be a >> particularly pretty one. > >> 2) Tooltips are only shown from the menu-button not from the >> Fl_Active_Button inside the popup. Oddly enough, the tooltips are not >> shown with 1.3.x but the text of the menu-button tooltip is shown for >> the Fl_Active_Buttons in 1.1.9 (maybe because of grab?). >> 3) FL_PUSH does not get routed to buttons > > All the above are likely due to a missing fake FL_RELEASE which should be > sent to the original menu button, followed by another fake FL_PUSH into the > just popped up window. I doubt that I have time today, but maybe I can write > that code on the weekend. I have been working some more on the derived menu popup, unfortunately with very little real success. According to your suggestion I have added a fake FL_RELEASE and FL_PUSH right before the grab-call (as a timeout(0)). It did not have any effect. I have found some kind of a work-around so that the popup hides in most cases when clicking on the decorations but I fear this is quite Linux specific: the window seems to receive a FL_MOVE event (after click-drag or click-release) and you can then test if the event_root coordinates are outside the client area of the main window. It is however not very reliable and does not seem to be how the fltk-popup menus work. >> 4) Even though the popup window is modal I seem to be able to move the >> main window while the popup window is shown! That looks rather odd and >> is not a desired behavior, I'm sure. > > Yes, this is a huge issue which I believe was solved. I'd have to dig deeper > into Menu code to find out what we did. Essentially, a click onto the > decoration is not sent to the application itself, so the popup menu does not > know when to dismiss. Again, I beleive we solved that, but I have to check. > >> 5) When you click on the window decorations of the main window the popup >> should disappear - but does not (e.g. system menu) or X, or they should >> not be accessible at all. > > Same. I have been reading a lot through the internal library code, I guess you are referring to Fl_Menu.cxx menuwindow::handle and menuwindow::early_hide_handle? I couldn't find any particular magic, which checked for events outside the client area. I don't think that code will get any more events than what I posted yesterday. The menu-code, with all its states, is indeed not quite easy to follow. Maybe you could give me a hint or three how it all fits together or which additional code/files also contribute to the behavior? Thanks, Herman _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
