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.
> 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
