Maybe you can try the IDLE and see how it behaves. There is also another possibility. The IDLE callback is somewhat equivalent of
while(IupLoopStep() != IUP_CLOSE) { do something } But this is also high CPU consuming. So, to avoid this, you can try: while(IupLoopStepWait() != IUP_CLOSE) { do something } But I would start with the IDLE. In GTK is much better handled than in Windows. Best, Scuri On Tue, Aug 11, 2015 at 11:09 AM, "Jörg F. Wittenberger" < joerg.wittenber...@softeyes.net> wrote: > Sorry again. > > I've been distracted and did not read to the end of your message. > > Am 11.08.2015 um 15:39 schrieb Antonio Scuri: > > 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) > > That's the "complicated" way I can see. Have an embeddes > Lua-Interpreter executed dynamically generated Lua code. > > > - 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) > > That's what we startet with. But since I can't make the timer return > "right now", it will hopelessly slow down the application. To no > usable. Example: e few hundred results to be read from the database and > display in a matrix. Takes forever while Iup is sitting most of the > time in idle until the timer will check for i/o and notice a new item. > > > - Use the IDLE callback to process it (high CPU use since it will be > > running all the time) > > As you said: that's the CPU hook. I read that in the docs and thought > there must be a better way. > > Sorry again for the incomplete reply before. > > /Jörg > > > > > 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 > > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > 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