Re: [Pythoncard-users] Color tuple wxPython issue?

[Kevin A. <al...@se...>]

On Sep 4, 2007, at 6:14 AM, XXXXXXXXXXX wrote:

> On 10/08/2007 15:01, Kevin Altis wrote:
>> ... I have moved to Python 2.5.x and wxPython 2.8.x for my own work,
>> so that is what I'm testing against.
>
> Kevin...could you check whether wxPython 2.8.x on your machine is
> returning 4-element wxColor tuples, i.e. RGB + alpha, when you try
> changing the foreground/background colors in the resource/layout  
> editor?

Yep, this looks like a 2.7/2.8 API change.

http://www.wxpython.org/recentchanges.php

2.7.1.1

18-Oct-2006
...
wx.Colour now includes an alpha component, which defaults to  
wx.ALPHA_OPAQUE. This is in preparation for allowing various new  
alpha blening functionality using wx.Colour objects, such as drawing  
with pens and brushes on a wx.DC.

Checking wx.ALPHA_OPAQUE in the shell shows...

 >>> wx.ALPHA_OPAQUE
255

I'm guessing that the exceptions you are probably seeing can be  
traced back to the _getDefaultColor method in PythonCard/widget.py.  
Note that the check the code is doing is historical for a very old  
version of wxPython and this code could probably be safely changed.

     def _getDefaultColor( self, aColor ) :
         if aColor is None :
             return wx.NullColour
         else :
             # KEA 2001-07-27
             # is the right place for this check?
             if isinstance(aColor, tuple) and len(aColor) == 3:
                 return wx.Colour(aColor[0], aColor[1], aColor[2])
             else:
                 return aColor

If you have a resource that contains 4 element tuples (0, 0, 0, 255)  
instead of (0, 0, 0) then the code above is just going to return the  
original input and then it will end up calling the wxPython method  
SetForegroundColour with the 4 element tuple.

     def _setForegroundColor( self, aColor ) :
         aColor = self._getDefaultColor( aColor )
         self.SetForegroundColour( aColor )
         self.Refresh()   # KEA wxPython bug?

When the long 4 tuple is passed as an arg is where the actual  
exception occurs under wxPython earlier than 2.7.1.1. You can try  
this out in the shell yourself. Just run a sample like minimal.py  
with the shell using an older wxPython...

python minimal.py -s

then type something like:

 >>> comp.field1.SetForegroundColour((0, 0, 0, 255))

to see if it throws an exception.

I haven't dug into the other code in the resourceEditor or other  
places that might make assumptions about the format of the color in  
the framework, but I'm pretty sure there will be a number of problem  
spots for trying to run on an older wxPython. I'm guessing the code  
would have to specifically check for a color that wouldn't work on an  
older version of wxPython and remove the last element or do some  
generic try/except block to try using a color and then chop to a 3- 
tuple and try again.

Alternatively, you could identify the 4 tuple strings in  
your .rsrc.py files and do a global replace on them before copying/ 
using on an older version of wxPython.

ka

> Anybody else using 2.5.x or 2.6.x - could you check whether the color
> selector is just returning RGB?
>
> My situation is unusual, in that I'm mainly developing on Windows XP +
> wxPython 2.8.x alongside Windows NT + wxPython 2.5.x and yesterday I
> copied a project from the XP box onto the NT box only to find that the
> resource editor failed after importing half the components. My initial
> examination of the stack trace and code makes me think that the 2.5.x
> system cannot cope when it reads in a colour tuple that looks like
> (255,0,0,255) instead of (255,0,0).
>
> Unfortunately when I looked at the on-line wxPython docs they make  
> very
> little reference to the alpha channel, so I want to make sure there
> isn't something weird going on that is isolated to my XP machine.
>
> -- 
> XXXXXXXXXXX