[Gambas-user] refer to an object with a string

[Doriano Blengino]

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.

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.

Regards,
Doriano