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
