Kevin Ollivier wrote:
Looking at the test failures, I think a number of them are due to ambiguities, as Frank mentioned. For the ClientRect failure, my guess is that the client rect is adding the control's border to the x and y positions. Or perhaps it's giving it's x,y relative to the parent?
wxRect GetClientRect() const
{
return wxRect(GetClientAreaOrigin(), GetClientSize());
}
Both GetClientAreaOrigin and GetClientSize will call platform specific methods located in the derived classes, so they can (and do) vary across platforms and window types. IMO because of this potential variability the only valid test for GetClientRect is that it returns a rectangle positioned at GetClientAreaOrigin and with a size of GetClientSize.
Also, will GetClientSize always return a value >= the MinSize?
No. The min size is just a hint for sizers and in the case of top-level windows it's also a hint for the window manager. In most cases it's possible to explicitly set the size smaller than the minsize. Even if that is not the case, the min size is for the whole window, whereas the client size can be smaller than that depending on window type, platform and how borders and other decorations are accounted for.
As for the virtual size failures, I suspect the issue is that SetVirtualSize doesn't allow the virtual size to go below the control's current size? Is that correct?
It is limited based on what the virtual size hints are currently set to. Here is the common (platform independent) base class version:
void wxWindowBase::DoSetVirtualSize( int x, int y )
{
if ( m_minVirtualWidth != wxDefaultCoord && m_minVirtualWidth > x )
x = m_minVirtualWidth;
if ( m_maxVirtualWidth != wxDefaultCoord && m_maxVirtualWidth < x )
x = m_maxVirtualWidth;
if ( m_minVirtualHeight != wxDefaultCoord && m_minVirtualHeight > y )
y = m_minVirtualHeight;
if ( m_maxVirtualHeight != wxDefaultCoord && m_maxVirtualHeight < y )
y = m_maxVirtualHeight;
m_virtualSize = wxSize(x, y);
}
Again this method can be overridden in the derived classes to have different behavior if needed for that class.
It makes sense, but if so, we should update the tests and the documentation to reflect that. Also, Robin, the Get/SetVirtualSizeWH APIs just convert tuples into wx.Size (and vice-versa) then call the wx.Size version of the method, right?
SWIG sees these declarations:
void SetVirtualSize(const wxSize& size );
%Rename(SetVirtualSizeWH, void, SetVirtualSize( int w, int h ));
so in addition to the wrapper for the regular SetVirtualSize it generates a Python wrapper method named SetVirtualSizeWH which calls the C++ SetVirtualSize which takes two parameters. On the C++ side we have these methods:
void SetVirtualSize( const wxSize &size ) { DoSetVirtualSize( size.x, size.y ); }
void SetVirtualSize( int x, int y ) { DoSetVirtualSize( x, y ); }
So, yes they do exactly the same thing, but just provide a way for the programmer to have more choices on how to call them. For the getters we have this for SWIG:
wxSize GetVirtualSize() const;
DocDeclAName(
void, GetVirtualSize( int *OUTPUT, int *OUTPUT ) const,
"GetVirtualSizeTuple() -> (width, height)",
GetVirtualSizeTuple);
And this C++ code:
wxSize GetVirtualSize() const { return DoGetVirtualSize(); }
void GetVirtualSize( int *x, int *y ) const
{
wxSize s( DoGetVirtualSize() );
if( x )
*x = s.GetWidth();
if( y )
*y = s.GetHeight();
}
This same pattern is fairly common in wx and wxPython.
If so, maybe a test that ensures GetVirtualSizeWH returns the same value as GetVirtualSize would be sufficient.
Also that setting the same value via the two setters results in the same values. Also via using the VirtualSize property.
One last question for Frank. I noticed you have an assert for missing wx.Slider.GetRange(). AFAICT, that function is not part of the wx.Slider API. It probably SHOULD be, as we have SetRange(min, max), but right now you get the values by calling GetMin() and GetMax(). It was probably done this way because in C++ returning two values is difficult and they didn't want to use wx.Size or wx.Point for it, so they just stuck with the GetMin/GetMax functions.
Actually it's good to point out things like that because it's super easy to add something like this in the declarations that SWIG sees:
%pythoncode {
def GetRange(self):
return self.GetMin(), self.GetMax()
}
···
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!