Sorry for following up on my own message. I just considered the problem again and got stuck.
Am 11.08.2015 um 14:04 schrieb "Jörg F. Wittenberger": > 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 I don't really see. So when exactly SHOULD I call IupFlush? Which one is the strategy natural to Iup. Changing the app side of things is simple. There is not so much to change by now. I'm still exploring/learning the toolkit. So far the first strategy I tried was to simply run IupMainLoop and call Iup functions from the callbacks. This did work as long as there Iup was the only source of events to be considered. But there is some i/o going on (database connections etc.). So I switched to the next strategy : 2nd: In a loop 1. Call all Iup* things to build the GUI as app logic suggests at this point in time. 2. Call IupFlush. (Former version: call IupLoopStep and IupFlush if that does not return IUP_CLOSE, but that seemed to add no value over just IupFlush.) 3. Poll other I/O for a moment. Goto 1 processing the results. This did work most of the time, but sometimes it would just not result in updates as expected. Turned out some calls (I don't recall which one it where) would executed in (1.) call callbacks again. (I recall having read about this in the docs, so no surprise here so far.) At this point I had to do wild guess work how I should handle this. Option A: Record the callbacks job to be execute later and return immediately. Option B: Execute the Job right now. The former resulted eventually in the segfaults during IupFlush in step (2). To I settled so far on Option B. But this required me to Call IupFlush also in the recursive invocation. So, to repeat myself: which strategy is natural to Iup? When must I call IupFlush? As I'm reading your reply, I'd understand that calling IupFlush from withing callbacks is no good idea, correct? If so: how would I make those changes take effect? Because: if I call "too many" (whatever that is _I_ have no way to know) Iup* things (e.g. IupDestroy) from within a single callback, then I get the segfault. Thanks so much /Jörg > > 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
