Thanks Ian and Roman for your remarks. Here I give you more details about what I'm trying to do: I'm developing a graphic editor to edit already existent proprietary-format forms (GUIs). Those forms usually contain block diagrams using hundreds of rectangles, lines and polygons, that sometimes act as buttons. It's common to have overlapping objects, as in the following diagram in which there are two small boxes (2 and 3) over a big background box (1).
+----------------------------+ | 1 | | | | +---------+ +---------+ | | | 2 | | 3 | | | | | | | | | +---------+ +---------+ | | | +----------------------------+ The "z-axis position" is given by the order in which an object is defined in the file (same phylosophy as FLTK) It would be desirable that the editor could provide the function "send to background / foreground" so that the user could create or add objects in any order, and then adjust wich one is in background/foreground. The only way I know to change the z-axis order in FLTK when the objects are already created is to destroy them and then recreate them in the desired order. Somebody has a better solution? Regards David. > David Lopez wrote: > > Hi everybody. > > > > How can I handle FL_PUSH events when there are several overlapped widgets? > > Do I need to handle the event in the container (e.g. Fl_Window) and > > traverse the child list, checking the coordinates, or there is any better > > way to do it? > > Is there any way to send a widget "background/foreground" so one of the > > overlapped widgets can receive the FL_PUSH event? > > Normally it is recommended not to have overlapping widgets, however if > you are careful you can have them overlapping too (I am guilty here > too), although you might need to override some handle/draw methods. You > have to have in mind that: > > 1) The widgets are drawn with the order within the parent group array - > so arrange them that way or create the top widgets *after* the bottom ones. > > 2) The widgets send events in reversed order (unfortunately with > exception of FL_FOCUS) which is consistent with (1) so that top widgets > get the event first. But if the widget is not interested in the event, > the event can be sent to the background widget later. In your case to > avoid sending FL_PUSH event to the background one for invisible part > assure that the handle() of your top widget always returns 1 if the > click is *inside* the top widget. > > 3) You have to assure that if the background widget needs redraw, you > should call redraw() also for top widget. The easiest way is (when > necessary) to call redraw() on parent group encapsulating all the widgets > > R. > > _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
