NewObject() not shown 2

[Koen Piller]

Hi,
Usualy I drag and drop my objects on my form but in this special case I need to instantiate the objects upon user condition so Addobject() should do it. However I dont seem to be able to show the new object on my form.
The (basic) command I use is:

loObject = NEWOBJECT("MyContainer","MyClass")
loObject.Backcolor = RGB(255,0,0)  && just to show I can manipulate the props of loObject
loObject.Visible = .t.

The MyClass.vcx lib was instantiated and contains a class MyContainer based on a container

My form shows, without the red container, what should I change in above basic coding?

Regards,
Koen

 

[Mike Lewis]

Koen,

I'm not sure what you are doing. Do you want to place the container on a form? If so, you need to uae the form's AddObject method, rather than the NEWOBJECT() function:

MyForm.AddObject("Mycontainer", "container")
MyForm.MyContainer.Visible = .T.

The way you are doing it, you are creating the container, but it just exists in memory. You are not placing it anywhere.

My apologies if I've misunderstood your question.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Koen Piller]

Mike,

You guessed right.
So I corrected my coding:

loObject = thisform.addobject('myContainer','myClass.vcx')

although the currentdir is the directory where myClass.vcx resides and although I had set

SET CLASSLIB TO "D:\foxexamples\nieuwe map (4)\myclass.vcx" additive

and
? set('classlib') responds with "D:\foxexamples\nieuwe map (4)\myclass.vcx" alias myclass

it errors: "classdefinition myClass is not found"

Grrr...

Regards,

Koen

 

[Dan Freeman]

The help file lists the parameters differently than you're using.

form.Addobject("ControlName","ClassName")

Your class is not named "myclass.vcx".

 

[Nigel Gomm]

the parameters to addobject are not the same as newobject()

assuming mycontainer is a class in myClass.vcx....

SET CLASSLIB TO "D:\foxexamples\nieuwe map (4)\myclass.vcx" additive
thisform.addobject('myContainer1','myContainer')
thisform.mycontainer1.visible = .t.

nigel

 

[Mike Lewis]

Alternatively, you can use the NewObject method (not the funtion), add specify the class library as the third parameter:

MyForm.[b]NewObject[/b]("Mycontainer", "MycontainerClass", "MyLibrary.VCX")
MyForm.MyContainer.Visible = .T.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Mike Lewis]

Koen,

Looking back at your original question, you say that you only need this container to be on the form under certain conditions, which is why you want to do this at run time rather than in the designer.

In that case, there is another approach. Place the container on the form at design time, but set its visibility to .F. Then, in the form's Init, evaluate the condition and set the visibility to .T. if appropriate.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Koen Piller]

Mike,
You are correct that would be the best solution however in this case it is unknown howmany objects will be shown it is up to the user, so I shall need the new- or addobject.
It seems newobject is faster.
Thanks,
Regards,
Koen

 

[Mike Lewis]

That's fine, Koen. It sounds like you are going about it the right way.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

I's all figured out, and in case of an unknown number of new objects using form.addobject() or form.newobject() is best, and you need one of these to let the object be a child of the form, otherwise it's not having a parent and doesn't belong to it, just because it was created in a method within it.

And to add a third possibility, you can add objects at design time and not just keep them invisible, you can avoid them getting instantiated at runtime by returning .f. from their Init(). But it's obviously a bad idea to foresee 10 containers of which some may not be initialized and then fail to have 11, if necessary.

There is one positive side to it very useful: You can program with it, have full automatic intellisense, even if at runtime the object will not always exist, that's more interesting with active components like optional handlers/managers attached to an application object, than with controls.

I identified a small quirk with that in thread184-1776850, but also tell how you can handle detecting the availability of such an object with TYPE() instead of PEMSTATUS() Another idea I have right now is how the Init() routine could not only let the object exist or not, but also take notice of it somewhere on the form level or on the level of the application object, if your application has one and that object scope is of general interest.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Koen Piller]

Olaf,
Thanks for the idea.
However meanwhile I will stick to the myform.newobject(). In this special case it is unpredictable to foresee how many objects the user could instantiate so your third proposal/possibility to instantiate a number of of objects is here not feasible. Newobject() is a generic useful command. I struggled with its syntax, mixing addobject() syntax with newobject() syntax. Mike, Nike and Dan cleared me correctly.
Koen

 

[Olaf Doschke]

Yes, my idea is not for your case, I explicitly said so, stopping the construction of an object at its init is more applicable when you have to do with single optional components, especially as you can only have a finite number of design time objects, but can add as many as you like (limited by screen size/memory of course).

I said it from two sides:
1. "using form.addobject() or form.newobject() is best"
2. "But it's obviously a bad idea to..."

I just added the concept, so you also know it in other future cases, where it applies.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Koen Piller]

Olaf,
Thanks.
Regards,
Koen