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




_______________________________________________
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