hello,
I had seen this before, but couldn't reproduce it, now I can:
- open an windows explorer in folders mode, so you have a tree at the left
- start the wxpython demo
- position the wxpython window, so it covers half the folders tree of the explorer
- expand the wxpython tree
- double click on an item in the wxpython tree
weird ?
should be impossible in windows 
cheers,
Stef
I followed your steps above, and it's weird indeed. When I clicked on an item in the wxPython tree, an item on the Explorer menu opened instead, and turned the PC screen into a mess.
Bob
At 07:16 PM 10/13/2007, Stef Mientki wrote:
I had seen this before, but couldn't reproduce it, now I can:
- open an windows explorer in folders mode, so you have a tree at the left
- start the wxpython demo
- position the wxpython window, so it covers half the folders tree of the explorer
- expand the wxpython tree
- double click on an item in the wxpython treeweird ?
should be impossible in windowscheers,
Stef
Bob Klahn wrote:
At 07:16 PM 10/13/2007, Stef Mientki wrote:
I had seen this before, but couldn't reproduce it, now I can:
- open an windows explorer in folders mode, so you have a tree at the left
- start the wxpython demo
- position the wxpython window, so it covers half the folders tree of the explorer
- expand the wxpython tree
- double click on an item in the wxpython treeweird ?
should be impossible in windowscheers,
StefI followed your steps above, and it's weird indeed. When I clicked on an item in the wxPython tree, an item on the Explorer menu opened instead, and turned the PC screen into a mess.
Things like this have been reported before, but so far I've never been able to reproduce it on my machines. I suspect that it may be dependent on video driver or something. The demo does lots of Freeze/Thaw calls when changing to a new sample, so that is probably what is allowing the lower windows to bleed through the demo window, but I have no idea how or why the mouse events are being allowed through.
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
Robin,
From: Robin Dunn [mailto:robin@alldunn.com]
Sent: Monday, October 15, 2007 1:23 PM
To: wxPython-users@lists.wxwidgets.org
Subject: Re: [wxPython-users] weird wxpython demo bahavior ...Bob Klahn wrote:
>> I had seen this before, but couldn't reproduce it, now I can:
>>
>> - open an windows explorer in folders mode, so you have a
tree at the
>> left
>> - start the wxpython demo
>> - position the wxpython window, so it covers half the
folders tree of
>> the explorer
>> - expand the wxpython tree
>> - double click on an item in the wxpython tree
>>
>> weird ?
>> should be impossible in windows
>>
>> cheers,
>> Stef
>
> I followed your steps above, and it's weird indeed. When I
clicked on
> an item in the wxPython tree, an item on the Explorer menu opened
> instead, and turned the PC screen into a mess.Things like this have been reported before, but so far I've
never been able to reproduce it on my machines. I suspect
that it may be dependent on video driver or something. The
demo does lots of Freeze/Thaw calls when changing to a new
sample, so that is probably what is allowing the lower
windows to bleed through the demo window, but I have no idea
how or why the mouse events are being allowed through.--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
I just tried it, but it's not as easy to do as these guys make it out to
be. I clicked around expanding and un-expanding the trees in the Demo and
you do indeed see some flashes of things underneath...but at least on
mine, I only see it when I am actually clicking from item to item within
the tree list, not when I'm just expanding or contacting the list.
I intentionally tried to click on the items underneath, but you have to
work at it and be extra quick to do it. I have included a screenshot of
what happens when you succeed (sorry it's kind of large...I'm not at home
or I would have been able to better edit it).
I'm using the wxPython 2.8.4.2 version of the demo on Windows XP SP2,
using the Classic theme. The GPU is an ATI Sapphire Radeon X300SE. Maybe
the others can tell us what their videocards are too?
Mike
-----Original Message-----
> At 07:16 PM 10/13/2007, Stef Mientki wrote:
Mike Driscoll wrote:
Robin,
I just tried it, but it's not as easy to do as these guys make it out to
be.
I've a hit rate of 100% on 2 different machines 
(But I've to admit that I've awfully fast double-click !!)
On the other hand it has not completely due to speed of the double click,
because I can even realize the effect partially with a single click !!
Try this:
- Start Mozilla Firefox with the add-on "Tab Kit"
- set the Tab Kit option to left side tabs
- be sure to have a lot of tabs open in Mozilla
- place the wxPython demo with it's tree partial overlapping the Tab Kit
- now single click on a element in the wxPython demo tree
Weird ?
Very Weird !!
AFAIK windows, this indicates that on a single click in the wxPython demo tree,
either the complete wxPython window is hidden for a moment,
or on the position of the tree is temporary created a hole in the graphical window.
I clicked around expanding and un-expanding the trees in the Demo and
you do indeed see some flashes of things underneath...but at least on
mine, I only see it when I am actually clicking from item to item within
the tree list, not when I'm just expanding or contacting the list.
You're right,
the problem appeared after double clicking,
so that can never refer to expanding / compressing the tree,
but always refers to item selection.
I intentionally tried to click on the items underneath, but you have to
work at it and be extra quick to do it. I have included a screenshot of
what happens when you succeed (sorry it's kind of large...I'm not at home
or I would have been able to better edit it).I'm using the wxPython 2.8.4.2 version of the demo on Windows XP SP2,
using the Classic theme. The GPU is an ATI Sapphire Radeon X300SE. Maybe
the others can tell us what their videocards are too?
I doubt if it has anything todo with the video card,
but on one system it's an Nvidia GeForce 6100 on board graphics.
cheers,
Stef
I have tracked it down
When a wxFrame is frozen, it becomes transparent (in the MSW sense),
and mouse events travel through it. The demo freezes the top level
frame when it changes demos, and the reason why it's hard for people
to recreate is related to the speed of the machine and which demo you
try it with - as soon as the demo has loaded, mouse events go to the
demo again.
I was able to fix this with minimal increase in flicker by replacing
all calls to self.Freeze with self.nb.Freeze to just freeze the
notebook.
On 10/16/07, Stef Mientki <s.mientki@ru.nl> wrote:
Mike Driscoll wrote:
> Robin,
>
>
>>
>
> I just tried it, but it's not as easy to do as these guys make it out to
> be.
I've a hit rate of 100% on 2 different machines
(But I've to admit that I've awfully fast double-click !!)
On the other hand it has not completely due to speed of the double click,
because I can even realize the effect partially with a single click !!Try this:
- Start Mozilla Firefox with the add-on "Tab Kit"
- set the Tab Kit option to left side tabs
- be sure to have a lot of tabs open in Mozilla
- place the wxPython demo with it's tree partial overlapping the Tab Kit
- now single click on a element in the wxPython demo tree
Weird ?
Very Weird !!
AFAIK windows, this indicates that on a single click in the wxPython
demo tree,
either the complete wxPython window is hidden for a moment,
or on the position of the tree is temporary created a hole in the
graphical window.> I clicked around expanding and un-expanding the trees in the Demo and
> you do indeed see some flashes of things underneath...but at least on
> mine, I only see it when I am actually clicking from item to item within
> the tree list, not when I'm just expanding or contacting the list.
>
You're right,
the problem appeared after double clicking,
so that can never refer to expanding / compressing the tree,
but always refers to item selection.
> I intentionally tried to click on the items underneath, but you have to
> work at it and be extra quick to do it. I have included a screenshot of
> what happens when you succeed (sorry it's kind of large...I'm not at home
> or I would have been able to better edit it).
>
> I'm using the wxPython 2.8.4.2 version of the demo on Windows XP SP2,
> using the Classic theme. The GPU is an ATI Sapphire Radeon X300SE. Maybe
> the others can tell us what their videocards are too?
>
I doubt if it has anything todo with the video card,
but on one system it's an Nvidia GeForce 6100 on board graphics.
Chris Mellon wrote:
Mike Driscoll wrote:
Robin,
I just tried it, but it's not as easy to do as these guys make it out to
be.
I've a hit rate of 100% on 2 different machines
(But I've to admit that I've awfully fast double-click !!)
On the other hand it has not completely due to speed of the double click,
because I can even realize the effect partially with a single click !!Try this:
- Start Mozilla Firefox with the add-on "Tab Kit"
- set the Tab Kit option to left side tabs
- be sure to have a lot of tabs open in Mozilla
- place the wxPython demo with it's tree partial overlapping the Tab Kit
- now single click on a element in the wxPython demo tree
Weird ?
Very Weird !!
AFAIK windows, this indicates that on a single click in the wxPython
demo tree,
either the complete wxPython window is hidden for a moment,
or on the position of the tree is temporary created a hole in the
graphical window.I clicked around expanding and un-expanding the trees in the Demo and
you do indeed see some flashes of things underneath...but at least on
mine, I only see it when I am actually clicking from item to item within
the tree list, not when I'm just expanding or contacting the list.You're right,
the problem appeared after double clicking,
so that can never refer to expanding / compressing the tree,
but always refers to item selection.
I intentionally tried to click on the items underneath, but you have to
work at it and be extra quick to do it. I have included a screenshot of
what happens when you succeed (sorry it's kind of large...I'm not at home
or I would have been able to better edit it).I'm using the wxPython 2.8.4.2 version of the demo on Windows XP SP2,
using the Classic theme. The GPU is an ATI Sapphire Radeon X300SE. Maybe
the others can tell us what their videocards are too?I doubt if it has anything todo with the video card,
but on one system it's an Nvidia GeForce 6100 on board graphics.I have tracked it down
Chris that's great !!
If presenting such a nice demo as wxPython demo,
it looks rather clumsy, and gives a great feeling of uncertainty, if such problems occurs.
When a wxFrame is frozen, it becomes transparent (in the MSW sense),
and mouse events travel through it. The demo freezes the top level
frame when it changes demos, and the reason why it's hard for people
to recreate is related to the speed of the machine and which demo you
try it with - as soon as the demo has loaded, mouse events go to the
demo again.
I was able to fix this with minimal increase in flicker by replacing
all calls to self.Freeze with self.nb.Freeze to just freeze the
notebook.
So what does this mean for other programs ?
I don't know what freeze does, so I probably never used it
But does it mean that you should never "freeze" (whatever it does) an outer/top frame ?
thanks,
Stef Mientki
On 10/16/07, Stef Mientki <s.mientki@ru.nl> wrote:
I have tracked it down
When a wxFrame is frozen, it becomes transparent (in the MSW sense),
and mouse events travel through it. The demo freezes the top level
frame when it changes demos, and the reason why it's hard for people
to recreate is related to the speed of the machine and which demo you
try it with - as soon as the demo has loaded, mouse events go to the
demo again.I was able to fix this with minimal increase in flicker by replacing
all calls to self.Freeze with self.nb.Freeze to just freeze the
notebook.
You might want to hang on a second.. I'm having trouble remembering some of the details at the moment, but I believe that the call to Freeze was moved from the notebook and to the frame to remedy a different issue that existed. I think it was Andrea that proposed the fix. I haven't found the related messages yet, my Google-fu is a bit weak.
Robert O'Connor
From: "Chris Mellon" <arkanes@gmail.com>
Sent: Friday, October 19, 2007 5:20 PM
Robert O'Connor wrote:
From: "Chris Mellon" <arkanes@gmail.com>
Sent: Friday, October 19, 2007 5:20 PMI have tracked it down
When a wxFrame is frozen, it becomes transparent (in the MSW sense),
and mouse events travel through it. The demo freezes the top level
frame when it changes demos, and the reason why it's hard for people
to recreate is related to the speed of the machine and which demo you
try it with - as soon as the demo has loaded, mouse events go to the
demo again.I was able to fix this with minimal increase in flicker by replacing
all calls to self.Freeze with self.nb.Freeze to just freeze the
notebook.You might want to hang on a second.. I'm having trouble remembering some of the details at the moment, but I believe that the call to Freeze was moved from the notebook and to the frame to remedy a different issue that existed. I think it was Andrea that proposed the fix. I haven't found the related messages yet, my Google-fu is a bit weak.
It was done to reduce flicker.
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
Stef Mientki wrote:
I don't know what freeze does, so I probably never used it
It blocks the sending of paint events until the Thaw method is called.
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
Robin Dunn wrote:
Stef Mientki wrote:
I don't know what freeze does, so I probably never used it
It blocks the sending of paint events until the Thaw method is called.
And does calling "freeze" makes a control transparent ???
cheers,
Stef
HI All,
From: "Chris Mellon"
Sent: Friday, October 19, 2007 5:20 PM>
> I have tracked it down
>
> When a wxFrame is frozen, it becomes transparent (in the MSW sense),
> and mouse events travel through it. The demo freezes the top level
> frame when it changes demos, and the reason why it's hard for people
> to recreate is related to the speed of the machine and which demo you
> try it with - as soon as the demo has loaded, mouse events go to the
> demo again.
>
> I was able to fix this with minimal increase in flicker by replacing
> all calls to self.Freeze with self.nb.Freeze to just freeze the
> notebook.You might want to hang on a second.. I'm having trouble remembering some of
the details at the moment, but I believe that the call to Freeze was moved
from the notebook and to the frame to remedy a different issue that existed.
I think it was Andrea that proposed the fix. I haven't found the related
messages yet, my Google-fu is a bit weak.
Yes, that was me, as in the previous implementation (self.nb.Freeze())
you were able to see a small bad grey rectangle on the top left of the
notebook while the pages were created/repopulated. Freez()ing and
Thaw()ing the main frame got rid of this.
Stef Mientki wrote:
And does calling "freeze" makes a control transparent ???
No, this shouldn't happen and it is wrong in my opinion. The frame
should stay there, opaque as it is normally, until Thaw() is called. I
also noticed this behavior: calling Freeze() just makes the main frame
transparent (!).
Andrea.
"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/
On 10/21/07, Robert O'Connor wrote:
Stef Mientki wrote:
And does calling "freeze" makes a control transparent ???
No, this shouldn't happen and it is wrong in my opinion. The frame
should stay there, opaque as it is normally, until Thaw() is called. I
also noticed this behavior: calling Freeze() just makes the main frame
transparent (!).
So what does transparent for the main form mean ?
In windows even if the alphablend factor is just 1,
the form is almost invisible, but stays on top and catches all events.
And to get a more practical answer:
if I freeze a form, that is on top, does this form catch my mouse events or not ?
thanks,
Stef Mientki
It's not getting paint events, so the windows underneath it are being
painted instead and you're seeing them. Windows (the OS) also
considers top-level windows that don't paint themselves to be
non-interactive, and mouse events are passed through them to the
window below. This is a totally different kind of transparent than
alpha blending.
I saw the little black square in the notebook, but honestly I consider
that small glitch to be better than the transparency behavior.
On 10/22/07, Stef Mientki <s.mientki@ru.nl> wrote:
> Stef Mientki wrote:
>
>> And does calling "freeze" makes a control transparent ???
>>
>
> No, this shouldn't happen and it is wrong in my opinion. The frame
> should stay there, opaque as it is normally, until Thaw() is called. I
> also noticed this behavior: calling Freeze() just makes the main frame
> transparent (!).
>
>
So what does transparent for the main form mean ?
In windows even if the alphablend factor is just 1,
the form is almost invisible, but stays on top and catches all events.
And to get a more practical answer:
if I freeze a form, that is on top, does this form catch my mouse events
or not ?thanks,
Stef Mientki
I saw the little black square in the notebook, but honestly I
consider that small glitch to be better than the transparency
behavior.
+1
From: Stef Mientki [mailto:s.mientki@ru.nl]
Sent: Sunday, October 21, 2007 4:26 PM
To: wxPython-users@lists.wxwidgets.org
Subject: Re: [wxPython-users] weird wxpython demo bahavior ...Robin Dunn wrote:
> Stef Mientki wrote:
>
>> I don't know what freeze does, so I probably never used it
>
> It blocks the sending of paint events until the Thaw method
is called.
>
And does calling "freeze" makes a control transparent ???
No, that's a gradient-type setting. Since freeze blocks paint calls, I
would assume that the reason you can see the underlying controls briefly
is because when you expand the tree, it doesn't "paint" over what's
beneath it like it should...obviously because the paint is being blocked.
But since some computers are faster than others, it's not as noticeable on
fast PCs as the freeze/thaw is so fast that it's not readily apparent.
cheers,
Stef
Mike
-----Original Message-----
Chris Mellon wrote:
I saw the little black square in the notebook, but honestly I consider
that small glitch to be better than the transparency behavior.
I've made a change that appears to avoid both problems. I recently added a panel under the AUI splitter panes to work around an AUI glitch on OS X 10.3, so I moved the Freeze call to that panel and that seems to work just as well at avoiding flicker without allowing the windows under the frame to paint through.
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
Robin Dunn wrote:
Chris Mellon wrote:
I saw the little black square in the notebook, but honestly I consider
that small glitch to be better than the transparency behavior.I've made a change that appears to avoid both problems. I recently added a panel under the AUI splitter panes to work around an AUI glitch on OS X 10.3, so I moved the Freeze call to that panel and that seems to work just as well at avoiding flicker without allowing the windows under the frame to paint through.
Can we generalize this to advice for other applications that might use Freeze on the frame: always have a "frame-filling" child panel that contains the rest of the windows, and that you Freeze instead of the frame?
--
Don Dwiggins
Advanced Publishing Technology
Don Dwiggins wrote:
Robin Dunn wrote:
Chris Mellon wrote:
I saw the little black square in the notebook, but honestly I consider
that small glitch to be better than the transparency behavior.I've made a change that appears to avoid both problems. I recently added a panel under the AUI splitter panes to work around an AUI glitch on OS X 10.3, so I moved the Freeze call to that panel and that seems to work just as well at avoiding flicker without allowing the windows under the frame to paint through.
Can we generalize this to advice for other applications that might use Freeze on the frame: always have a "frame-filling" child panel that contains the rest of the windows, and that you Freeze instead of the frame?
Yes, but we talked on wx-dev about doing that automatically if Freeze is called on a top-level window.
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
