Sorry, can't help more than that. And this problem will be the same in any toolkit you would use, not just IUP.
Best, Scuri Em 11/08/2015 11:52, Jörg F. Wittenberger <joerg.wittenber...@softeyes.net> escreveu: > Am 11.08.2015 um 16:31 schrieb "Jörg F. Wittenberger": > > Am 11.08.2015 um 16:27 schrieb Antonio Scuri: > >> 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 > >> } > > > > Not too bad. Though that's essentially the loop my program is sitting > in. > > > > "do something" would be in my app "1. do Iup-Calls 2. poll i/o" > > > > But if I don't have *any* IupFlush in there, than I don't see any > > progress ever. That's confusing me. > > Turns out that's not completely true. > > If "do something" does wait some time, than I'm in the same position as > if IupMailLoop would simply sit idle until it fires the timer. > > In practice: it takes forever. > > > > > > > >> 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