Thanks for your reply. It was very helpful and I will take that approach. Matt On Mon, Oct 29, 2018 at 3:58 PM Antonio Scuri <antonio.sc...@gmail.com> wrote: > > Hi, > > Childtype is the best way, but there are some issues. As you can see some > containers have more children than specified, because they are internal > controls. Unfortunately there is no way how to know if a class has internal > controls without actually create the container. We still need to add that > support. > > Meanwhile you can check if it is one of these containers: detachbox, > expander, flatscrollbox, sbox, spin, split. They are the only containers that > have internal controls. Split can have two children, and all the others can > have only one. > > Actually, I just check, you can safely assume that any class that has > childtype > IUP_CHILDMANY, can contain only 1 possible regular child. The > other children are internal. With the exception of IupSplit that can have 2 > regular children. > > Best, > Scuri > > > > Em seg, 29 de out de 2018 às 14:18, Matthew Kennedy <burnsid...@gmail.com> > escreveu: >> >> Hello, >> >> While creating a programmatic language binding for IUP using the >> Internal SDK, I ran into a case where some containers include a canvas >> as part of the Iclass childcount. I was hoping to use childtype as a >> way to determine whether the language binding should accept a single >> child, list of children or some fixed number of children as argument >> lists, but I'll be off-by-one in some cases where IUP provides a >> canvas. >> >> e.g. in C: >> >> Ihandle* IupSbox(Ihandle* child); >> >> i.e. 1 child >> >> But childtype = IUP_CHILDMANY+2; /* canvas+child */ >> >> i.e. 2 children >> >> I can special-case these, but I was looking for a more robust way for >> the programmatic language binding. Is there some other way to deduce >> the maximum number of "user-provided" children? I had started looking >> into Iclass's format field (used by LED, it seems)... Is that my best >> bet? >> >> Thanks, >> >> Matt >> >> >> _______________________________________________ >> Iup-users mailing list >> Iup-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/iup-users > > _______________________________________________ > Iup-users mailing list > Iup-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/iup-users
_______________________________________________ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
