[Lazarus] blank window

[zeljko]

On Monday 30 of January 2012 17:19:42 Henry Vermaak wrote:
> On 26/01/12 17:34, Henry Vermaak wrote:
> > On 26/01/12 16:56, Mattias Gaertner wrote:
> >> Henry Vermaak <henry.vermaak at gmail.com> hat am 26. Januar 2012 um 17:21
> >> 
> >> geschrieben:
> >> > Perhaps a thread problem?
> >> 
> >> Maybe.
> >> 
> >> Please add the unit cmem as first unit in ide/lazarus.pp and try again.
> > 
> > That didn't make a difference, unfortunately.
> 
> I started looking into what changed for the "new iteration" code and
> came across gtk2msgqueue.pp.  I saw a comment that TGtkMessageQueue is
> supposed to be thread safe (presumably for PostMessage), but it appears
> that it isn't (despite the critical section in the old code, since a
> lock variable is checked first, presumably to handle nested locks).  The
> new code is even worse: g_main_context_acquire doesn't block and return
> value isn't checked, so it seems rather pointless.  Why have a "lock"
> method that doesn't actually lock?  I'd imagine the only reason that
> this doesn't break really badly is that acquiring the context seems
> unnecessary, since the help for g_main_context_acquire says:
> 
> You must be the owner of a context before you can call
> g_main_context_prepare(), g_main_context_query(),
> g_main_context_check(), g_main_context_dispatch().
> 
> But none of those functions are called anywhere.  What's going on here?

Why do you think they aren't called ?

>   I can see that the message queue can get pretty screwed up when
> someone uses PostMessage.

No, PostMessage works fine. I've tested it with an "heavy" app which posts 
messages from another threads and updates various controls (works same as with 
win32 or qt), and it DOES NOT work when using old approach.
Currently I'm testing gtk2 without gtk threads initialization, looks good and 
could be commited soon.


zeljko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20120131/16491df3/attachment-0003.html>