first batch of wxPythonOSX-2.5.2.2p.20040717 problems

wxPython Dev
1

TextCtrl leaves background and outline of control around after calling Hide() or Show(False). The text is hidden. Covering up the window, forcing a refresh of the underlying panel, etc. doesn't appear to get rid of the artifacts.

The clipping region is not updated for resized panels which causes the drag rect used in the PythonCard resourceEditor to get chopped off at the initial panel size instead of the resized size. Controls are drawn correctly, what is cut off are wx.DC draw operations done on the panel. This has actually been around since 2.5.1.5 but Kevin O. said this spring I should just wait for the 2.5.2.x fixes he and Stefan had made before doing any serious testing and this is the first time I've run 2.5.2.x. I would rather not have to make a minimal sample to show this if I don't have to since the calls in the resourceEditor are just standard wxPython. See the on_mouseDrag handler for the self.dc.DrawRectanglePointSize calls.

The ListBox appears to have too much whitespace on the left side of the text. OTOH, the text looks great compared to 2.5.1.5 and earlier :slight_smile:

Tab and Shift-Tab are inserted into a TextCtrl with the wxTE_RICH2 style rather than changing focus to the next or previous control. Single-line TextCtrl seems to work correctly.

StaticBitmap and BitmapButton sizes are off, still investigating.

SpinCtrl position is wrong on initialization. It reports (-1, -1) and appears to be at position (0, 0) rather than whatever is supplied at initialization. See wxPython demo for an example of this bug.

StatusBar font size needs to be reduced slightly to avoid lowercase jpqy letters from being chopped on the bottom. Alternatively, it looks like the position of the text could probably be raised two pixels and still leave whitespace above the text. Either way, some adjustment of the text size and position probably needs to be done.

ka
p.s. Overall the Mac controls are looking nice! Good job.

2

Hi Kevin (A),

TextCtrl leaves background and outline of control around after calling Hide() or Show(False). The text is hidden. Covering up the window, forcing a refresh of the underlying panel, etc. doesn't appear to get rid of the artifacts.

Thanks for reporting this. I'm seeing the opposite (no border appearing when controls is shown but not focused) on some demos, but not all. ;-/ I'll talk to Stefan about this - he recently made big changes to wxTextCtrl due to various complexities surrounding the native Mac control. (For example, there is no 'out of the box' multiline Mac text ctrl! - you need to draw borders and such yourself.)

The clipping region is not updated for resized panels which causes the drag rect used in the PythonCard resourceEditor to get chopped off at the initial panel size instead of the resized size. Controls are drawn correctly, what is cut off are wx.DC draw operations done on the panel. This has actually been around since 2.5.1.5 but Kevin O. said this spring I should just wait for the 2.5.2.x fixes he and Stefan had made before doing any serious testing and this is the first time I've run 2.5.2.x. I would rather not have to make a minimal sample to show this if I don't have to since the calls in the resourceEditor are just standard wxPython. See the on_mouseDrag handler for the self.dc.DrawRectanglePointSize calls.

I'll look into this probably tomorrow.

The ListBox appears to have too much whitespace on the left side of the text. OTOH, the text looks great compared to 2.5.1.5 and earlier :slight_smile:

That's because it is now using the nice OS X style controls, and not the old OS 9 style one. :wink: As for the sizing issue, are you referring to the default size of the control on startup?

Tab and Shift-Tab are inserted into a TextCtrl with the wxTE_RICH2 style rather than changing focus to the next or previous control. Single-line TextCtrl seems to work correctly.

I assume it only does this on Mac? I had thought that previous versions of wx had this behavior as default...

StaticBitmap and BitmapButton sizes are off, still investigating.

SpinCtrl position is wrong on initialization. It reports (-1, -1) and appears to be at position (0, 0) rather than whatever is supplied at initialization. See wxPython demo for an example of this bug.

Yes, I'm seeing this in the demo too. There are some other sizing issues here as well (notice the wxTextCtrl blue highlight borders are clipped), and actually I was waiting until Stefan fixed wxTextCtrl before looking into this further. So I'll be trying to submit a fix for this in the next couple days.

StatusBar font size needs to be reduced slightly to avoid lowercase jpqy letters from being chopped on the bottom. Alternatively, it looks like the position of the text could probably be raised two pixels and still leave whitespace above the text. Either way, some adjustment of the text size and position probably needs to be done.

It may be easiest just to try moving it up two pixels first and see if that works. Otherwise, we could actually set a control's size to the "mini" variant if it's parent is a wxStatusBar.

ka
p.s. Overall the Mac controls are looking nice! Good job.

Good! Hopefully we can iron out the remaining issues and get it (mostly) up to speed with other platforms. We still need to support the DataBrowser control for native wxListCtrls and wxTreeCtrls, but that one will take some time.

Thanks,

Kevin

···

On Jul 18, 2004, at 3:23 PM, Kevin Altis wrote:

3

[Kevin O. has already addressed most of this, so I'll just trim it to the one issue left.]

Kevin Altis wrote:

Tab and Shift-Tab are inserted into a TextCtrl with the wxTE_RICH2 style rather than changing focus to the next or previous control. Single-line TextCtrl seems to work correctly.

The RICH styles are not used at all in wxMac so those flags shouldn't make any difference. Does the control have the wx.TE_PROCESS_TAB style? There was a change there such that if the style is present then the TAB is treated a normal character and is not used for navigation at all. So if you use wx.TE_PROCESS_TAB and want to still use it for navigation then you need to send a navigation event from your EVT_KEY_DOWN handler. A Navigate() method was added to help with this, here is its declaration and docstring:

     DocDeclAStr(
         virtual bool , Navigate(int flags = wxNavigationKeyEvent::IsForward),
         "Navigate(self, int flags=NavigationKeyEvent.IsForward) -> bool",
         "Does keyboard navigation from this window to another, by sending a
`wx.NavigationKeyEvent`.", "

     :param flags: A combination of the ``IsForward`` or ``IsBackward``
         and the ``WinChange`` values in the `wx.NavigationKeyEvent`
         class, which determine if the navigation should be in forward
         or reverse order, and if it should be able to cross parent
         window boundaries, such as between notebook pages or MDI child
         frames. Typically the status of the Shift key (for forward or
         backward) or the Control key (for WinChange) would be used to
         determine how to set the flags.

One situation in which you may wish to call this method is from a text
control custom keypress handler to do the default navigation behaviour
for the tab key, since the standard default behaviour for a multiline
text control with the wx.TE_PROCESS_TAB style is to insert a tab and
not navigate to the next control.");

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

4

Argh! Indeed that is the problem. My bad for not running 2.5.2.x on Windows before the Mac or I would have seen this is "broken" there as well. I guess I'll just remove that flag to get the old behavior. Better add this one to the migration guide.

ka

···

On Jul 19, 2004, at 8:22 AM, Robin Dunn wrote:

[Kevin O. has already addressed most of this, so I'll just trim it to the one issue left.]

Kevin Altis wrote:

Tab and Shift-Tab are inserted into a TextCtrl with the wxTE_RICH2 style rather than changing focus to the next or previous control. Single-line TextCtrl seems to work correctly.

The RICH styles are not used at all in wxMac so those flags shouldn't make any difference. Does the control have the wx.TE_PROCESS_TAB style? There was a change there such that if the style is present then the TAB is treated a normal character and is not used for navigation at all. So if you use wx.TE_PROCESS_TAB and want to still use it for navigation then you need to send a navigation event from your EVT_KEY_DOWN handler. A Navigate() method was added to help with this, here is its declaration and docstring:

    DocDeclAStr(
        virtual bool , Navigate(int flags = wxNavigationKeyEvent::IsForward),
        "Navigate(self, int flags=NavigationKeyEvent.IsForward) -> bool",
        "Does keyboard navigation from this window to another, by sending a
`wx.NavigationKeyEvent`.", "

    :param flags: A combination of the ``IsForward`` or ``IsBackward``
        and the ``WinChange`` values in the `wx.NavigationKeyEvent`
        class, which determine if the navigation should be in forward
        or reverse order, and if it should be able to cross parent
        window boundaries, such as between notebook pages or MDI child
        frames. Typically the status of the Shift key (for forward or
        backward) or the Control key (for WinChange) would be used to
        determine how to set the flags.

One situation in which you may wish to call this method is from a text
control custom keypress handler to do the default navigation behaviour
for the tab key, since the standard default behaviour for a multiline
text control with the wx.TE_PROCESS_TAB style is to insert a tab and
not navigate to the next control.");

5

Hi Kevin (A),

The ListBox appears to have too much whitespace on the left side of the text. OTOH, the text looks great compared to 2.5.1.5 and earlier :slight_smile:

That's because it is now using the nice OS X style controls, and not the old OS 9 style one. :wink: As for the sizing issue, are you referring to the default size of the control on startup?

Attached are two images, the first one shows the display settings list from the System Settings and the second is a wxPython ListBox that I stuck the same text into. It is a minor issue, but it just looks like there is a bit much whitespace between the text and border on the left.

Tab and Shift-Tab are inserted into a TextCtrl with the wxTE_RICH2 style rather than changing focus to the next or previous control. Single-line TextCtrl seems to work correctly.

I assume it only does this on Mac? I had thought that previous versions of wx had this behavior as default...

StaticBitmap and BitmapButton sizes are off, still investigating.

The BitmapButton and StaticBitmap size problem is on Windows too and looking closer I think I caused this problem myself with a change to PythonCard for 0.8. Yep, until further notice this is my own stupidity, sorry.

ka

normal.png

wx.png

···

On Jul 18, 2004, at 6:00 PM, Kevin Ollivier wrote:

On Jul 18, 2004, at 3:23 PM, Kevin Altis wrote:

6

Kevin Altis wrote:

Better add this one to the migration guide.

Yep.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

7

Hi Kevin (A),

The ListBox appears to have too much whitespace on the left side of the text. OTOH, the text looks great compared to 2.5.1.5 and earlier :slight_smile:

That's because it is now using the nice OS X style controls, and not the old OS 9 style one. :wink: As for the sizing issue, are you referring to the default size of the control on startup?

Attached are two images, the first one shows the display settings list from the System Settings and the second is a wxPython ListBox that I stuck the same text into. It is a minor issue, but it just looks like there is a bit much whitespace between the text and border on the left.

Ah, I see, thanks! I'll see if I can tweak this to match the system controls.

BTW, I've fixed the positioning problem with wxSpinCtrl (it was a typo - the base constructor was being called with wxDefaultPosition regardless of if a position was passed in or not :wink: and am working on fixing the cropped text control. Should have this fixed soon. I'm also taking the time to make it match the Apple HIG closer in terms of sizing.

I've also sent a message to wx-dev about the text control borders issue. When I hear back, I should hopefully be able to put together a fix on this.

Tab and Shift-Tab are inserted into a TextCtrl with the wxTE_RICH2 style rather than changing focus to the next or previous control. Single-line TextCtrl seems to work correctly.

I assume it only does this on Mac? I had thought that previous versions of wx had this behavior as default...

StaticBitmap and BitmapButton sizes are off, still investigating.

The BitmapButton and StaticBitmap size problem is on Windows too and looking closer I think I caused this problem myself with a change to PythonCard for 0.8. Yep, until further notice this is my own stupidity, sorry.

That's OK, I'm just glad to hear that it's taken care of! :wink:

Kevin

···

On Jul 19, 2004, at 10:48 AM, Kevin Altis wrote:

On Jul 18, 2004, at 6:00 PM, Kevin Ollivier wrote:

On Jul 18, 2004, at 3:23 PM, Kevin Altis wrote:

8

[snip]

The clipping region is not updated for resized panels which causes the drag rect used in the PythonCard resourceEditor to get chopped off at the initial panel size instead of the resized size. Controls are drawn correctly, what is cut off are wx.DC draw operations done on the panel. This has actually been around since 2.5.1.5 but Kevin O. said this spring I should just wait for the 2.5.2.x fixes he and Stefan had made before doing any serious testing and this is the first time I've run 2.5.2.x. I would rather not have to make a minimal sample to show this if I don't have to since the calls in the resourceEditor are just standard wxPython. See the on_mouseDrag handler for the self.dc.DrawRectanglePointSize calls.

I'm not seeing this on my machine using PythonCard CVS (I just did a CVS update). I'm looking in tools/resourceEditor/resourceEditor.py, is this the correct place? First, I am seeing just calls to DrawRectangle inside on_mouseDrag, and more importantly, I'm not seeing any clipping problems when adding controls to the canvas and then resizing them. (Adding a wxRadioGroup does give strange resizing behavior though, where it jerks around periodically) I didn't see any option to add a Panel control, so I assume when you talk about the panel, you're referring to the panel behind the control that's used by the resource editor for resizing? Does this always happen when resizing any control, or are there certain controls or certain steps that make it happen?

Kevin

···

On Jul 18, 2004, at 3:23 PM, Kevin Altis wrote:

9

The DrawRect... calls are only done when dragging the control not resizing it. Create a Button, click and drag the button and you should see a dashed rectangle appear and follow the mouse while is is down. As you move the mouse down or to the right the rectangle will start to get clipped before you reach the boundaries of the window.

ka

···

On Jul 19, 2004, at 12:39 PM, Kevin Ollivier wrote:

On Jul 18, 2004, at 3:23 PM, Kevin Altis wrote:

[snip]

The clipping region is not updated for resized panels which causes the drag rect used in the PythonCard resourceEditor to get chopped off at the initial panel size instead of the resized size. Controls are drawn correctly, what is cut off are wx.DC draw operations done on the panel. This has actually been around since 2.5.1.5 but Kevin O. said this spring I should just wait for the 2.5.2.x fixes he and Stefan had made before doing any serious testing and this is the first time I've run 2.5.2.x. I would rather not have to make a minimal sample to show this if I don't have to since the calls in the resourceEditor are just standard wxPython. See the on_mouseDrag handler for the self.dc.DrawRectanglePointSize calls.

I'm not seeing this on my machine using PythonCard CVS (I just did a CVS update). I'm looking in tools/resourceEditor/resourceEditor.py, is this the correct place? First, I am seeing just calls to DrawRectangle inside on_mouseDrag, and more importantly, I'm not seeing any clipping problems when adding controls to the canvas and then resizing them. (Adding a wxRadioGroup does give strange resizing behavior though, where it jerks around periodically) I didn't see any option to add a Panel control, so I assume when you talk about the panel, you're referring to the panel behind the control that's used by the resource editor for resizing? Does this always happen when resizing any control, or are there certain controls or certain steps that make it happen?

10

I found the problem and once again it is sort of PythonCard-specific I guess or at least as far as the Mac is concerned. I make a call to the createDC method during initialization.

     def createDC(self):
         dc = wx.ClientDC(self.panel)
         dc.SetPen(wx.Pen('black', 1, wx.DOT))
         dc.SetBrush(wx.TRANSPARENT_BRUSH)
         dc.SetLogicalFunction(wx.INVERT)
         self.dc = dc

On Windows this doesn't seem to be an issue regardless of when the window is resized or later manual window resizes. However, on the Mac it looks like saving a reference to the DC like this is a problem for clipping. If I manually call createDC after the window is resized the problem goes away. So, I don't know whether this is a bug or not. I'm pretty sure it doesn't create a problem on GTK.

ka

···

On Jul 19, 2004, at 3:30 PM, Kevin Altis wrote:

On Jul 19, 2004, at 12:39 PM, Kevin Ollivier wrote:

On Jul 18, 2004, at 3:23 PM, Kevin Altis wrote:

[snip]

The clipping region is not updated for resized panels which causes the drag rect used in the PythonCard resourceEditor to get chopped off at the initial panel size instead of the resized size. Controls are drawn correctly, what is cut off are wx.DC draw operations done on the panel. This has actually been around since 2.5.1.5 but Kevin O. said this spring I should just wait for the 2.5.2.x fixes he and Stefan had made before doing any serious testing and this is the first time I've run 2.5.2.x. I would rather not have to make a minimal sample to show this if I don't have to since the calls in the resourceEditor are just standard wxPython. See the on_mouseDrag handler for the self.dc.DrawRectanglePointSize calls.

I'm not seeing this on my machine using PythonCard CVS (I just did a CVS update). I'm looking in tools/resourceEditor/resourceEditor.py, is this the correct place? First, I am seeing just calls to DrawRectangle inside on_mouseDrag, and more importantly, I'm not seeing any clipping problems when adding controls to the canvas and then resizing them. (Adding a wxRadioGroup does give strange resizing behavior though, where it jerks around periodically) I didn't see any option to add a Panel control, so I assume when you talk about the panel, you're referring to the panel behind the control that's used by the resource editor for resizing? Does this always happen when resizing any control, or are there certain controls or certain steps that make it happen?

The DrawRect... calls are only done when dragging the control not resizing it. Create a Button, click and drag the button and you should see a dashed rectangle appear and follow the mouse while is is down. As you move the mouse down or to the right the rectangle will start to get clipped before you reach the boundaries of the window.

ka

11

I had a half-written email saying pretty much the same thing when this came in. :wink: IMHO, this is correct behavior because the purpose of creating a wxClientDC (as opposed to a wxWindowDC) is that you are only able to draw within the client area of the control. The size is determined when the client DC is constructed, and I think it'd be expensive to recalculate the clipping region every time a DC function is called, not to mention, this wouldn't be correct behavior for someone who explicitly called SetClippingRegion and set the clip region themselves.

I decided to check the various ports to see what they do in the wxClientDC constructor, and in fact, you may have uncovered a very nasty MSW bug... Mac and GTK do both call SetClippingRegion in the wxClientDC initialization and set it to the size of the wxWindow passed in. On MSW, however, the call to SetClippingRegion is there, but it is inside a #ifdef __WXUNIVERSAL__ || defined(__WXWINCE__) block, meaning that the clipping region isn't set on MSW.

Unless MSW somehow magically clips all drawing to the client area of the HWND, then this looks to me to be a bug. I'll send a note to wxDev and see what people say.

I think to resolve your Mac problem with PythonCard, you should override the panel resize handler and call self.dc.SetClippingRegionPointSize(self.panel.GetPoint(), self.panel.GetSize()) or similar. (Not sure if SetClippingRegionPointSize exists, but I'm assuming it does based on Robin's wxDC changes. =)

HTH,

Kevin

···

On Jul 19, 2004, at 6:05 PM, Kevin Altis wrote:

On Jul 19, 2004, at 3:30 PM, Kevin Altis wrote:

On Jul 19, 2004, at 12:39 PM, Kevin Ollivier wrote:

On Jul 18, 2004, at 3:23 PM, Kevin Altis wrote:

[snip]

The clipping region is not updated for resized panels which causes the drag rect used in the PythonCard resourceEditor to get chopped off at the initial panel size instead of the resized size. Controls are drawn correctly, what is cut off are wx.DC draw operations done on the panel. This has actually been around since 2.5.1.5 but Kevin O. said this spring I should just wait for the 2.5.2.x fixes he and Stefan had made before doing any serious testing and this is the first time I've run 2.5.2.x. I would rather not have to make a minimal sample to show this if I don't have to since the calls in the resourceEditor are just standard wxPython. See the on_mouseDrag handler for the self.dc.DrawRectanglePointSize calls.

I'm not seeing this on my machine using PythonCard CVS (I just did a CVS update). I'm looking in tools/resourceEditor/resourceEditor.py, is this the correct place? First, I am seeing just calls to DrawRectangle inside on_mouseDrag, and more importantly, I'm not seeing any clipping problems when adding controls to the canvas and then resizing them. (Adding a wxRadioGroup does give strange resizing behavior though, where it jerks around periodically) I didn't see any option to add a Panel control, so I assume when you talk about the panel, you're referring to the panel behind the control that's used by the resource editor for resizing? Does this always happen when resizing any control, or are there certain controls or certain steps that make it happen?

The DrawRect... calls are only done when dragging the control not resizing it. Create a Button, click and drag the button and you should see a dashed rectangle appear and follow the mouse while is is down. As you move the mouse down or to the right the rectangle will start to get clipped before you reach the boundaries of the window.

ka

I found the problem and once again it is sort of PythonCard-specific I guess or at least as far as the Mac is concerned. I make a call to the createDC method during initialization.

    def createDC(self):
        dc = wx.ClientDC(self.panel)
        dc.SetPen(wx.Pen('black', 1, wx.DOT))
        dc.SetBrush(wx.TRANSPARENT_BRUSH)
        dc.SetLogicalFunction(wx.INVERT)
        self.dc = dc
On Windows this doesn't seem to be an issue regardless of when the window is resized or later manual window resizes. However, on the Mac it looks like saving a reference to the DC like this is a problem for clipping. If I manually call createDC after the window is resized the problem goes away. So, I don't know whether this is a bug or not. I'm pretty sure it doesn't create a problem on GTK.

12

Kevin Ollivier wrote:

Unless MSW somehow magically clips all drawing to the client area of the HWND, then this looks to me to be a bug.

I would guess that is the case.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

13

Hi Robin,

···

On Jul 20, 2004, at 2:24 PM, Robin Dunn wrote:

Kevin Ollivier wrote:

Unless MSW somehow magically clips all drawing to the client area of the HWND, then this looks to me to be a bug.

I would guess that is the case.

That it's a bug, or that MSW magically clips drawing to the client area of the HWND? :wink:

Thanks,

Kevin

14

Kevin Ollivier wrote:

Hi Robin,

Kevin Ollivier wrote:

Unless MSW somehow magically clips all drawing to the client area of the HWND, then this looks to me to be a bug.

I would guess that is the case.

That it's a bug, or that MSW magically clips drawing to the client area of the HWND? :wink:

That MSW is auto-clipping.

···

On Jul 20, 2004, at 2:24 PM, Robin Dunn wrote:

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!