The common solution would be to subclass the label, alter it's INIT method and use NEWOBJECT or ADDOBJECT with additional parameters.
Normally sub classing for this is just a pain. And it should not be in the base class, because this will be called over and over for nothing.

I go for a simple a simple

loForm.Addobject("elbl"+Alltrim(Recno()), "label")
oLabel = EVALUATE("THISFORM.elbl"+Alltrim(Recno()))
oLabel.Move(...
oLabel.visible = .t.
WITH oLabel
 ....

or NEWOBJECT.

>You are probably correct. Still *just from syntax* it is the best way
>to sidestep the need for an init method defined for additional parameters,
>as named parameters are only possible via parsing wrapper and
>directly setting *only* non-default properties is good with add abject.
>
>Probably could be enhancement hacked in Vfp Advanced or Vfp-C-Compiler,
>as it only needs a pointer to start of object hierarchy and name, value pairs list,
>which can be resolved. OTOH in many dynamic building I can think of
>the use cases would benefit from defined added class with specific .init(),
>which here would have those 2 dynamic parameters from OP
>filled either in create or addobject(), rest done in define class defaults.
>
>>Don't think so, ADD OBJECT belongs to the DEFINE CLASS syntax, not to code running.
>>
>>>can be done in more ways...
>>>

>>>oLabel = createobject( "Label")
>>>with oLabel
>>>endwith
>>>loForm.Addobject("elbl"+Alltrim(Recno()), "label", oLabel )

>>>
>>>upd: not really certain if

>>>scan
>>>  cLabel = "elbl"+Alltrim(Recno())
>>>  ADD OBJECT ("loForm."+m.cLabel)  AS label WITH ;
>>>    Top = , ;
>>>    Left = , ;
>>>    Visible = .T., ;
>>>    Name = m.cLabel
>>>endscan