[Gambas-user] refer to an object with a string
Jean-Yves F. Barbier
12ukwn at ...626...
Mon Aug 17 23:16:24 CEST 2009
Doriano Blengino a écrit :
> Jean-Yves F. Barbier ha scritto:
>> Doriano Blengino a écrit :
>>
>>> I didn't want to say that Label2572 is obscure code: instead the first
>>> thing that came to my mind is "how many labels are in this form?".
>>> So I pointed out that perhaps dynamic construction of gadgets would have
>>> been useful to you.
>>>
>> Ha, ok (at first, I intended to put label2445316, hopefully I didn't: I would
>> have been responsible from a stroke;-)
>> I you could point me to an example it would be nice, because I really don't get
>> the interest of on-ze-fly construction (seems complicated, what pros? what cons?)
>>
> I think there are two cases when dynamic construction comes in place.
> The first is when you have many widgets sharing most of their
> properties. Instead of drawing them in the IDE, one can make a cycle and
> create them on the fly. If you have, say, eight buttons all similar, you
> can do something like (not tested code listing):
>
> public sub create_buttons()
> dim abutton as Button
> dim i as integer
>
> for i=1 to 8
> abutton = NEW Button(ME) as "mybutton" ' the as... is for
> event handler
> abutton.x = 20
> abutton.y = i*20 + 50
> abutton.text = "Button #" & i
> abutton.tag = i
> next
> end
>
> public sub mybutton_Click()
> print "You pressed button #" & LAST.tag
> end
>
> This example is just a simple one - one can also create 8 buttons in the
> IDE. But, if after some try, you decide to change the text of the
> buttons, you must change 8 items, while you could change a single line
> in code. In this example the variable abutton is used over and over, so
> it only keeps the last created button (and goes out of scope at the end
> of the sub). But using an array, one can "remember" all the created
> buttons, and operate on them through for-next cycles. Using a constant
> declaration (MAX_BUTTON as integer = 16), one can, by changing just a
> value, have 2, 4 or 12 buttons, at will. Clearly, this approach has an
> advantage only if the logic of the program requires this.
> I rarely used this, though.
Ok Doriano, now I see what you meant.
> The second case is when you want to have several instances of a form (or
> something else). For example, I recently wrote an accounting program,
> with a dozen forms. Through the menu you open those forms, but they are
> "swallowed" inside a tabstrip. So I can start to make an invoice; from
> there, I can open the customers table to browse for a name; if someone
> asks me to produce quickly another invoice, I open another instance of
> the invoice form. At this point I have two invoices open, created
> dynamically. I can also cut/paste data between them. It goes like this:
>
> ' a menu item click to create an invoice
> PUBLIC SUB mnInvoice_Click()
> DIM ht AS Object
>
> IF swall() THEN RETURN ' create a new page in tabstrip -
> refuses if too much of them
> ht = NEW fmInvoice(tsMain) ' create dynamically the new form,
> child of the tabstrip
> END
>
> This is a sort of MDI (multiple document interface), only the documents
> are all kept in a tabstrip.
This is very interesting and will be useful for my next project (ERP+accounting)
As a matter of fact, I was seeking for a manner to do exactly what you just
explained: beeing able to create/modify/... multiple instances of a kind of
document at the same time :)
Thanks again
JY
--
If women didn't exist, all the money in the world would have no meaning.
-- Aristotle Onassis
More information about the User
mailing list