pythoncard-users Mailing List for PythonCard (Page 172)

On Thu, 07 March 2002, Dan Shafer wrote:

> 
> Patrick K. O'Brien wrote:
> 
> >
> >My only lingering concern about event attributes versus explicit handler
> >parameters is how the writer of the handler code knows what raw material
> >they have to work with. If the stub for the handler was automatically
> >generated, and contained relevant parameters like target, position and
> >keycode, then the user would have an idea that they should probably make use
> >of those in their handler code. But if all they get is an event object
> >(decorated or not) they don't get those visual clues. I suppose a docstring
> >could be generated, which could list the event properties. Or we just rely
> >on good documentation.
> >
> Well-put, Patrick, and a clearer way of saying what I (with far less 
> Python experience than you!) was struggling with. It is exactly this 
> issue that rises to the top of this kind of discussion for the embattled 
> Inventive User.
> 
> >
> >
> >---
> >Patrick K. O'Brien
> >Orbtech
> >
> 
> >
> 
> 
> 

And let me just third that opinion. I spent a fruitless couple of hours playing around with the wx event system last night and had to retire to the couch because my head was starting to throb too much. 

As Kevin says in his message wxPython is just hard to understand and anything we can do to make it more Pythonic is a good thing. 

I'm only half understanding this discussion (which half is a little unclear at present ;-) but shall bring my crushing ignorance to bear on the PythonCard event model. If I can understand what we have implemented (and I do so far) there is hope for us all.

Still, I might dive into the wx docs just one more time ...

Regards,
Andy

Dan Shafer brought up the issue about changes to the framework breaking
peoples code. I responded that this is alpha code, so I expect people to be
on the list and participate. That way they know when things are changing and
what they need to change to work with each revision. The samples and docs
will always be kept up-to-date.

So, if you're working on a project using PythonCard you should be on the
mailing list and let everyone know what you're working on. If you want to
make your project one of the samples that is a possibility too.

Other suggestions?

ka

If we want to go ahead and make the change, it looks like all the changes
could be checked in today.

I've looked at binding.py and added the following code (not checked into
cvs) that appears to work just fine. This goes into class
wxPython_EventBinding, method _dispatch around line 122 of binding.py. All
other _dispatch methods currently call this superclass _dispatch, so it is a
good place for common code, even if it isn't the cleanest possible solution.
Anyway, as a first test I added:

    def _dispatch(self, aWxEvent):

        eventType = aWxEvent.GetEventType()
        try:
            # all events should have GetEventObject()
            aWxEvent.target = aWxEvent.GetEventObject()
        except:
            pass
        try:
            # mouse and key events
            aWxEvent.position = aWxEvent.GetPosition()
            aWxEvent.x = aWxEvent.GetX()
            aWxEvent.y = aWxEvent.GetY()
        except:
            pass
        try:
            # key events
            aWxEvent.keyCode = aWxEvent.GetKeyCode()
            aWxEvent.altDown = aWxEvent.AltDown()
            aWxEvent.controlDown = aWxEvent.ControlDown()
            aWxEvent.shiftDown = aWxEvent.ShiftDown()
        except:
            pass

        ...

Different event classes: wxCommandEvent, wxMouseEvent, wxKeyEvent... have
different event attributes and methods, so that's why there are separate
try/except blocks. We have to decide which attributes we want to make
available and the names (i.e. 'target' or 'source', 'altDown' or 'altdown')
we want to use and what type the attribute will be. For example, which
modifier keys are down (alt, shift, control) could be a single list or
dictionary.

As I mentioned before, very few samples actually make use of the 'target',
so I can easily globally replace occurances of (self, target, event) with
(self, event) and (self, menu, event) with (self, event) and then update the
few samples using target.

ka

> From: David Primmer
>
> Well, I don't know how inventive I am but I just spent 4 hours trying to
> figure out how to write a custom event handler (and failed miserably).
> What gibberish all the docs are. Even with the boilerplate on wxPyWiki I
> couldn't do it. This isn't a help request. Just a rant. Sorry.

This is a recognized fundamental problem with "raw" wxPython and one of the
reasons the barrier to entry is so high. Also, what you are trying to do is
definitely in the advanced category. Every time I'm confronted with having
to do a custom event I have to ponder the docs and then copy and paste code
too. It certainly isn't something that just rolls off your fingers as you
type.

> I think experts forget that if you've never seen some version of code
> before, you can't infer what they meant when they give generalized
> examples and code out of context. I see examples on the lists that mix
> generic terms in the same block with specific implementations.
>
> I got some instructions from Kevin that said use "self.panel" and having
> never seen that object I thought he meant "replace the latter part of
> self.panel the name of your panel". I know now after just trying it but
> it didn't look right at first. If I'm any example, you're gonna have
> people using your framework who don't even understand what the words
> mean. It always helps to indicate if one should "type this exactly" or
> "replace with so and so"

Good point. On a mailing list in order to get a timely reply, the code or
suggestions people supply are typically not tested unless they have your
original code to modify against. That is a generic problem to all public
discussion forums. On the other hand, since we have the shell in PythonCard,
Patrick and I at least have been giving shell examples when possible where
you see the entire command to type as well as the result. I encourage others
to do the same. If I knew you had the cvs version of PyCrust instead of the
0.7 version that comes with wxPython, I could have told you to use
Ctrl+Shift+V paste the class definition and childframe creation.

Your comments are good to keep in mind for any docs that get written. Feel
free to point out confusing bits.

ka

> davep
>
>
> Dan Shafer
> > >
> > Well-put, Patrick, and a clearer way of saying what I (with far less
> > Python experience than you!) was struggling with. It is exactly this
> > issue that rises to the top of this kind of discussion for the
> embattled
> > Inventive User.
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>

Well, I don't know how inventive I am but I just spent 4 hours trying to
figure out how to write a custom event handler (and failed miserably).
What gibberish all the docs are. Even with the boilerplate on wxPyWiki I
couldn't do it. This isn't a help request. Just a rant. Sorry.

I think experts forget that if you've never seen some version of code
before, you can't infer what they meant when they give generalized
examples and code out of context. I see examples on the lists that mix
generic terms in the same block with specific implementations. 

I got some instructions from Kevin that said use "self.panel" and having
never seen that object I thought he meant "replace the latter part of
self.panel the name of your panel". I know now after just trying it but
it didn't look right at first. If I'm any example, you're gonna have
people using your framework who don't even understand what the words
mean. It always helps to indicate if one should "type this exactly" or
"replace with so and so"

davep


Dan Shafer
> >
> Well-put, Patrick, and a clearer way of saying what I (with far less
> Python experience than you!) was struggling with. It is exactly this
> issue that rises to the top of this kind of discussion for the
embattled
> Inventive User.

Patrick K. O'Brien wrote:

>
>My only lingering concern about event attributes versus explicit handler
>parameters is how the writer of the handler code knows what raw material
>they have to work with. If the stub for the handler was automatically
>generated, and contained relevant parameters like target, position and
>keycode, then the user would have an idea that they should probably make use
>of those in their handler code. But if all they get is an event object
>(decorated or not) they don't get those visual clues. I suppose a docstring
>could be generated, which could list the event properties. Or we just rely
>on good documentation.
>
Well-put, Patrick, and a clearer way of saying what I (with far less 
Python experience than you!) was struggling with. It is exactly this 
issue that rises to the top of this kind of discussion for the embattled 
Inventive User.

>
>
>---
>Patrick K. O'Brien
>Orbtech
>

>

Considering the fact that we are now married to wxPython (for better or
worse), I agree with your assessment and I like your solution. I think
decorating the event object to make it more PythonCardish would be better
than making the call to the handler adaptive. Looks good to me.

(And, yes, I think we can avoid __getattr__ and __setattr__ on wxEvent. But
it wouldn't be hard to do so if we change our minds.)

My only lingering concern about event attributes versus explicit handler
parameters is how the writer of the handler code knows what raw material
they have to work with. If the stub for the handler was automatically
generated, and contained relevant parameters like target, position and
keycode, then the user would have an idea that they should probably make use
of those in their handler code. But if all they get is an event object
(decorated or not) they don't get those visual clues. I suppose a docstring
could be generated, which could list the event properties. Or we just rely
on good documentation.

In any case, I'd like to keep exploring ways to make wxPython less opaque
and I see event handling as one area that could benefit from a bit of light.
It would be nice to be able to give event handler coders more dynamic tools,
but I'm not sure how we can do that at design time, rather than runtime. At
runtime we don't really have a way to get into an event handler from the
shell and poke around, if you know what I mean.

Does anyone follow what I'm trying to get at? Or am I suffering from the
fact that I've probably actually *used* PythonCard less than just about
everyone else on this list?

---
Patrick K. O'Brien
Orbtech

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Kevin
> Altis
> Sent: Thursday, March 07, 2002 2:24 AM
> To: pythoncard-Users
> Subject: RE: [Pythoncard-users] should we shorten the event handler
> argument list?
>
>
> Long reply, but there is an alternative solution at the end.
>
[snip]
>
> We could provide some extras to the native event instances prior to
> forwarding them to the user code. Without complicated wrapping we could
> simply add some properties for the most commonly accessed elements in the
> PythonCard event dispatcher.
>
>    event.target = event.GetEventObject()
>    event.position = event.GetPosition()
>    event.keycode = event.GetKeyCode()
>    ...
>
> That would be consistent with our component attributes and won't make the
> event instance incompatible with other wxPython methods. Of course, these
> attributes would not be settable, but that shouldn't be an issue
> because it
> is not generally necessary to set an event attribute in a
> handler, and when
> you need to you just use the normal setter method. [Note to
> Patrick, I don't
> think we want to try and modify wxEvent with __getattr__ and __setattr__
> code. ;-)]
>
> Whew, so does that make sense?
>
> ka

Kevin Altis wrote:

> Long reply, but there is an alternative solution at the end.
> 
> 
[snippage]


> 
> We could provide some extras to the native event instances prior to
> forwarding them to the user code. Without complicated wrapping we could
> simply add some properties for the most commonly accessed elements in the
> PythonCard event dispatcher.
> 
>    event.target = event.GetEventObject()
>    event.position = event.GetPosition()
>    event.keycode = event.GetKeyCode()
>    ...
> 
> That would be consistent with our component attributes and won't make the
> event instance incompatible with other wxPython methods. Of course, these
> attributes would not be settable, but that shouldn't be an issue because it
> is not generally necessary to set an event attribute in a handler, and when
> you need to you just use the normal setter method. [Note to Patrick, I don't
> think we want to try and modify wxEvent with __getattr__ and __setattr__
> code. ;-)]
> 
> Whew, so does that make sense?
> 
> ka
> 
> 

Works for me. I would like the target available as an attribute in my code, calling GetEventObject() doesn't appeal.


So count me as a vote for ' ...(source, target, event)' or 'event.target 
= ' whichever is easier to implement. I would suspect the latter is, but 
I defer to those who have actually written component wrappers.


Regards,
Andy
-- 
-----------------------------------------------------------------------
 From the desk of Andrew J Todd esq.
"So I curtailed my Walpoling activities, sallied forth and infiltrated
  your place of purveyance to negotiate the vending of some cheesy
  comestibles." - Monty Python.

>
>
>
>We could provide some extras to the native event instances prior to
>forwarding them to the user code. Without complicated wrapping we could
>simply add some properties for the most commonly accessed elements in the
>PythonCard event dispatcher.
>
>   event.target = event.GetEventObject()
>   event.position = event.GetPosition()
>   event.keycode = event.GetKeyCode()
>   ...
>
This solution sounds just fine to me and it sounds like it would work 
better from an implementer's perspective.

>
>That would be consistent with our component attributes and won't make the
>event instance incompatible with other wxPython methods. Of course, these
>attributes would not be settable, but that shouldn't be an issue because it
>is not generally necessary to set an event attribute in a handler, and when
>you need to you just use the normal setter method. [Note to Patrick, I don't
>think we want to try and modify wxEvent with __getattr__ and __setattr__
>code. ;-)]
>
>Whew, so does that make sense?
>
>ka
>
>
>_______________________________________________
>Pythoncard-users mailing list
>Pyt...@li...
>https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>
>

Long reply, but there is an alternative solution at the end.

> From: Dan Shafer
>
> In his description of when the event paramater is used, Kevin said:
>
> >The event source is most commonly referenced with
> >components that need to either inspect or modify themselves in
> response to a
> >user action such as a menu selection, list selection, choice
> selection, text
> >field key press, etc.
> >
> The viable alternative is to require the user to know that s/he must
> specifically reference the event object if it's needed.
>
> I think this design would add a layer of opacity to PythonCard as a
> linguistic framework. If I have a pre-defined method skeleton or model
> that explicitly provides the event source as a parameter, I can see that
> I can use that parameter in my code. But if that parameter is omitted,
> then I have to somehow know, without any clues in the code or
> documentation itself, that I can get the event source if I need it. Then
> I need to know how to get it.

This is one of the reasons I definitely don't want to omit 'event', so at a
minimum we always have something like:

    def on_showNotes_command(self, event):

Again, the arg list above appeals to me because it is what all native
wxPython event handlers expect.

> I think this has at least a slight bearing on our definition of who we
> see being the ultimate user of PythonCard. If we assume that person is a
> programmer of some skill and background, then this change is obviously
> fine. If, OTOH, we harbor dreams (as I do) of appealing to the
> HyperCard/dbase/Excel macro crowd with PythonCard, then I'd like to see
> the event source parameter left in for the clarity it brings to the
> coding process.

I would like to appeal to both crowds. The way to do that, if it is
possible, is for PythonCard to scale in the same way that Python does. The
Python language is fairly easy to learn for the beginner, yet it doesn't run
out of steam as you try and do more complex and bigger tasks. I think
wxPython provides the necessary flexibility and power at the more complex
end of the spectrum. The trick is how to provide a kinder, gentler, wxPython
if you will but somehow support the depth of the full toolkit if necessary
without the end solution having to be bolted on in some horrible way. We
should also try and leverage wxPython as much as possible and not try and be
different for equivalent functionality unless the underlying wxPython API
just seems horribly broken or difficult to use.

In the case of events we are already passing native wxPython events to the
user code event handlers. In addition, if your code needs details of an
event such as the key pressed or mouse position, you have to use the
wxPython event methods to get that info. Like some of the other changes to
the framework last fall this was partly driven by the desire to not have to
wrap the entire wxPython event system, which is quite large. Some of the
PythonCard samples are already using methods of the native wxPython event to
get the mouse position, key codes, modifier keys, and passing events. These
methods are wxPython methods for particular event classes. Examples include:

    event.Skip(), event.ShiftDown(), event.ControlDown(),
event.GetPosition()

Most of the time, these methods are not needed, except in the case of Skip()
which must be used for the dialog buttons of a modal dialog, so it can be
closed correctly.

Some elaboration is probably required to better understand the current
system. These are precisely the types of details that I hope most users will
never see, but you can't understand the event limitations in PythonCard
without understanding how wxPython works, so here's a little taste.

If you look at the Events section in the wxPython docs you'll see that there
are almost 40 event classes. Each one of these classes contains one or more
event binding "macros". For example, wxKeyEvent contains EVT_KEY_DOWN,
EVT_KEY_UP, EVT_CHAR. wxCommandEvent has all of the bindings for mouse
clicks and selections, the bindings that are typically thought of as default
actions for a given control. There are at least a couple hundred event
bindings in wxPython of which PythonCard currently only exposes mouse
events, key events, and command events for the currently supported
components. PythonCard also supplies a consistent set of simple aliases such
as 'mouseClick' so the user programmer doesn't have to remember that you
need to use EVT_BUTTON to bind to a wxButton, EVT_CHECKBOX to a wxCheckBox,
or remember the required arguments for the different types of event
bindings.

So, I guess what I'm saying is that we are going to be directing users
towards the wxPython event methods for certain info already and getting the
event source (target) is just another one of those methods.

We could provide some extras to the native event instances prior to
forwarding them to the user code. Without complicated wrapping we could
simply add some properties for the most commonly accessed elements in the
PythonCard event dispatcher.

   event.target = event.GetEventObject()
   event.position = event.GetPosition()
   event.keycode = event.GetKeyCode()
   ...

That would be consistent with our component attributes and won't make the
event instance incompatible with other wxPython methods. Of course, these
attributes would not be settable, but that shouldn't be an issue because it
is not generally necessary to set an event attribute in a handler, and when
you need to you just use the normal setter method. [Note to Patrick, I don't
think we want to try and modify wxEvent with __getattr__ and __setattr__
code. ;-)]

Whew, so does that make sense?

ka

Kevin Altis said:
>
> While I appreciate that it can be done, I don't think it should be done.
> 1. I don't want to omit the event argument. In fact, it would be extremely
> bad design to do so, since then you would have no way of getting the event
> object.

Not every handler needs this. If you decide you do need it, you just add it
to the arguments for your handler. Subsequent calls to the handler will send
the event object.

> 2. I would prefer to have one way of doing things. For example,
> even though
> it would be legal Python for someone to write:
>     def on_showNotes_command(s, t, e):
>         ...
>
> and then use those references in their method, this would simply make it
> harder to read each others code. I'm pretty sure that there is a Python
> coding guideline encouraging you to use "self" and I would like
> to encourage
> people to use the name "event" and for all handlers to have the
> same format.

You couldn't do what you suggest. The arguments are passed as keywords, not
positional. So the arguments would have to be spelled "target" and "event".
(Or "button" to match the case where you spelled it that way as well.)

> 3. Low-level Python mucking doesn't give me a warm fuzzy.

We already have a certain amount of mucking about to get use things like dot
notation and such. A little more can't hurt. I don't see the harm.

The idea is this, if you want to receive the event object in your handler,
include an argument called "event". If you want to also receive the target
as a separate object, include an argument called "target". If you don't care
about either of these, leave them out altogether. And if we decide another
parameter would be useful, we could add it without breaking any existing
handlers. This is very similar to supplying default values on parameters.

If this feature was built into the language I don't think anyone would
hesitate to use it. The fact that we have to muck about in some low-level
Python isn't the important issue to me. The important issue is whether this
makes PythonCard better or not. At first glance I'm in favor of it. But I'm
willing to debate it on its merits. If everyone else things it is confusing
or worse, then I agree we should leave it out. But we should at least
examine the issue, don't you think?

---
Patrick K. O'Brien
Orbtech

You've had a lot of discussion on intended user base so let me give you
my background. I consider myself the "HyperCard/dbase/Excel macro
crowd". This email turned out to be mostly about OO design and GUI
toolkits but I think it relates to the event handler question. 

I don't know the real implication for making this change but if it
simplifies the argument list it looks better to me. When you're new to
Python and learning about classes, all those (self) references can be
really confusing. GUI programming puts these foreign concepts right out
front. 

I think it's easier to design objects (or forms and controls) in a
visual way and it's easier to *see* selfhood or identity than typing it
in an argument and indicating it with words. After trying to learn C++
and staring blankly at a ".this" statement, (wondering what it was) and
finding that concept in other OO languages, I realized that is generally
the point where I loose focus of the design and spend most of my time
trying to read the damn syntax or trace identity.

That's not really about PythonCard but it is my perspective on using GUI
toolkits. I've been using them ever since Visual C++ 1.0 (but never
effectively) and I've never adopted one as a "general system programming
utility". I'm pretty good with computers and have a lot of skills but
after being a system administration professional for a few years and
scripting and "dumbing down" a lot of applications for users, I know
that there are tools for people who use them regularly or get paid for
it, and tools for part-timers. It's not a matter of how smart or dumb
you are. You just can't keep all the details of a system in your head if
you use it rarely. But there are ways to bridge the gap (being able to
round-trip between straight SQL and the visual query designer in
Microsoft Query is an example).

I think VBA as it's used in Word and Access and Excel is a very good
hybrid. The documentation is there and it's detailed, there are good
visual object browsing tools so that you can investigate lower level
stuff and see how things are connected if you're curious, and the editor
dumps you into the right place and the docs give you some sample code to
paste in and modify and then you're back to work on what you really want
to do. It's not crippled. Just look at the methods and properties on a
Word document object.

I know it takes a lot of work to duplicate Visual Basic but I do like
their form design tools. Drop the control, it hooks itself up, you pick
an event and it does mostly the right stuff. A year from now when
PythonCard is ready, .NET will be starting to happen. Assuming you can
afford .NET tools, why would you want to do a windows GUI on anything
else? I know how to do small scale database stuff pretty well but I'm
interested in more system-wide and internet-enabled programming tools.
This current interest in programming was a result of trying to move my
website content to XML. Python has a good focus on the internet, it has
good application glue and scripting, it has, from what I can tell, close
ties to XML. (I was hoping the XML API's would be as streamlined and
efficient as something like MS's ADO but I was way wrong). It's free.

I know Kevin has said he wants to stay away from code generators but
what's wrong with the way that VBA apps do it? What you usually do is
make a guess at which event you want to respond to (onbefore onafter
etc.) or trigger and then you pick it from a list and it writes the
skeleton of your event handler. All you really need is a good
representation of the order of events (for example, all the events in
sequence that fire when a window is created) and you can figure out
where you want to go.

My initial introduction to programming (except for using Basic in high
school) was in foxpro/dbase. That turned me into a one-off throw-away
type programmer (I'm not ashamed to admit it) - writing code to mangle a
unique piece of data into a standard format. Now that I'm using Python
I'm trying to learn re-usability, I'm shocked at how much I use "import"
but I almost never prototype with components. I cut and past pieces of
code the same way people steal javascript from other people web pages.
That's what has turned tons of graphic artists into web browser
scripters over the last few years. My artist friends who use Director
and Lingo and Flash are only object oriented when they have to be. They
primarily cut and paste code and I think that is where Python is going
to "out sell" Perl in the future. It's easier to cannibalize it like you
do in the HTML world (the one "language" that almost everybody knows).


Hope this helps. I'm ready to work on docs or web design or tutorials.
As you may have gathered from my verbosity, I'm professional writer.

davep

While I appreciate that it can be done, I don't think it should be done.
1. I don't want to omit the event argument. In fact, it would be extremely
bad design to do so, since then you would have no way of getting the event
object.

2. I would prefer to have one way of doing things. For example, even though
it would be legal Python for someone to write:
    def on_showNotes_command(s, t, e):
        ...

and then use those references in their method, this would simply make it
harder to read each others code. I'm pretty sure that there is a Python
coding guideline encouraging you to use "self" and I would like to encourage
people to use the name "event" and for all handlers to have the same format.

3. Low-level Python mucking doesn't give me a warm fuzzy.

ka

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of
> Patrick K. O'Brien
> Sent: Wednesday, March 06, 2002 5:53 PM
> To: pythoncard-Users
> Subject: RE: [Pythoncard-users] should we shorten the event handler
> argument list?
>
>
> We could support both/multiple signature styles at the same time. What we
> would do is inspect the arguments of the event handler to be called to see
> what arguments it expects and only pass it the ones it will accept. So if
> the handler includes target, we give it target. If not, we only give it
> event. If neither, we give it neither. And so forth.
>
> Here is the bit of black magic that will allow this adaptive calling:
>
> def _call(receiver, **kwds):
>     """Call receiver with only arguments it can accept."""
>     if type(receiver) is types.InstanceType:
>         # receiver is a class instance; assume it is callable.
>         # Reassign receiver to the actual method that will be called.
>         receiver = receiver.__call__
>     if hasattr(receiver, 'im_func'):
>         # receiver is a method. Drop the first argument, usually 'self'.
>         fc = receiver.im_func.func_code
>         acceptable = fc.co_varnames[1:fc.co_argcount]
>     elif hasattr(receiver, 'func_code'):
>         # receiver is a function.
>         fc = receiver.func_code
>         acceptable = fc.co_varnames[0:fc.co_argcount]
>     if not (fc.co_flags & 8):
>         # fc does not have a **kwds type parameter, therefore
>         # remove unacceptable arguments.
>         for arg in kwds.keys():
>             if arg not in acceptable:
>                 del kwds[arg]
>     return receiver(**kwds)
>
> The code is a bit hairy in that we must dive into the bowels of
> Python. But
> it works and gives a lot of flexibility that might be deemed worthwhile in
> meeting our goals of keeping things simple for newbies yet powerful enough
> for experts.
>
> So here is how your example event handlers could look:
>
>     def on_menuFileExit_select(self):
>         self.Close()
>
>     def on_goNext_command(self):
>         self.document.goNextRecord()
>
>     def on_showNotes_command(self, target):
>         if target.label == 'Show Notes':
>             self.components.Notes.visible = 1
>             target.label = 'Hide Notes'
>         else:
>             self.components.Notes.visible = 0
>             target.label = 'Show Notes'
>
>     def on_imagebtn_mouseClick(self, button):
>         log.debug('imagebutton-mouseClick:' + str(button))
>
>     def on_choiceGroups_select(self, target):
>         group = target.selection
>         category = self.components.choiceCategories.selection
>         self.displayTopics(group, category)
>
>     def on_listMenus_select(self, target):
>         self.displayItemAttributes(target.selection)
>
>     def on_listPosts_select(self, target):
>         # the first item is assumed to be the topic id
>         topic = target.getStringSelection().split(' ', 1)[0]
>         content = self.getContent(topic)
>         if content == None:
>             self.components.fldContent.text = ""
>         else:
>             self.components.fldContent.text = content
>
>
> ---
> Patrick K. O'Brien
> Orbtech
>
> > -----Original Message-----
> > From: pyt...@li...
> > [mailto:pyt...@li...]On Behalf Of Kevin
> > Altis
> > Sent: Wednesday, March 06, 2002 11:15 AM
> > To: pythoncard-Users
> > Subject: [Pythoncard-users] should we shorten the event handler argument
> > list?
> >
> >
> > In the examples at the end of this message, the event source is
> the second
> > argument in each method, the one between 'self' and 'event'. This
> > message is
> > about whether we should drop the second argument. I'm in favor
> of dropping
> > it.
>
>
> _______________________________________________
> Pythoncard-users mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>

We could support both/multiple signature styles at the same time. What we
would do is inspect the arguments of the event handler to be called to see
what arguments it expects and only pass it the ones it will accept. So if
the handler includes target, we give it target. If not, we only give it
event. If neither, we give it neither. And so forth.

Here is the bit of black magic that will allow this adaptive calling:

def _call(receiver, **kwds):
    """Call receiver with only arguments it can accept."""
    if type(receiver) is types.InstanceType:
        # receiver is a class instance; assume it is callable.
        # Reassign receiver to the actual method that will be called.
        receiver = receiver.__call__
    if hasattr(receiver, 'im_func'):
        # receiver is a method. Drop the first argument, usually 'self'.
        fc = receiver.im_func.func_code
        acceptable = fc.co_varnames[1:fc.co_argcount]
    elif hasattr(receiver, 'func_code'):
        # receiver is a function.
        fc = receiver.func_code
        acceptable = fc.co_varnames[0:fc.co_argcount]
    if not (fc.co_flags & 8):
        # fc does not have a **kwds type parameter, therefore
        # remove unacceptable arguments.
        for arg in kwds.keys():
            if arg not in acceptable:
                del kwds[arg]
    return receiver(**kwds)

The code is a bit hairy in that we must dive into the bowels of Python. But
it works and gives a lot of flexibility that might be deemed worthwhile in
meeting our goals of keeping things simple for newbies yet powerful enough
for experts.

So here is how your example event handlers could look:

    def on_menuFileExit_select(self):
        self.Close()

    def on_goNext_command(self):
        self.document.goNextRecord()

    def on_showNotes_command(self, target):
        if target.label == 'Show Notes':
            self.components.Notes.visible = 1
            target.label = 'Hide Notes'
        else:
            self.components.Notes.visible = 0
            target.label = 'Show Notes'

    def on_imagebtn_mouseClick(self, button):
        log.debug('imagebutton-mouseClick:' + str(button))

    def on_choiceGroups_select(self, target):
        group = target.selection
        category = self.components.choiceCategories.selection
        self.displayTopics(group, category)

    def on_listMenus_select(self, target):
        self.displayItemAttributes(target.selection)

    def on_listPosts_select(self, target):
        # the first item is assumed to be the topic id
        topic = target.getStringSelection().split(' ', 1)[0]
        content = self.getContent(topic)
        if content == None:
            self.components.fldContent.text = ""
        else:
            self.components.fldContent.text = content


---
Patrick K. O'Brien
Orbtech

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Kevin
> Altis
> Sent: Wednesday, March 06, 2002 11:15 AM
> To: pythoncard-Users
> Subject: [Pythoncard-users] should we shorten the event handler argument
> list?
>
>
> In the examples at the end of this message, the event source is the second
> argument in each method, the one between 'self' and 'event'. This
> message is
> about whether we should drop the second argument. I'm in favor of dropping
> it.

Patrick....

An interesting task. I did a little searching and found this public 
domain database (DBF format as far as I can tell) which might be a 
starting point for such an undertaking:

http://www.nationalatlas.gov/timeznm.html

Here's another site that offers a free database of time zone info, but 
it comes in three formats I've never heard of.

http://software.geocomm.com/data/intl_timezones.html



Patrick K. O'Brien wrote:

>Here is an idea for a PythonCard app. (Cuz I need this for my own app.)
>Create something that will take a phone number or address or ZIP Code, and
>will return the timezone. I've even got lat/lon on most of my records, if
>that helps.
>
>Anyone have any idea how to do this conversion? Or is there a web service
>that will do this?
>
>---
>Patrick K. O'Brien
>Orbtech
>
>
>_______________________________________________
>Pythoncard-users mailing list
>Pyt...@li...
>https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>
>

As the guy who is probably less a computer scientist than almost anyone 
else on this list, I thought I'd chime in here.

In his description of when the event paramater is used, Kevin said:

>The event source is most commonly referenced with
>components that need to either inspect or modify themselves in response to a
>user action such as a menu selection, list selection, choice selection, text
>field key press, etc.
>
The viable alternative is to require the user to know that s/he must 
specifically reference the event object if it's needed.

I think this design would add a layer of opacity to PythonCard as a 
linguistic framework. If I have a pre-defined method skeleton or model 
that explicitly provides the event source as a parameter, I can see that 
I can use that parameter in my code. But if that parameter is omitted, 
then I have to somehow know, without any clues in the code or 
documentation itself, that I can get the event source if I need it. Then 
I need to know how to get it.

I think this has at least a slight bearing on our definition of who we 
see being the ultimate user of PythonCard. If we assume that person is a 
programmer of some skill and background, then this change is obviously 
fine. If, OTOH, we harbor dreams (as I do) of appealing to the 
HyperCard/dbase/Excel macro crowd with PythonCard, then I'd like to see 
the event source parameter left in for the clarity it brings to the 
coding process.



Kevin Altis wrote:

>In the examples at the end of this message, the event source is the second
>argument in each method, the one between 'self' and 'event'. This message is
>about whether we should drop the second argument. I'm in favor of dropping
>it.
>
>When Rowland put together the first event handler system last summer I
>insisted that we pass the event source (target) of the event as one of the
>parameters to the event handler. In HyperCard terms, the event source is
>'the target' or if you had a script for a button or field you might have
>used 'me'.
>
>The main reason for including the event source was so that it would be
>simple to refer to in an event handler script. At the time, we were wrapping
>all events and planned to support toolkits other than wxPython. We had a
>getSource() method for events, but I thought scripts would be referring to
>the event target all the time and having to use an extra method call would
>be a lot of extra code.
>
>It turns out that based on the samples we have now, the event source is used
>infrequently. This might be due to the samples not covering a wide enough
>range of problems. The event source is most commonly referenced with
>components that need to either inspect or modify themselves in response to a
>user action such as a menu selection, list selection, choice selection, text
>field key press, etc.
>
>Since the 'event' argument is a native wxPython event rather than a wrapped
>event, you can always get the event source (if there is one), by using
>GetEventObject(). Prior to our change to direct subclasses of wxPython
>controls this wasn't particularly useful. But now the event source and the
>target are identical. You can test this yourself by creating a Button named
>'Button1' and trying this handler:
>
>    def on_Button1_mouseClick(self, target, event):
>        print target.name, event.GetEventObject().name
>        assert target == event.GetEventObject()
>
>So, while 'target' is less typing than 'event.GetEventObject()' it does mean
>that most of the time the user is having to type something extra, instead
>of:
>
>    def on_Button1_mouseClick(self, target, event):
>
>they could just be typing:
>
>    def on_Button1_mouseClick(self, event):
>
>Since we have switched to direct subclasses of wxPython controls and are
>using native wxPython events, there is another benefit to shortening the
>argument list, it will make our handlers compatible with direct wxPython
>event binding.
>
>The downside to removing the target or event source argument from the
>handlers is that all of the samples and documentation and web pages have to
>be updated to reflect the change and if you've gotten used to typing (self,
>target, event) then you need to start typing (self, event) instead.
>
>I can make the necessary changes for release 0.6.4 if everyone else thinks
>it is a good idea, it will just delay the release for a few more days, or we
>can wait to decide until after 0.6.4.
>
>As Andy expected, very little of my Jan 28 list is done, but we're making
>progress.
>http://aspn.activestate.com/ASPN/Mail/Message/PythonCard/1002210
>
>ka
>---
>example event handlers...
>
>    def on_menuFileExit_select(self, menu, event):
>        self.Close()
>
>    def on_goNext_command(self, target, event):
>        self.document.goNextRecord()
>
>    def on_showNotes_command(self, target, event):
>        if target.label == 'Show Notes':
>            self.components.Notes.visible = 1
>            target.label = 'Hide Notes'
>        else:
>            self.components.Notes.visible = 0
>            target.label = 'Show Notes'
>
>    def on_imagebtn_mouseClick(self, button, event):
>        log.debug('imagebutton-mouseClick:' + str(button))
>
>    def on_choiceGroups_select(self, target, event):
>        group = target.selection
>        category = self.components.choiceCategories.selection
>        self.displayTopics(group, category)
>
>    def on_listMenus_select(self, target, event):
>        self.displayItemAttributes(target.selection)
>
>    def on_listPosts_select(self, target, event):
>        # the first item is assumed to be the topic id
>        topic = target.getStringSelection().split(' ', 1)[0]
>        content = self.getContent(topic)
>        if content == None:
>            self.components.fldContent.text = ""
>        else:
>            self.components.fldContent.text = content
>
>
>_______________________________________________
>Pythoncard-users mailing list
>Pyt...@li...
>https://lists.sourceforge.net/lists/listinfo/pythoncard-users
>
>

I updated the documentation page on the main web site. The page points to
the new documents that Dan Shafer created for release 0.6.4. I'm still
making changes to walkthrough2.html. Comments and corrections welcome on any
pages on the site.

http://pythoncard.sourceforge.net/documentation.html

ka

> From: David Primmer
>
> I realize this isn't cross platform and therefore probably not directly
> supported in PythonCard, but I've using PythonCard for my app and I'd
> like a child window that has an IE activex control. I've modified the
> wxWindows IE sample and it's running as a simple frame with one sizer
> but it's not a PythonCard app.
>
> I have the information about making child windows (Kevin's post about
> doodle) but I'm not sure how to make a PythonCard app use a wxWindows
> app as a child. This code is close I'm sure:
>
> >         rsrc = res.ResourceFile('doodle.rsrc.py').getResource()
> >         self.doodleWindow = doodle.Doodle(self.stack,
> >                                           -1,
> >                                           rsrc,
> >                                           rsrc.stack.backgrounds[0])

That only applies to using another PythonCard background as a child window.
If you just want to use a plain wxPython frame as a child, you can use a
variation of a class like this:

from wxPython import wx

class ChildFrame(wx.wxFrame):
    def __init__(self, parent, ID, title, pos, size):
        wx.wxFrame.__init__(self, parent, ID, title, pos, size,
                         wx.wxDEFAULT_FRAME_STYLE | wx.wxFRAME_NO_TASKBAR)

        wx.EVT_CLOSE(self, self.OnCloseMe)

    # clicking the close box will only hide the window
    def OnCloseMe(self, evt):
        self.Show(0)

The actual class will be different depending on the type of window you want.
Then in your openBackground handler, create the child:

        self.child = ChildFrame(self.panel, -1, "child frame",
                                wx.wxDefaultPosition,
                                (200, 100))
        self.child.Show(1)


> So, I've tried to put the IE ActiveX control in a PythonCard
> background...
>
> I tried pasting the IE sample code in a Minimal app directly in
> on_openBackground and manually setting its size and position. But this
> doesn't work very well as you might guess because my component (bg.ie)
> is not described in the resource file. My guess is that it needs to be
> part of bg.components so that sizing works and it doesn't smash all the
> other controls on my background on a resize. In addition, no mouse
> events seem to get through to the browser window.

The problem is most likely that you have a layout where you probably want
sizers, which means that all of the components defined in the .rsrc.py file
and the controls you copied from the wxPython demo have to be part of your
sizer description. You can post your code and resource to the list and I'll
take a look at it. Attach the code/resource in a zip file.

self.components is just a dictionary of the components on your background
that provides dot notation access to each component, so you can do:
    self.components.btn1
instead of having to do:
    self.components['btn1']

If you place the IE control on the background, by making the parent of the
IE control self.panel then in terms of the window hierarchy it will be part
of the same panel as the rest of your components. In your openBackground
handler you would use a modification of the demo.py code:

        theClass = MakeActiveXClass(browserModule.WebBrowser,
                                    eventObj = self.panel)

        # Create an instance of that class
        self.ie = theClass(self.panel, -1, style=wxSUNKEN_BORDER)

I haven't tried that myself, but in PythonCard terms, self refers to the
background which is a wxFrame and self.panel to a wxPanel in the frame,
which is where the other components are actually placed. PythonCard normally
hides this detail from you, but since you want to mix "raw" wxPython and
PythonCard you need to be aware of what wxPython expects.

> Which is better? Use a child window that has no rcsc file and therefore
> not a PythonCard background or try to "port" the wxWindows code into a
> PythonCard background? Is it even possible to send messages to a
> non-pythoncard child window?

The simplest to code in the case of the IE control is to just use it as a
child window and not worry about having PythonCard event handlers or dot
notation for attributes, etc. Depending on what you want to do with the
control you might be able to just change the control directly. You can also
use wxPostEvent. See the wxPython docs and:
  http://aspn.activestate.com/ASPN/Mail/Message/633617
and then do some searches in the wxPython archives like this:

http://aspn.activestate.com/ASPN/search?query=wxPostEvent&type=Archive_Pytho
n

> Thanks a lot. I'm starting to get the hang of this stuff and I'm glad
> you folks are working on PythonCard.

Great!

> Ps. I want to be able to suggest PythonCard to my non-programmer friends
> one day. Any estimate on when it will a good newbie tool? 6 months? A
> year?

I guess that depends a bit on your definition and how motivated your friends
are. On SourceForge, the project development status is listed as Alpha and
we still have 'Prototype' in the package name. I think it is usable today
and we're slowly adding documentation. The problem for a newbie is that the
framework is changing quite a bit, so it is not appropriate for someone that
can't follow the changes as they occur.

I always keep the samples up-to-date, but if someone is working on their own
programs and not keeping up with the list or posting about what they are
working on then it is very likely they will find themselves with errors in
their source because the framework or resource file format changed. Until we
reach a Production/Stable release I don't think much effort will be put into
scripts to convert old source and resources to the current framework. I
expect PythonCard will continue to change and improve quite a bit over the
next six months to a year given the track record since last summer. That
could be speeded up if we get more developers, more samples from users and
more feedback from users on the features that are missing that they need
most.

ka

In the examples at the end of this message, the event source is the second
argument in each method, the one between 'self' and 'event'. This message is
about whether we should drop the second argument. I'm in favor of dropping
it.

When Rowland put together the first event handler system last summer I
insisted that we pass the event source (target) of the event as one of the
parameters to the event handler. In HyperCard terms, the event source is
'the target' or if you had a script for a button or field you might have
used 'me'.

The main reason for including the event source was so that it would be
simple to refer to in an event handler script. At the time, we were wrapping
all events and planned to support toolkits other than wxPython. We had a
getSource() method for events, but I thought scripts would be referring to
the event target all the time and having to use an extra method call would
be a lot of extra code.

It turns out that based on the samples we have now, the event source is used
infrequently. This might be due to the samples not covering a wide enough
range of problems. The event source is most commonly referenced with
components that need to either inspect or modify themselves in response to a
user action such as a menu selection, list selection, choice selection, text
field key press, etc.

Since the 'event' argument is a native wxPython event rather than a wrapped
event, you can always get the event source (if there is one), by using
GetEventObject(). Prior to our change to direct subclasses of wxPython
controls this wasn't particularly useful. But now the event source and the
target are identical. You can test this yourself by creating a Button named
'Button1' and trying this handler:

    def on_Button1_mouseClick(self, target, event):
        print target.name, event.GetEventObject().name
        assert target == event.GetEventObject()

So, while 'target' is less typing than 'event.GetEventObject()' it does mean
that most of the time the user is having to type something extra, instead
of:

    def on_Button1_mouseClick(self, target, event):

they could just be typing:

    def on_Button1_mouseClick(self, event):

Since we have switched to direct subclasses of wxPython controls and are
using native wxPython events, there is another benefit to shortening the
argument list, it will make our handlers compatible with direct wxPython
event binding.

The downside to removing the target or event source argument from the
handlers is that all of the samples and documentation and web pages have to
be updated to reflect the change and if you've gotten used to typing (self,
target, event) then you need to start typing (self, event) instead.

I can make the necessary changes for release 0.6.4 if everyone else thinks
it is a good idea, it will just delay the release for a few more days, or we
can wait to decide until after 0.6.4.

As Andy expected, very little of my Jan 28 list is done, but we're making
progress.
http://aspn.activestate.com/ASPN/Mail/Message/PythonCard/1002210

ka
---
example event handlers...

    def on_menuFileExit_select(self, menu, event):
        self.Close()

    def on_goNext_command(self, target, event):
        self.document.goNextRecord()

    def on_showNotes_command(self, target, event):
        if target.label == 'Show Notes':
            self.components.Notes.visible = 1
            target.label = 'Hide Notes'
        else:
            self.components.Notes.visible = 0
            target.label = 'Show Notes'

    def on_imagebtn_mouseClick(self, button, event):
        log.debug('imagebutton-mouseClick:' + str(button))

    def on_choiceGroups_select(self, target, event):
        group = target.selection
        category = self.components.choiceCategories.selection
        self.displayTopics(group, category)

    def on_listMenus_select(self, target, event):
        self.displayItemAttributes(target.selection)

    def on_listPosts_select(self, target, event):
        # the first item is assumed to be the topic id
        topic = target.getStringSelection().split(' ', 1)[0]
        content = self.getContent(topic)
        if content == None:
            self.components.fldContent.text = ""
        else:
            self.components.fldContent.text = content

I realize this isn't cross platform and therefore probably not directly
supported in PythonCard, but I've using PythonCard for my app and I'd
like a child window that has an IE activex control. I've modified the
wxWindows IE sample and it's running as a simple frame with one sizer
but it's not a PythonCard app.

I have the information about making child windows (Kevin's post about
doodle) but I'm not sure how to make a PythonCard app use a wxWindows
app as a child. This code is close I'm sure:  

>         rsrc = res.ResourceFile('doodle.rsrc.py').getResource()
>         self.doodleWindow = doodle.Doodle(self.stack, 
>                                           -1, 
>                                           rsrc, 
>                                           rsrc.stack.backgrounds[0])


So, I've tried to put the IE ActiveX control in a PythonCard
background...

I tried pasting the IE sample code in a Minimal app directly in
on_openBackground and manually setting its size and position. But this
doesn't work very well as you might guess because my component (bg.ie)
is not described in the resource file. My guess is that it needs to be
part of bg.components so that sizing works and it doesn't smash all the
other controls on my background on a resize. In addition, no mouse
events seem to get through to the browser window.

Which is better? Use a child window that has no rcsc file and therefore
not a PythonCard background or try to "port" the wxWindows code into a
PythonCard background? Is it even possible to send messages to a
non-pythoncard child window? 

Thanks a lot. I'm starting to get the hang of this stuff and I'm glad
you folks are working on PythonCard. 

Ps. I want to be able to suggest PythonCard to my non-programmer friends
one day. Any estimate on when it will a good newbie tool? 6 months? A
year?

davep

I made some fixes to debug.py and the resourceEditor to get rid of asserts
and other errors when using the hybrid version of wxPython. Unless other
problems are reported today, I think I'm about done with changes prior to
doing a 0.6.4 release.

The last thing on my list is to update Dan Shafer's second walkthrough
document

http://pythoncard.sourceforge.net/walkthrough2.html

to make sure it corresponds to the changes made in the last week to the
resourceEditor. This is an updated version of the counter tutorial that
includes screen shots and additional directions on building your first
PythonCard app. Comments welcome.

ka

sorry - that should have been back-channel.

At 05/03/2002 10:12:15, Roger Day wrote:
#  Do you have to sign up to some species of GPL before they let you graze?
#
#  At 05/03/2002 05:24:07, "Simon" <Si...@x-...> wrote:
#  #  The choice of a GNU generation.
#  #
#  #  http://savannah.gnu.org/
#  #
#  #  Get out, before it's too late.
#  #
#  #
#  #

Roger

Do you have to sign up to some species of GPL before they let you graze?

At 05/03/2002 05:24:07, "Simon" <Si...@x-...> wrote:
#  The choice of a GNU generation.
#
#  http://savannah.gnu.org/
#
#  Get out, before it's too late.
#
#
#
#
#  ---
#  Outgoing mail is certified Virus Free.
#  Checked by AVG anti-virus system (http://www.grisoft.com).
#  Version: 6.0.324 / Virus Database: 181 - Release Date: 2/14/2002
#
#
#  _______________________________________________
#  Pythoncard-users mailing list
#  Pyt...@li...
#  https://lists.sourceforge.net/lists/listinfo/pythoncard-users
#
Roger

Bravo, KA! Thanks for the information, it's a relief.

from,
Simon

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.324 / Virus Database: 181 - Release Date: 2/14/2002
=20

This is not exactly a new story. Simon, thanks for the heads up, but in the
future, you don't need to forward this kind of general issue to the list. A
number of developers on this list get SourceForge postings and also read
slashdot (part of the same group that does SourceForge) and other news
sources, so we'll all know when the walls come crumbling down, if in fact
that is what happens.

For PythonCard it won't be a disaster. We have very few developers and I
have all of the current files and major releases on multiple machines. We
aren't making much use of the tracker service. The main web site and mailing
list and cvs could be moved to other sites if necessary. The PythonCard
mailing list can probably move to the wxwindows list server since we use
wxPython for the framework. Wherever wxWindows and wxPython move their cvs
... we can probably follow.

I would be willing to pay a nominal fee for the services that SourceForge
provides, but so far they haven't requested that of the tens of thousands of
projects hosted on SourceForge. This is a much bigger deal for Python and
other large open source projects on SourceForge, the big projects will have
a harder time moving if they have to, but moving is still possible.

So, DON'T PANIC :)

ka

> -----Original Message-----
> From: pyt...@li...
> [mailto:pyt...@li...]On Behalf Of Dan
> Shafer
> Sent: Monday, March 04, 2002 9:18 PM
> To: Simon
> Cc: pythoncard-Users
> Subject: Re: [Pythoncard-users] Sourceforge... a nice place to park?
>
>
> Not a pretty picture. What are the alternatives?
>
> Simon wrote:
>
> >For your reading "pleasure".
> >
> >http://www.usatoday.com/life/cyber/invest/2002/01/15/askmatt.htm
> >
> >http://www.fsfeurope.org/news/article2001-10-20-01.en.html
> >
> >"For God so loved the world that he gave his only Son that whoever
> >believes in him will not perish but have eternal life." John 3:16.
> >
> >---
> >Outgoing mail is certified Virus Free.
> >Checked by AVG anti-virus system (http://www.grisoft.com).
> >Version: 6.0.324 / Virus Database: 181 - Release Date: 2/14/2002