On May 31, 2007, at 2:48 PM, Brendan Barnwell wrote:
> I'm having sort of the same problem I had before, which is that I
> can't find
> any information on how to set up simple GUI apps that DON'T require
> a database
> or a large collection of "records", but just involve a set of GUI
> widgets that
> interact with one another.
We don't have a wizard for doing this, but it isn't that hard.
Define your form classes, create your menus, and create a small
program that instantiates the dApp object and starts the ball rolling.
Here's probably the most basic app you can create:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
import wx
import dabo
dabo.ui.loadUI("wx")
import dabo.dEvents as dEvents
class TestForm(dabo.ui.dForm):
def afterInit(self):
self.Caption = "Example"
def main():
app = dabo.dApp()
app.MainFormClass = TestForm
app.setup()
app.start()
if __name__ == '__main__':
main()
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Obviously, you'd want to make your form more interesting than that,
but this should give you the general idea. If there is anything else
that would make things clearer, let me know.
> In simpleDemo2.py, I see that the slider's DataSource is set to
> the Caption of
> the label that displays the slider value. But this seems backwards
> to me --- it
> seems like what's really happening is the label is getting its
> Caption from the
> slider value. Then I found out that I can do a DynamicCaption so
> it does
> exactly that, but I'm curious what is going on with this setup in
> the demo.
The difference is one of push vs. pull. Dynamic* properties are more
of a "pull" approach, where controls determine their appearance
dynamically. But when using the DataSource/DataField approach is more
of a "push" from one object to another.
These props, as the name suggests, come from the need to bind data
to a control. What's important in a database app is the the control
knows how to get its value from the data source, but also how to
propagate updates back to that data source. So when a control changes
its Value, that change is "pushed" to the DataSource.DataField. While
this is primarily used to write changes back to a database, it's also
useful in tying together UI elements.
> At first I started thinking I could use a bunch of DynamicCaptions
> and stuff to
> get certain widgets to update based on the state of other widgets,
> but then I
> thought that would get really unwieldy. If I understand correctly,
> this is what
> a bizObj is for --- to serve as a sort of manager for the data from
> various
> widgets. What I'd like is to have an object (a bizObj?) that is
> linked to the
> widgets, so that, for instance, the current value of my number
> spinner is stored
> in myObj.spinValue and the current value of some other caption in
> the window is
> taken from myObj.getLabelText (which I can write as a method to
> manipulate the
> spinner data and output the value I want). However, I can't find any
> documentation that says "here is how you link a bizObj to a bunch
> GUI controls,
> and here is how you set up some GUI controls to put their data into
> the bizObj
> and others to take data out". All the bizObj stuff I see filled
> with database
> references that I'm not interested in for this application.
Bizobjs are really just for databases, although they can be used to
simply enforce rules (see the Bubblet demo for an example). But in
your case, it sounds like what you need is a common object that all
the controls on a form can relate to, and which can act as a mediator
for these controls.
There are two good choices for this, and it depends on scope. If all
the interaction to be managed is among controls on a single form,
then self.Form (i.e., the form itself) is the optimal choice for
managing interaction among controls. However, if you have multiple
forms that need to be managed, self.Application (the dApp object) is
the best choice for such a mediator.
-- Ed Leafe
-- http://leafe.com
-- http://dabodev.com
©2007 Ed Leafe |
