Am 11.08.2015 um 17:42 schrieb Antonio Scuri:
> Sorry, can't help more than that. And this problem will be the same in
> any toolkit you would use, not just IUP.
No problem.
You've already been very helpful. Learning that IupFlush is _not_
something to be used lightly (since it appears to make things work) was
incredibly useful.
Currently my application does not crash anymore.
My focus is already shifting towards the next issue in the queue. Under
some conditions (which I can not yet pinpoint) the display update is a
bit weird. I see all the controls positioned in the upper left corner
for a split second and than they appear at correct position.
If I remove *all* calls to IupRefresh the result is the same as in the
"distorted" split second.
So my current best guess is that I should suppress some, but not all,
calls to IupRefresh. But that's a wild guess at the moment. Maybe it's
a bad idea like excessively calling IupFlush.
Thanks again for your help!
Best
/Jörg
>
> 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
