On Jan 4, 2007, at 8:26 AM, Dave Crozier wrote:
> 1. So far so good with Dabo. I've downloaded and installed Dabo and
> can now
> run all the demos no problem including the form with an SQL link
> onto Ed's
> site. A little bit of hassle getting everything working on XP but I
> managed
> and I'm going to write up an account of the software I used and how to
> install it as soon as possible to help any other converts.
Did you follow the Wiki page:
http://dabodev.com/wiki/InstallingRequirementsForWindows
If so, what worked and what didn't?
> Assuming I create a form Myform (a dabo.ui.dForm) and I thene
> create objects
> on the form called cmdButton1, cmdButton2 etc.
>
> Q1. After I have created these objects I can see them as cmdButton1
> and so
> on- no problem. Shouldn't I also be able to see them as
> self.cmdButton or am
> I thinking too much in a VFP way as in "Thisform.<object name>"?
From form methods, you can indeed refer to them by
'self.cmdButton1', etc. From other objects within the form, you can
refer to them by 'self.Form.cmdButton1'.
> Q2. If I have a form class method (for a lack of a better description)
Just 'method'.
> called Tester() coded in the form class definition,
Nitpicky Dabo-ism note: the naming convention for methods and
attributes is to begin them with a lower-case letter; classes and
properties start with upper-case.
> how do I reference these
> previous form objects by name? I only seem to be able to refer to
> them using
> self.Children[n] (n>=0). What am I doing wrong? I can see "self" as
> Myform
> so why can't I see them as Myform.cmdButton1 or self.cmdButton1?
I assume that you're talking about the Intellisense not finding
them? Or is it that when you run the form, the code cannot find them?
The Intellisense in the editor is far from perfect; for example, if
you add a method called 'tester' to the form in the Designer, and
then later type 'self.tes', you won't see your new method there.
That's because the Intellisense gets its information from the class
definition, not the instance being edited. That's something I'd love
to be able to improve, but it's a lot of work.
So for now, just type the names of the methods/objects that you know
are there, and hit Escape to kill the Intellisense popup.
> Q3. AAssuming I get an answer to Q2 if I first create a panel and
> then add
> objects to that panel as I would a container in VFP, how would I
> see the
> objects then as opposed to use the form self.Children[n].Children
> [p] in
> hierarchical way.
From the form, you would use 'self.<panelName>.<objectName>'. From
the panel, just 'self.<objectName>'.
This can easily get very hairy, so I added the ability for any
object to register itself with the form using a unique identifier.
This identifier, called 'RegID' (for 'registration ID') is
independent of the name, and must be unique across the entire form
(the Name property must be unique only among siblings in a
container). Name is also required, while RegID is optional. You can
then always refer to an object by '<formReference>.<RegID>'
So if I have a textbox on a page buried in 17 levels of various
containers, and I give that textbox a RegID of 'dave', I can always
refer to from anywhere else on the form using 'self.Form.dave'.
I just thought of one thing that could be an important difference
between Dabo referencing and VFP: the 'Form' property, akin to the
VFP 'Thisform', is defined as 'the form in which I exist' for a
control. So if you are in code for the form itself, 'self.Form' will
be None, since the form is not contained by another form. Contrast
that with VFP, where 'Thisform' in form-level code is the same as
'This'. Just thought that I'd mention it while we were discussing
references.
-- Ed Leafe
-- http://leafe.com
-- http://dabodev.com
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
