How to rethink functions, and a little background

[true911m]

I come from a Structured Programming background, and I fall back to old habits sometimes, because they were efficient in their context. But I'm trying to find context here.

In my last environment (Superbase), which was a mess in some ways, I had the flexibility to encapsulate code in OO constructs, or simply to drop oft-used chunks into subroutines, which had NO scope restrictions, and could be loaded on demand.

What I'm trying to do today is to better understand the wx.lib.printout collection in wxPython by wrapping convenient parts like basic setup, final print, etc. in simple -- really simple -- function calls.

The problem with scoped functions is that I have to place all those setup variables (PrintBase, PrintGrid, PrintTable, etc.) in my main app prior to calling the routines. I don't want to do that for two reasons: It stinks of cut-and-paste activity, and it's inelegant.

In this case, it's a couple lines of code, and no biggie, so consider it an academic exercise. To use the full functionality of this module, it's not so trivial, and consumes tons of whitespace in a language that doesn't tend to go that way. The last thing I'd prefer not to do, because all my sloppy VB buddies used to do it, is declare everything global just to get the job done.

So at the core, I would like to have simple, callable functions that initiate wx.lib.printout parameters at the beginning of my main calling app that can be later referenced by the wrap-up printing routines without declaring stuff all over the place.

Can it be done?

Seeya,

[bartonc]

In a word "yes". I wish that I had pencil and paper (a picture being worth a thousand words (and there's a 10000 character limit in these forums)). Here's my example (I haven't played with the printout lib yet):

My mainFrame has textCtrls for data entry and display of data being collected via USB all of which get stored in a SQL database when the user hits the Record button. So my mainFrame requires a USB connection object and a database connection object. Of course, each of these needs lots of their own varibles to setup and maintain these connections plus GUI's for user interaction (password, etc). No problem: Subclass frame (or Dialog in my case) in a separate module, define any "global" values needed by this class (I often set DefaultValueFor EntryWidgetXYZ) in the module scope and "getter" fuctions in the class scope. Are you with me so far? In this case, the mainFrame imports the workerFrame and instantiates it in its __init__ function. I use menus to show these frames (which seems pretty natural - especially for "print").
Now, what about the case where another Frame needs access to that instance?
I this example, a third "calibratio n" frame needs access to data comming from the USB and to the database for storing the calibration data. The mainFrame is the "parent" for all these subframes, so that's where I define things like GetDatabaseServ er() so that the subframes can call db = self.parent.Get DatabaseServer( ), etc. Now the subframe has access to all the functionality of the dbServer. There is no need to import the module defining the dbServer class in the subframe module. Getting data which is actively changing is a whole other discussion, but I have implemented a version of what Robin Dunn calls Model-View-Controler model in his book wxPython in Action.
I'll post some examples. Keep posting,
Barton

[bartonc]

Here are links to examples:
Dialog instantiates dbServer
another dialog get the instance
mainFrame ties them together

[true911m]

Wow, great.

I'm sure I need to read that a couple more times and play with it to get the full content. From first read, though, I'm seeing an instance of a separate class that, when initialized, takes care of all those annoying startup values in some default sense, while also easily accomodating changes to one or two (or more) customizations as needed. Effectively this instance becomes a "global variable holder" for the processes that will ultimately need those values to function.

This will give me something to chew on for awhile, thanks!

[bartonc]

Wow, great.

I'm sure I need to read that a couple more times and play with it to get the full content. From first read, though, I'm seeing an instance of a separate class that, when initialized, takes care of all those annoying startup values in some default sense, while also easily accomodating changes to one or two (or more) customizations as needed. Effectively this instance becomes a "global variable holder" for the processes that will ultimately need those values to function.

This will give me something to chew on for awhile, thanks!

That's exactly it.
I think that you have grasped the essentials of oop in python.
You are welcome,
Barton