> Paul R wrote: > >>> if the pointer has moved to > >>> allocate another button, how is the old one accessed? > > >> It is accessed via the callback, which is passed a pointer to the > >> object. So although you have no "name" that references that button, you > >> can still access it from within the callback, as shown in the example. > > Right, what he said ;) > > It's unlikely your code will need access to the individual buttons > other than when the callback is invoked. > > And since the button passes itself to the callback whenever it's > clicked, > that may be all you'll ever need. > > However, if you want to do things to all the buttons that involves > accessing each one, then you might want to keep a pointer to all > of them in an array. > > Note that if you delete the top level widget (in this case, the window), > that will deallocate all the buttons automatically. So you do not need > to worry about keeping a pointer to all the buttons for deallocation; > zapping the top level widget will do that for you. > > Note too you can do things like deactivate all the buttons by > deactivating the parent widget. So if the parent is an Fl_Group > (or Fl_Tile), you can deactivate that, and everything in it will > automatically deactivate as well. Ditto for hide()/show(). >
thanks for all the advice all, am really making progress now, and as a bonus am learning to use more advanced code constructs of neccesity and certainly learning about class composition and inheritance! so my general knowledge repetoire is growing also. the 'wheres the button name' thing clicked just after sending last reply the memory is still allocated with a callback attached to it and in the callback function you dereference(?) it with the cast or function object argument. Then of course you can do what you like. I think that an array is probably going to be best as i will need to be able to index buttons that have already been selected by the user in case they want to deselect one and change their choice. Also the tile was the wrong choice as i don't need the buttons to be resizable in that sense, dragging gridlines around etc. unless this can be disabled for the tile? i need to check member functions. i built and ran the 'copy and paste' buttons version using fluid and everything was fine as a demo run, but like i say i think will need more hand coding with the array version. Also any advice on my use of inheritance, its just that the new window 'MapData' with the number pad and other buttons inherits from DataGenerator which inherits from MainWindow (fluid class). So when i create a new instance of mapWin i also get a new mainWin, right now i am just deleting it in the mapWin constructor, would it be possible to make the mainWin static? and thus avoid this? or should i move my MapData class within DataGenerator? or just not worry about it? _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
