Manually Changing An Object's BaseClass 1

[stanlyn]

Hi,

I'm working on a form that has many textbox controls on it that are based on 3 different classes. I'd like to clean that up by making all their base classes the same single base class, WITHOUT first creating a new object based on the desired class, then copy all the pems, then deleting the original control. Is there a way to do this, as I dread manually replacing all those controls? Can this be hacked at a table level by "use name.vcx in 0", browse? If yes, please explain as I don't see how to do the controls...

Thanks,
Stanley

 

[TamarGranor]

You have several choices.

First, Thor has a tool that lets you replace an individual control with a different class and handles copying PEMs very cleanly.

Second, Rick Schummer's HackCX tool (

http://www.whitelightcomputing.com/prodhackcxpro.htm)

provides a nice interface for doing the work manually.

Third, you can, as you suggest, open the form as a table and manipulate it. You can ever write code to do that.

Tamar

 

[Olaf Doschke]

Even the native tool class browser allows you to redefine the class of objects. Just to illustrate it's already a feature of native VFP.

But just changing the class and classloc fields (which redefine does) has the risc of the Properties memo becoming invalid for the exchange class. You can fix errors by editing the Properties memo, too.

If you're sure the class you want to use has all the features (property names could vary, especially user defined properties), then an sql UPDATE of the vcx can be done. What needs change is both class and classloc fields.

Bye, Olaf.

 

[stanlyn]

Hi,

To confirm, this has to be done at the form level by hacking the .frx and changing the class and classloc fields of the records (objects that needs changed).

Thanks,
Stanley

 

[Olaf Doschke]

FRX? No. A report has no class and classloc.

I said SCX and VCX.

Class and Classloc is what the property window displays as Class and ClassLibrary (The ClassLibrary is stored with (if that works) relative path in the Classloc field and always displayed as absolute path, but doesn't matter much).

The baseclass itself, if you really mean that, is always a native VFP base class with no parent class, that's not settable, that simply comes out from whatever base class the root parent class is, so for example, if you have a _textbox class based on the native VFP baseclass textbox and then define a child class numerictextbox based on _textbox and a pricetextbox based on numerictextbox, then all those classes have textbox as baseclass. As that's set in stone you can't specify that separately, especially it's impossible the numerictextbox or pricetextbox become spinner controls, that will need the numerictextbox to be redefined as spinner or _spinner class (if _spinner is a spinner like _textbox is a textbox), and then inherits back to all child classes. That also means you can't specify some numerictextboxes to be spinners and others still remaining textboxes. It's always a tree hierarchy, that should be clear.

I think you really mean you want to change the class, not the baseclass, because the latter makes no sense and being able to set the former already allows you to get rid of separate classes and refactor them, so you can remove an unused vcx.

Bye, Olaf.

 

[Mike Lewis]

I second Tamar's recommendation for using Rick Schummer's HackCX tool. I've been using this for at least ten years. It is the easiest and safest way I know of rebasing objects.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Koen Piller]

Hi,

To confirm, this has to be done at the form level by hacking the .frx and changing the class and classloc fields of the records (objects that needs changed).

Good luck!!
Tamar gave you 3 options, and guess what you selected the most difficult way to do it! BTW .frx files are report files, forms have .SCX + .SCT and classes have .VCSX + .VCT files which you can easily ruin to achieve what you want.

Regards,

Koen

 

[stanlyn]

Hi,

Yes, I know they are scx and vcx files. I said frx because they are the only types I've been hacking for so long, so for me when we talk about hacking, its always a frx... sorry. Looks like going forward, I'll be associating frx, scx and vcx types to my hacking vocabulary.

I appreciate the suggested alternative solutions and did review the HackCX app. I selected the most difficult way for you, not me, as I have lots of experience hacking frx files, so simply changing from frx to scx is a matter of changing one char (f to a s). The other steps are identical with exception to their field names and values. I can surely and easily pull that off.

Thanks to all for sharing their knowledge,
Stanley

 

[Olaf Doschke]

It's a totally different beast, because things mean totally different things, but sure it's not so hard, it's just updating data. Actually hacking FRX in changing fonts and object types and positions needs some extra knowledge about what some object type numbers means and hacking SCX/VCX is easier in that aspect, if it's only about redefining classes of objects/controls.

There are pitfalls in there, too. I also hacked source code in the memo fields and you have to compile the changed form or classlib before reopening in the visual designers, because the splitting into methods of the designers editor doesn't merely split at PROCEDURE/ENDPROC lines. You can get strange side effects like having that PROCEDURE line itself in the code editor.

When you hack properties there is that name property, which redundantly repeats the objects name. Try changing it and see side effect creeping on you.

That's surely also a reason Tamar pointed out other tools like that of Thor and Mike mentioned HackCX.

Bye, Olaf.