Duplicate existing object? 4

[dunc0029]

Is there a built-in way of making a copy of an existing object? Maybe I'm just braindead and I can't remember. I realize you could loop through all properties and assign them individually, I was just wondering if there was a shortcut.

I'm thinking something like ...

o1=NEWOBJECT(<class>...)
o1.Name="Object 1"
o2=COPYOBJECT(o1)
?o2.Name && prints "Object 1"
o2.Name="Object 2"
?o2.Name && prints "Object 2"
?o1.Name && still prints "Object 1", since o2 refers to a separate object

 

[ramani]

HI

1. Are you talking about development time ?

Simply right click on the object, select copy and then paste it where you want. Rename that.

2. If you are talking about runtime..
NewObject() or CreateObject() syntax should help you.



____________________________________________
ramani - (Subramanian.G)

http://winnersoft.coolfreepages.com/

 

[dunc0029]

Ramani - thanks for the response.

I was hoping to do this at run-time. I did just find the CloneObject() Method, but that's only available at runtime. As you mentioned, I could create an object of the same class and adjust the properties to make the 2 equal, I was just looking for a shortcut. It looks like there is not a built-in way of duplicating an object.

 

[Olaf Doschke]

Maybe AMEMBERS() helps a bit.

Bye, Olaf.

 

[dunc0029]

I just re-read my last post. Typo on the "that's only available at runtime". I meant design-time, of course!

Thanks for the help - I think I have a workaround for now.

 

[jimstarr]

At runtime you can use SaveAsClass, then CreateObject.

Jim

 

[Olaf Doschke]

Hi jimstarr,

SaveAsClass is a cool idea.
Here's a small example for everyone

Local o1
Clear 
o1=CreateObject("custom")
o1.Name="Object1"
COPYOBJECT(o1,@o2)
?o2.Name && prints "object1"
o2.Name="Object2"
?o2.Name && prints "Object2"
?o1.Name && still prints "Object1", since o2 refers to a separate object

Procedure Copyobject()
   LParameters toSourceobject, toDestinationobject
   Local lcTempvcx, lcTempclass
   lcTempvcx = sys(2015)
   toSourceobject.SaveAsClass(lcTempvcx,toSourceobject.Name)
   toDestinationobject = Newobject(toSourceobject.Name,lcTempvcx)
EndProc

Well, it's an EXAMPLE. You'd have to add ERASE of the temp vcx file when the destination object isn't used anymore.
And it only works with classes, that have the SaveAsClass method of course. I think if you copy a form this way, you won't get the controls actual values copied and there would be several issues with controlsources, private data session etc. But for simple objects it could work.

 

[Olaf Doschke]

There should be a line before COPYOBJECT:

local o2

But the code works without it. Seem o2 is created the moment the code passes it with @o2 to COPYOBJECT. It's not new that you can work without defining variables, but I'd not recommend it and in this case I expected it would raise an error.

Bye, Olaf.

 

[dunc0029]

Olaf and Jim - thanks for the SaveAsClass idea. That's pretty slick.

 

[craigsboyd]

I agree with OlafDoschke, SaveAsClass is a cool idea for the problem at hand. Star to jimstarr for the idea and OlafDoschke for taking the time to flesh out an example. Thanks.

http://www.sweetpotatosoftware.com

 

[theThirdElement]

What a great method. I've been looking for the VFP counterpart of clone() in java and other OO languages. Many thanks to Jim and Olaf.

Just curious, how would one use that CloneObject() in design time? I don't see how that can be useful...

Cheers,

Ed

 

[theThirdElement]

After some pondering about copying objects, can I ask another question to the experienced: I've been using a lot of cloning and deep copies in java, c++, python etc, but in my short venture to VFP so far I don't seem to have used it or ever needed it in the way I used to.

So I'm wondering is it needed in VFP? Or is it because VFP isn't OO enough so we don't really use it (as we can just create a instance and then directly access/change the properties of the instance). Can someone give me a practical real world scenario?

Thanks,

Ed

 

[Olaf Doschke]

Hi Ed,

Well, copying objects or classes is not really OOP programming style, is it? It's a bit like using copy & paste with code, copying methods/functions/procedures. They are there to be called, not to be copied. And inheritance/subclassing is for reusing code, not copying classes. Copying always makes diversifications possible, which is normally not desired and could mean a great maintenance overload.

Back to the possibilities of copying an object or a class:
I showed you AMEMBERS(), which would create an array of the properties. There is also SCATTER and GATHER, especially with the NAME option. You cannot copy objects with this, but you can copy the contents of a record to an object, just having the field names as properties and you can GATHER the values of such an object back to another record.

If you really want to copy a class at design time, that can be done with drag & drop: Open the vcx to see it's classes and drag the class you want to copy to another vcx, finished. If you want a copy in the same vcx you have to rename that copy and copy it back to the original vcx, or again use saveasclass() of an instanciated object with a new name. And there is always a command to do the same:

CREATE CLASS newClassname OF classlib.vcx as oldClassname FROM classlib.vcx

Having trouble correctly overloading a class with a subclass? Just because foxpro doesn't show parent code in a child class, it doesn't mean it isn't there: Take a look at DODEFAULT(). To prevent Baseclass (lowest level) behaviour you can use NODEFAULT. And then there is the :: Operator. You can call a method on any class level of all your parent or parent.parent etc. classes with that. And you can make properties and methods public, private or hidden.

Not OOP enough?

Bye, Olaf.

 

[dunc0029]

In reply to theThirdElement, my original reason for wondering about this was trying to make an existing app more OO and 3-tier ( e.g. model-view-controller ). Specifically, this application tracks Long Term Care insurance. We have a policy table, and a policy segment table. Each policy can have several segments ( annual renewals ). Well, I was trying to rewrite the Renewal processing code in an OO manner. I want to take the existing, most recent, policy segment object, duplicate it, then change only the few properties that need changing ( Daily benefit amounts if inflation protection is selected, date ranges, etc. ). Sure, I could create a blank segment from scratch, but most of the properties/fields will be the same as the previous one.

Hope that's a decent example.

Jason

 

[Olaf Doschke]

Hi dunc0029,

maybe in this speacial case you should copy the record of the last annual renewal and then create the object to change those properties, that have to be updated for this year and not make it the other way around.

For your more general goal to implement model-view-controller, you should like BINDEVENTS. Besides all those other things I mentioned take a look at that.

Bye, Olaf.

 

[theThirdElement]

Thanks guys for your replies.

Jason,

I originally came across this thread looking for a solution to a problem similar to yours. It was to copy the properties of an instance (perhaps a better word for "object", which gets confused with classes), and then restoring the properties to that instance at a later time. I soon realised I can use AMEMBERS() and GETPEM() to do that, so my original intention of copying the instance isn't at all suitable in this scenario. And I think VFP is just great for implementing MVC sturcture.

Olaf,

I agree that copying classes is never a good OOP style. And yet I do think that cloning instances (not classes) is, at least it makes sure that by doing so the object being copied is encapsulated. The downside to it is that for deep copies it tends to be costly.

Anyhow there don't seem to be a direct call which will just automatically do the object cloning. Perhaps the only ways to do it is either by creating a custom copy constructor or use that AMEMBERS() and so on. I have even created a custom class that will do just that for an object, but only at a shallow copy level, I think.

I can now remember in one application written in python, where genetic programming is required, and I frequently copied instances. Or in Matrix...

Cheers,

Ed