Ok. Independent from language. The new IUP Tutorial is a good starting point, what's online already has more pages than the download version.
Best, Scuri On Tue, Aug 11, 2015 at 9:04 AM, "Jörg F. Wittenberger" < joerg.wittenber...@softeyes.net> wrote: > Am 10.08.2015 um 19:20 schrieb Antonio Scuri: > > Well, I really don't know. > > > > Just know that the calls are not actually "active all at the same > time". > > When you call IupFlush in one of them, it will stop that one, processes > the > > pending messages one by one, then return to that one. If that can occur > > recursively then it is a real nightmare to manage. You will have a hard > > time to know what is the order that things are happening. > > Ah' I see. > > Maybe it's a good idea to add a remark pointing this out in the manual. > Me, reading the manual, gathered that calling IupFlush would never > hurt, just advance the processing at the Iup side of things. > > > I would recommend you to get a step back are rethink that strategy. > > So far this never became a strategy. It failed straight in the first > experiment. It's just my missunderstanding of the docs and an experiment. > > > Independent from IUP, or other toolkits, what you are trying to > implement? > > There is a very simple RDF/DublinCore inspired inventory application for > a small archive (archive of physical things, kind of a museum - not the > family of file formats). I'm using it as "personal wiki" for my notes too. > > The original is a web app. I'm trying replace the Web-Interface with a > native GUI. > > /Jörg > > > > Best, > > Scuri > > > > > > On Sat, Aug 8, 2015 at 9:58 AM, "Jörg F. Wittenberger" < > > joerg.wittenber...@softeyes.net> wrote: > > > >> ((Sorry, this is not exactly the message I want to reply to, but at > >> least it's the correct thread. (The other message is already gone > here.))) > >> > >> I managed to understand the problem a little better. > >> > >> Maybe I'm dong something against the philosophy of correct Iup usage > here? > >> > >> What's happened is that the action callback from my apps back-button is > >> called as often as I click it. Eventually my action callback will also > >> call IupFlush. (Is this a No-No?) This IupFlush in turn enables the > >> next action callback to be activated. Thus there are 4-5 calls active > >> at the same time. > >> > >> Each of those calls does essentially the same: recreate scrollbox full > >> of controls (from different data sets). Then detach the (only) child of > >> the target container, IupDestroy that detached child, IupAppend the new > >> one and IupRefresh the container. > >> > >> Since the data set is different, those action callback take a different > >> amount of time (while waiting for the data base etc.). > >> > >> By throwing in some additional calls to IupFlush into the code (I'd > >> believe this _should_ not hurt, shouldn't it?) I've been able to get it > >> all mixed up. Up to the point that controls belonging to different data > >> sets / callbacks ended up mixed into the same container. > >> > >> To put it in other words: those nested action callbacks in combination > >> with IupFlush enabled me to (accidentally) implement a kind of green > >> threads on top of Iup. Unfortunately without proper locking. > >> > >> Having too few IupFlush's there will result in the segfault. More > >> flushes make it appear to work. Even more flushes confuse the layout > >> logic. > >> > >> How should this being done right? > >> > >> Thanks > >> > >> /Jörg > >> > >> Am 05.08.2015 um 10:50 schrieb "Jörg F. Wittenberger": > >>> Hi Antonio, > >>> > >>> during IupFlush my program dumped a core like this: > >>> > >>> Program terminated with signal SIGSEGV, Segmentation fault. > >>> #0 0x4097693a in gtkCanvasSetDXAttrib.part.3 () from > >>> /usr/local/lib/libiup.so > >>> (gdb) bt > >>> #0 0x4097693a in gtkCanvasSetDXAttrib.part.3 () from > >>> /usr/local/lib/libiup.so > >>> #1 0x00000000 in ?? () > >>> > >>> > >>> Anything I can do to help debugging that one? > >>> > >>> Best > >>> > >>> /Jörg > >> > >> > >> > >> > ------------------------------------------------------------------------------ > >> _______________________________________________ > >> 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 > >
------------------------------------------------------------------------------
_______________________________________________ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
