[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