On Monday 03 December 2007 12:46:04 pm Nate Lowrie wrote:
> On Dec 3, 2007 12:27 PM, johnf <[EMAIL PROTECTED]> wrote:
> > Hopefully, everyone completely understands sizers - LOL.  I laugh because
> > I sometimes get confused using sizers.  But rest assured that you will
> > get the hang of it and most of the time it's easy.  Just play with them
> > until get what you want.  It also helps to draw a little picture of what
> > you want the form to look like before starting and you'll get there.  You
> > may have noticed I did not explain the use of a "grid sizer".   I didn't
> > because it really does not fit into this tutorial.  But I use the grid
> > sizer often.  It helps maintain "control/object" alignment on the form. 
> > Maybe later I (or someone else) can provide a demo using a grid sizer.
> >
> > In the Visual Fox Pro world (windows) Adrian's request of a demo to
> > "browse directories" would have taken but a short time to develop and
> > deliver.   I would create a form, add a label, add a textbox, and a
> > button to activate the open file dialog.  Maybe all of ten minutes.  Well
> > I just timed it and it took 12 minutes in Dabo (mostly because I can't
> > type – you'd think after twenty years I learn how to type).  Anyway, my
> > point is Dabo's framework ( and everything Dabo is built on wxPython,
> > Python) is just as powerful as VFP, VB and all the other languages.  And
> > in my mind it is more powerful because it's cross platform and one of the
> > easiest languages to read and understand. But I guess I'm singing to the
> > choir since those that are reading this are at least considering moving
> > to Dabo for those very reasons.
> >
> >  Sorry got off topic!
> >
> > Like all modern day languages the Dabo framework has events.  When the
> > user clicks on a button with the mouse an event occurs.  With Dabo you
> > have to "bind" the event to some action (function, method).     Most
> > languages do the same thing.  In java they are called event listeners, in
> > C++ they are called callbacks.  Some languages sort of hide the events
> > methods as in VFP where the event method is on a property page.  But you
> > can bet it is there somewhere.
> >
> > The first thing we need to do with Dabo is to import the list of events. 
> > I'm taking a minor short cut here.  I am naming 'dabo.dEvents' as
> > 'dEvents' just to save a little typing.  You should see the line near the
> > top of the program.
> >
> > import dabo.dEvents as dEvents
> >
> > So now we have a list of available Dabo events and we need explain how to
> > use them.  I'll show you the long way of binding an event.  I think it
> > better explains what is happening.  Maybe someone would like to post the
> > easy way to bind an event – all on one line of code.
> >
> > The next line of code assigns a variable "ourButton" for a Dabo button.
> > Notice that I have added a new attribute "RegID".  Every control/object
> > within the Dabo framework can have a "RegID" (or a name?).  It should be
> > unique and if you don't assign a "RegID" the framework will assign one. 
> > This is cool because it allows us (the programmers) to later reference
> > the object. Knowing the "RegID" I can later assign a value or change a
> > value or property of the object.
>
> Note that the RegID is just a shortcut.  So, if you have a form that
> has a button on it embedded deep within a tree, and you want to access
> it from the form you would normally have to type something to the
> effect of self.panel.pageFrame.Pages[0].myFirstSizer.control to access
> it.  With a RegID, you can just go self.control.
>
> Note that it is not always advantageous to use a RegID.  Since each
> control on a form needs a UNIQUE regID, if you have a panel class
> whose controls are declared with RegIDs that you use more than once in
> a form, you will get a bunch of errors.  Truth is, I rarely use RegIDs
> anymore, since I can normally encapsulate control functionality into a
> panel class.  Makes for cleaner code that is more modularized and
> refactored IMHO.
>
> Cheers,
>
> Nate L.

Right on Nate.  You are of course correct - specially if you consider the case 
of re-usable classes.  When Larry and I first started creating re-usable 
classes we ran into the problem.  The solution for us was to pass the 'RegID' 
when creating the instance of the class.  This worked for us because we liked 
the convenience of using "self.form.RegID".  In the future we may change the 
classes.  But it's hard to fix was works even if the code will be better.


-- 
John Fabiani


_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
Searchable Archives: http://leafe.com/archives/search/dabo-users
This message: http://leafe.com/archives/byMID/dabo-users/[EMAIL PROTECTED]

Reply via email to