Thread: Re: [Pythoncard-users] colored rectangles

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.338 / Virus Database: 267.9.6/59 - Release Date: 27/07/2005

Alex Tweedly <al...@tw...> wrote on 08/01/2005 05:31:59 PM:

>> bra...@om... wrote: 
> 
>> One thing my users miss now that we've transitioned away from 
> >FileMaker is the color. 
>> In FileMaker, specific regions of a form were colored to help break 
>> up the window 
>> into visual groupings. This was accomplished in FileMaker through the 
use of 
>> a rectangle widget. 
>> Does anyone have any recommendations for how to bring more color to 
>> PythonCard layouts? 

> imageButton with no file (image) specified. set to visible, 
> disabled, border = none and set the backgroundColor to what you 
> want.  (just watch your layer order  :-)

That sounds like a nifty solution, but it didn't work when I tried it on
the Mac. It just turns gray and is unresponsive to changes in the
backgroundColor or foregroundColor. If I set the border to transparent,
the whole image button turns transparent (still gray), but when the
border is None, the image button obscures any overlapping widgets, 
even the ones that are supposedly in front.

The Image widget worked a little better, in that I could change the
color, but it still obscures all overlapping widgets.

I'm using PythonCard .82 (latest CVS) and wxPython 2.5.3 on Mac OS 10.4.2
with Python 2.3.5. Since I'm at home today, I don't have access to my
work PC, but tomorrow I can try it on Windows XP. 

On Aug 2, 2005, at 10:29 AM, bra...@om... wrote:

>
> Alex Tweedly <al...@tw...> wrote on 08/01/2005 05:31:59 PM:
>
>  >> bra...@om... wrote:
> >
>  >> One thing my users miss now that we've transitioned away from
>  > >FileMaker is the color.
>  >> In FileMaker, specific regions of a form were colored to help =
break
>  >> up the window
>  >> into visual groupings. This was accomplished in FileMaker through=20=

> the use of
>  >> a rectangle widget.
>  >> Does anyone have any recommendations for how to bring more color =
to
>  >> PythonCard layouts?
>
> > imageButton with no file (image) specified. set to visible,
>  > disabled, border =3D none and set the backgroundColor to what you
>  > want. =A0(just watch your layer order =A0:-)
>
> That sounds like a nifty solution, but it didn't work when I tried it=20=

> on
> the Mac. It just turns gray and is unresponsive to changes in the
> backgroundColor or foregroundColor. If I set the border to =
transparent,
> the whole image button turns transparent (still gray), but when the
> border is None, the image button obscures any overlapping widgets,
> even the ones that are supposedly in front.
>
> The Image widget worked a little better, in that I could change the
> color, but it still obscures all overlapping widgets.
>
> I'm using PythonCard .82 (latest CVS) and wxPython 2.5.3 on Mac OS=20
> 10.4.2
> with Python 2.3.5. Since I'm at home today, I don't have access to my
> work PC, but tomorrow I can try it on Windows XP.

IIRC, z-order and overlapping widgets is going to be a problem on the=20
Mac in the foreseeable future. wx doesn't really support overlapping=20
widgets anyway, it is just that there are certain situations you can=20
get away with them on Windows and Linux. Another possibility might be=20
to use a background image which has the rectangles you want and will be=20=

drawn instead of the normal background window pattern; see the proof=20
sample for an example of the use of a background image. The downside is=20=

that the background image you create will need to be tweaked as your=20
layout changes, window grows, etc. but it should work on all platforms.

ka=

Kevin Altis wrote on 08/02/2005 12:50:46 PM:

> IIRC, z-order and overlapping widgets is going to be a problem on the 
> Mac in the foreseeable future. wx doesn't really support overlapping 
> widgets anyway, it is just that there are certain situations you can 
> get away with them on Windows and Linux. 

That would explain why StaticBox doesn't work on the Mac (it blocks
mouse events to overlapping/contained widgets), except it doesn't
explain why a StaticBox works fine in a plain wx app (see below):

#---------------------- contributed by Alex Tweedly --------------------- 

class TestPanel(wx.Panel):
   def __init__(self, parent, log):
       wx.Panel.__init__(self, parent, -1)
       self.log = log
       self.count = 0

       self.lb = wx.StaticBox(self, -1, "This example uses the 
wx.StaticBox.", (45, 100), (200,400))
       self.btn = wx.Button(self, -1, "Test", (50,120))
       wx.EVT_LEFT_DOWN(self.lb, self.on_box)
       wx.EVT_LEFT_DOWN(self.btn, self.on_btn)

   def on_box(self, event):
       print "box"
   def on_btn(self, event):
       print "btn"

if __name__ == '__main__':
   import sys
   app = wx.PySimpleApp()
   frame = wx.Frame(None, -1, "title")
   TestPanel(frame, sys.stdout)
   frame.Show(True)
   app.MainLoop() 

Kevin Altis wrote:

> IIRC, z-order and overlapping widgets is going to be a problem on the 
> Mac in the foreseeable future. wx doesn't really support overlapping 
> widgets anyway, it is just that there are certain situations you can 
> get away with them on Windows and Linux.

Oh boy, am I glad you said that now. I was just about to set off on a 
project that would have utterly failed because it was completely 
dependent on reliable z-order and overlapping components. And of course 
I'd have been developing on Win, so it would probably have worked *most* 
of the time - leaving me baffled why sometimes I didn't get away with 
it. And eventually, I'd have put it on a Mac and discovered I'd wasted a 
lot of time.
So I'm really glad you said that now - thanks Kevin.

> Another possibility might be to use a background image which has the 
> rectangles you want and will be drawn instead of the normal background 
> window pattern; see the proof sample for an example of the use of a 
> background image. The downside is that the background image you create 
> will need to be tweaked as your layout changes, window grows, etc. but 
> it should work on all platforms.

Using an image and adjusting it for changes sounds like a nuisance, so I 
kept looking ....

Brad,

Another approach (not quite so simple, I'm afraid) would be to define 
your own background handler (this idea and code stolen from the 
resourceEditor's way of doing gridlines). This works fine (as far as I 
can tell) on Windows - and should, I hope, work on other systems as well 
(assuming the resourceEditor's gridlines work)

For this demo, I just defined Image components called "colouredArea1", 
"colouredArea2", etc. and defined their fore & backgroundColor (remember 
they're not going to be actually visible, so shouldn't be any 
platform-specific issues) - but doing this let me see in the 
resourceEditor how it should look. And using simple components like this 
means that you can use them in sizers, or adjust their size in your own 
geometry handlers. 

class MyBackground(model.Background):

    def on_initialize(self, event):
        # if you have any initialization
        # including sizer setup, do it here
        for comp in self.components.itervalues():
            if comp.name[:12] == "colouredArea":
                comp.visible = False
        self.panel.Bind(wx.EVT_ERASE_BACKGROUND, self.drawBackgroundAreas)
        self.panel.Refresh()
        pass

    def on_close(self, event):
        # Not sure why this is needed - resourceEditor doesn't appear to 
have an equivalent
        # but without this, we get attempts to use "dead" C++ objects
        self.panel.Unbind(wx.EVT_ERASE_BACKGROUND)
        event.skip()

    def drawBackgroundAreas(self, event):
        dc = event.GetDC()
        if not dc :
            dc = wx.ClientDC(self.panel)
            r = self.panel.GetUpdateRegion().GetBox()
            dc.SetClippingRegion(r.x, r.y, r.width, r.height)
        # need to set the background color to the default panel color
        brush = dc.GetBackground()
        brush.SetColour(self.panel.GetBackgroundColour())
        dc.SetBackground(brush)
        dc.Clear()
        for comp in self.components.itervalues():
            if comp.name[:12] == "colouredArea":
                dc.SetPen(wx.Pen(comp.backgroundColor, 1, wx.SOLID))
                dc.SetBrush(wx.Brush(comp.backgroundColor, wx.SOLID))
                x,y = comp.position
                sx,sy = comp.size
                dc.DrawRectangle(x,y, sx,sy)

Good luck ...

-- 
Alex Tweedly       http://www.tweedly.net

-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.338 / Virus Database: 267.9.9/62 - Release Date: 02/08/2005

Alex Tweedly wrote on 08/02/2005 06:01:08 PM:

> Another approach (not quite so simple, I'm afraid) would be to define 
> your own background handler (this idea and code stolen from the 
> resourceEditor's way of doing gridlines). This works fine (as far as I 
> can tell) on Windows - and should, I hope, work on other systems as well 

> (assuming the resourceEditor's gridlines work)

I tried it on my Mac and it worked great. Thanks, Alex! This seems like
a pretty good workaround to this problem. Since the image components
are invisible, they don't seem to cause any problems overlapping with
other widgets, and the colors are actually drawn on the panel itself.

The only drawback is that I can't easily see these colors in the
Resource Editor as I'm editing a layout. Eventually it might
be nice to have something like this integrated into PythonCard as a
new widget so that it could be handled specially by the Resource
Editor.

Thread: Re: [Pythoncard-users] colored rectangles

pythoncard-users