Ok. Now I see. IupFlush is usually used when you need to processes messages after changing elements attributes that need to be updated by the system.
I would recommend using IupMainLoop and something else for the database connections, not the way around using IupFlush. There are several ways how to pool secondary systems: - Use a second thread to processes it (frequently used) - Use a IupTimer to check from time to time if there is something to be processed on it (limited by a minimum time interval for not too fast processing) - Use the IDLE callback to process it (high CPU use since it will be running all the time) Best, Scuri On Tue, Aug 11, 2015 at 10:11 AM, "Jörg F. Wittenberger" < joerg.wittenber...@softeyes.net> wrote: > 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 > >
------------------------------------------------------------------------------
_______________________________________________ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
