Hi Patrick,
On Mon, Aug 31, 2015 at 08:22:50AM -0400, Patrick wrote:
I am fine right now with just 1 form and several groups but I was
curious as to the best way build widget "assemblies" and nest them.
Groups can't be nested but the guide refers to having multiple
forms. Is it good practice to nest forms? Is so do we really need
groups?
I'm not sure what you're up to;-) But I suspect that you
want to create some kind of widget that combines a number
of objects. There are some like that, for example the
browser, which is an object that embeds a "text box" and
two scrollbars (and the scrollbars are themselves such
"combined objects, build from a slider and two "scroll-
bar buttons"). If that's what you intend to create here
a few hints of how it's handled (otherwise skip the
next paragraph).
The FL_OBJECT structure has a field called 'spec', a void
pointer. For a new class of object you design you use that
to store a pointer to some structure of your own definition,
which holds state information for that object. And this may
very well include further objects. Of course, for a new class
of object you will have to write quite a bit of code to manage
the object. For the "child" objects you typically set call-
backs that are functions of the parent object, which then
decides what is to be done (e.g. with the browser the call-
backs of the scrollbars are set to a function in the parent
browser object, that then tells the "text box" object which
part of the text to display according to the new scrollbar
position). It may be a bit of a steep learning curve, sorry.
If you go that way please feel free to ask as many questions
as necessary - perhaps it will lead to a better documentation
of this somewhat obscure corner;-) If you want to look at some
examples here's a list of all widgets that are such "combined"
objects (from memory):
a) browser
b) scrollbar
c) spinner
The code for the scrollbar and the spinner are probably
simpler to get started with.
Groups have (as you probably already have read) two purposes,
one is visual (so you can hide a set of objects at once, and
they also play a role in resizing). The other are to be able
to set which radio buttons belong together. In hindsight it
probably wasn't too good an idea to use them for such un-
related purposes, and allowing to nest them may also have
been preferable. But then XForms goes back a long time
(about 25 years) when expectations at GUIs were still
rather limited;-)
Forms nearly always have their own window and while it's
possible to nest them (see e.g. the tabfolder and form-
browser object) I consider this to be rather "hackish".
But that, of course, shouldn't keep you from experimen-
ting with that if you feel it might suit your porpose!
Best regards, Jens