Form Class 2

[Scott24x7]

Hi All,
I think I've done this before, but I can't for the life of me figure it out again...
I have a form class (that I call Largeformbase), that I want to use as the basis for another class, but not a sub-class. I thought I could just open the formclass and "Save As" a new form, without making it a subclass, but I can't seem to get it to work. (I want to take some controls off of this one to form a different basis for some forms, without having to re-do the form from scratch). Is there some way to "copy" the class within the same class library, I just want to make Largeformbase something like Planeformbase... just can't seem to find how to do this?


Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."

 

[Mike Lewis]

Is there some way to "copy" the class within the same class library

Yes, but you have to use another class library as an intermediary:

1. Create a new class library within your project. Call it, say, Temp.VCX.

2. In the Project Manager, drill down into the original class library, and locate the class that you want to copy.

3. Drag it to Temp.

4. Within Temp, rename the class (right-click, and choose Rename from the context menu).

5. Drag the renamed class back to the original class library.

6. Delete Temp.VCX.

I think that should do it.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Scott24x7]

Mike,
Totally brilliant, thanks. So it wasn't something obvious I was missing, at least I feel better about that!
Cheers, you made my day.

Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."

 

[Mike Lewis]

Glad to help, Scott. This is something I've had to do several times myself. It's easy to forget that the solution isn't always obvious to everyone else.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Scott24x7]

I've actually copied your steps into a text file that I'm now saving in my VFP install directory so that I can keep these steps forever. It's rare that I want to do this, and I can see forgetting how to in the future. You should make this an FAQ!
Cheers,
-S

Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."

 

[Mike Lewis]

You should make this an FAQ

Yes, I'll consider doing that.

In the meantime, it occurs to me that you can also do the job programmatically, as follows:

ADD CLASS MyClass OF controls.vcx TO temp.vcx
RENAME CLASS MyClass OF temp.vcx TO MyNewClass
ADD CLASS MyNewClass OF temp.vcx TO controls.vcx
DELETE FILE temp.vcx

The only reason I discovered this was that the above commands (except the last) are echoed to the command window when you follow the steps interactively.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Instead of using a new temp.vcx you might "misuse" any other VCX just near the one with the desired class and drag and drop into this nearby VCX, rename, copy back and delete. After PACK of all VCXes the records you added and deleted will finally go away. Using a temp.vcx is cleaner.

I think there are some catches with special situations if the other VCX is in a different folder and objects within a class (not seldom for controls in form classes) point to yet other VCXes some of the classloc paths might get wrong.

What you actually should desire is a new intermediate level class, parent of the two almost similar classes, only composed of the common things. You can also get this by creating two subclasses, then cutting out part of the original class and paste that onto one of the new classes, the other one then doesn't inherit that.

Let's say you have a class with two textboxes (lets call this a) and some code for their behaviour, you want another one with a textbox and a combobox now. Then you create two subclasses (let's call them b and c). Now you open the original class a, cut out the text2 and save that, open b and see the previously inherited text2 is missing, as you cut it out, but you can now paste it back in. In the other subclass c you only have text1 and can add the combobox now. The two childclasses b and c both inherit from class a, which now may never be used, but is the logical parent of both forms with the common text1 control and behavior related to it.

It might not work out all the way always, but on top of having b and c you now have a parent of both classes and may think of further development to go in there instead of into both copies you have without a parent class. Even if a form with only text1 would never make sense this can be thought of as the concept of an abstract class, not fully functional but a common ground and template for the regular forms b and c.

Bye, Olaf.

 

[Mike Lewis]

Olaf, I take your point about "misusing" an existing class library, although, as you say, using a temp library is cleaner.

One thing that my programmatic version didn't show was creating the temp library. You would use CREATE CLASSLIB for that. Interestingly, that command creates an empty library. As far as I can see, there is no way of creating an empty class library interactively (is there?).

I suppose if you were doing this sort of thing a lot, it would be worth keeping a permanent temp library in existence, just for this purpose. (Hmm, not sure about "permanent temp library". Make that a permanent intermediate library.)

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Scott24x7]

Interesting, I didn't notice that taking place in the command window, but my focus was on what was taking place.

I wanted to avoid misuse just from the decades of VFP/FP experience that things can get weird, so the "clean" class was something that just intuitively made sense. It worked great anyway.
The main thing is I feel better knowing that I wasn't missing something obvious on some dropdown in "Tools", and that this is a little messy and unobvious.
But the result was great, I now have a clean, smaller version of the form that has most of the "background" stuff I wanted, and I could just delete the objects that I didn't want on the form. It's a great use to me.

It's funny I was today looking at a previous class library that I built circa 2002, and it had only 1 form in the baseforms library. Very funny. I have 10 now.


Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."

 

[Olaf Doschke]

>it had only 1 form in the baseforms library. Very funny. I have 10 now.
That looks like OOP progress.
Now, are those 10 forms all subclasses of one base form?
Besides having 10 form classes to start with for different purposes, if any of them is 1:1 used in your application, it's not a framework base form anymore, but a "system" form.
A typical framework would perhaps even not have 10 different base forms but it would have some non flat hierarchy.
for example a hierarchy could be baseform<-listform<-listanddetailform. Where listanddetailform inherits the listing data capabilities from the listformand adds a section for record details.

Bye, Olaf.

 

[Scott24x7]

Hi Olaf,
No they are not all subclasses of one base form. There are 3 (Largeformbase, codetablebase and superlargeform base) that are the same. The others (thanks to this trick too, which has a new form, which is a "cleaner" version of Largeformbase, but not a subclass) and a few others.

In moving to a Ribbon Bar interface, a couple of new forms have sprung up as well, which handle something similar to "tooltip text", but more robust and RTF based, (for example, open any office product, and hover over any button, and you get a "help" version below it), and a new menu form which (click any office product that has a "v" button to expand), and I've added something like that. They are very specific function and don't have all the typical "form" bits.

But yes, I've a few that are up to 3 levels deep from the base form, and they work like a charm.

Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."

 

[Mike Lewis]

In moving to a Ribbon Bar interface, a couple of new forms have sprung up as well, which handle something similar to "tooltip text"

Yes, I've got that as well. For what it's worth, mine is a single form which is always open but is normally invisible. It is made visible when the user rests the mouse on one of the relevant controls, then hidden when the mouse leaves the control.

But I haven't gone as far as you. Mine isn't RTF-based. It consists simply of a label which shows a heading (in bold), and another label which shows the tip text (not bold, but with wordwrap enabled). I have a separate Tips table which holds all the text. The controls have a TipID property which contains the ID of the relevant record in the table.

Most importantly, I have a master switch which lets the user turn this feature on or off. Most users seem to like these enhanced tooltips, but a few find them distracting.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

All I'm saying is that copying a class to modify the code hints on wanting another hierarchy level of a base class of which the two copies inherit from, so there is a central class to change both classes.

Bye, Olaf.

 

[Scott24x7]

Hi Mike,
Thanks for the continued discussion on this. The idea of making the form visible and invisible didn't occur to me. That might make the appearance a little better. I'm curious though, are you basing its appearance in relation to the control that it provides the help for?
-S

Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."