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

[Charlie Reinl]

Am Sonntag, den 16.08.2009, 19:08 +0200 schrieb Doriano Blengino:
> Jean-Yves F. Barbier ha scritto:
> > Doriano Blengino a écrit :
> >   
> >> Jean-Yves F. Barbier ha scritto:
> >>     
> >>> Hi list,
> >>>
> >>> I'm trying to refer to come couples Label/CheckBox that have the same suffix
> >>> (lbl_ONE & ckb_ONE) to enable/disable couple in one shot.
> >>>
> >>> But after building my strings that are orders, GB tell me its not an object:
> >>>
> >>> PUBLIC SUB lblckb_on_off(which AS String, on AS Boolean)
> >>>   DIM lbl AS String
> >>>   DIM ckb AS String
> >>>   
> >>>   lbl = "lbl_" & which & ".Enabled = "
> >>>   ckb = "ckb_" & which & ".Enabled = "
> >>>   IF onoff THEN   ' ON
> >>>     lbl &= "TRUE"
> >>>     ckb &= "TRUE"
> >>>     (SOMETHING TO "EXEC" THE STRING)lbl    (or may be: (SOMETHING)lbl = TRUE)
> >>>     (SOMETHING TO "EXEC" THE STRING)ckb
> >>>   ENDIF 
> >>> END 
> >>>
> >>> Is there a way to do that?
> >>>   
> >>>       
> >> The EVAL statement, but I never used it and also I am not sure it exists 
> >> in gambas2.
> >>     
> >
> > Yes it exists, however I'm not tough enough to tell if it can work that way
> >
> >   
> >> But there are other ways, more efficient. One is to find object handlers 
> >> using introspection. You can find all the children of a form and, based 
> >> on their name, do things (you can also scan all the children and, when 
> >> you find the one which has the right name, do the thing you want). The 
> >>     
> >
> > I don't see (may be you're talking about iterating form content is a Variant)
> >   
> 
> The following is a routine which transfers data from a form (or other 
> container) to a record of a database.
> The gadgets which are operated on are named like "edDBxxxx", where 
> "xxxx" is the name of the field in the database.
> This routine manages textboxes, checkboxes and other; i attach it 
> because you can see how to walk in a form,
> get the names and operate on gadgets:
> 
>     ' transfers a record from page to database; TRUE if error
>     PUBLIC SUB save_record(hCont AS Container, recmod AS Result) AS Boolean
>       DIM obj AS Object
>       DIM st AS String
> 
>       FOR EACH obj IN hCont.Children
>         IF obj.name LIKE "edDB*" THEN
>           SELECT Lower(object.Type(obj))
>             CASE "textbox", "tdbsimplebox"
>             recmod[Mid(obj.name, 5)] = obj.text
> 
>             CASE "tdbcalcbox"
>             recmod[Mid(obj.name, 5)] = utils.formatted2float(obj.text)
> 
>             CASE "tdbdatebox"
>             st = canonicaldate(obj.text)
>             IF st <> "" THEN recmod[Mid(obj.name, 5)] = Val(st)
>            
>             CASE "checkbox"
>             recmod[Mid(obj.name, 5)] = obj.value

	      default		
		'check here if it is a Container
		' if yes call save_record(obj,recmod)
> 
>           END SELECT
>         ENDIF
>       NEXT
>       recmod.Update
>       RETURN FALSE
> 
>       CATCH
>       Message.Error("Error " & error.Text & " in " & error.Where)
>       RETURN TRUE
>     END
> 
> 
> >> other one, which I would recommed, is to create dynamically you objects, 
> >> especially if they are many, and keep a reference to them using arrays 
> >> or collections. Or a mix of the two: you create a form visually in the 
> >> IDE, then in a routine collect all the handlers, and from then on you 
> >> always use those handlers. I suspect you are doing something very large...
> >>     
> >
> > No, in fact, not that big.
> > On 2nd thought, it wasn't a good idea (even if it has worked, code would have
> > been beeing too much obscur)
> >   
> I saw a "Label2572"... it seemed to me a little strange...
> And about obscure code, I think that well commented (and written!) code 
> is never obscure, but sometimes one writes code too much complex for the 
> purpose that has to be done. I sometimes do that...
> 
> Re-regards,
> 
> -- 
> Doriano Blengino
> 
> "Listen twice before you speak.
> This is why we have two ears, but only one mouth."