OleControl turns in Formset

[SteveDingle]

Heya All,

All my work is already lost :-( and doubt it's happened to anyone else but figure I would ask in case its something I'm doing wrong.

VFP 9 SP1 - DBITECH ctTree latest (Treeview control)

Created a subclass, worked hard adding method/properties etc.. to make it easier to re-use and setup via metadata and then it crashed. Seemed like it crashed while VFP was doing a IntelliSense lookup. (i.e. happend after first "(" in method call )

I had saved and tested it multiple times throughout the day

I closed VFP, reopened it and low and behold, my "OleControl" is now a formset with absolutely nothing in it.

FWIW, I normally put actx controls in containers, which would have saved me hours of re-work but anyway...

Anyone ever have anything like this?

Toodles,
Steve Dingle

http://www.dsbusinesssolutions.co.uk

D&S Business Solutions Ltd

 

[DSummZZZ]

Oh, h*ll yes. Not enough times yet for me to make regular back up copies several times thoughout the day (I still haven't smartened up that much I guess), but enough that I make daily or weekly backups.

I've found forms are not that hard to corrupt. Even while working on them I've had them get confused and switch code from other methods, or even load the compiled version of method code instead of human readable.

So don't feel all alone.


-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[Mike Lewis]

Steve / Dave,

Is this problem specific to the DBITech control, do you know, or is that just a side issue?

The reason I ask is that I am planning on using those controls quite extensively in my next project. If this is going to be a problem, better that I know now.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[SteveDingle]

Heya Mike,

I don't know as I am only using DBItech. FWIW, I can't imagine this would be a control specific thing. VFP must have somehow corrupted the VCX file. Its the only explanation I can find.

When you do use them though I do recommend you embed them in containers and use that as wrappers to the DBI control. If I had done that I am assuming I would have only lost the DBI control portion and the event code which called container methods.

I've always like that approach also because if you ever decided to use different activex control, at least the "interface" would remain the same

Just my .02p

Toodles,
Steve Dingle

http://www.dsbusinesssolutions.co.uk

D&S Business Solutions Ltd

 

[Mike Lewis]

Steve,

When you do use them though I do recommend you embed them in containers and use that as wrappers to the DBI control.

That's good advice. In fact, it's what I normally do with third-party controls.

Come to think of it, it was you who first told me the benefits of doing that, many years ago now.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[SteveDingle]

Heya Mike,

Quite possibly, dunno why I didn't follow my own advice this time :-( Will when I start all over again. FWIW, feel free to give me a shout if you have any questions about teh DBI controls, been working with then for quite a few years

tc,
Steve

 

[Scott24x7]

I've heard of this before, but don't understand why you would do it, and how to go about it... can you explain the benefits and how to deal with such a thing? I really don't put anything into containers, and dealing with containers feels like a level of "hassel" that seems unnecessary. What am I missing?


Best Regards,
Scott

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

 

[SteveDingle]

Heya Scott,

The reason I initially started doing it was because I had changed from using the MSFT treeview to use the DBI treeview control. Of course this meant that for each place I had used the treeview I had to change and recode.

Also, I found that sometimes when I had an activex control in a form class, then subclassed that form class, then subsequently change propeties of the control in the parent form class, those changes would not flow down into the subclass (propeties like backcolor or font for example)

At that point I decided that i would have minimum code in activex control them selves and always use a contraier as the interface into the control and it always contained the code to "setup" the control.

While it is/seems like an extra layer.. it allowed me to create an interface that worked best for me. It also allowed me to make properties/methods consistent across classes and hide what I often see as complexity in using some activex controls.

This might not be a "best practice" and over the years others have disagreed but its worked for me [shrug] and this morning I wish I would have done it that way to start ;-)

tc,
steve

 

[Mike Lewis]

Scott,

A few years ago, a client of mine was trying to decide what sort of control to use for grids: the native VFP grid, a Listview or the DBI grid control.

I discussed this with Steve, and he advised that, whichever one he chose, he should put it in a container -- and, importantly, put all the custom properties and methods at the container level. That way, you could hide the details of the class from the developer using it.

It turned out to be good advice. It meant that, whichever control the client chose, he could easily switch to a different one later, just by changing the contents of the container.

A bit later, I decided to create my own Simplelist control, which is essentially a wrapper for the Listview. By putting it in a container, not only did I get the benefits mentioned above, but it also enabled me to encapsulate the two Imagelist controls that the Listview uses. That way, any developer using my class would only have one control to worry about (one control to drop on the form, one lot of properties and methods) rather than three.

Give it a try.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[Mike Lewis]

Steve,

feel free to give me a shout if you have any questions about teh DBI controls,

I'll do that. I'm familiar with their grid control (see my reply to Scott above). I've often wanted to use some of their other controls, but clients are often cautious about too many third party components in their apps.

What tipped the balance in favour of DBI was the announcement that some of their controls are going to bundled in the next release of VFP. This is not just a question of saving money -- it means that, by being part of the product, they have become sort of "mainstream", and therefore more acceptable to clients.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[Scott24x7]

Steve,
Ah... I think I'm getting it now... you recommend this particularly for ActiveX controls, but not necessarily for just any control. I see how, from an inheritance stand point now, that there are advantages to this, as well as practicing "Safe X". Put it in a wrapper...



Best Regards,
Scott

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

 

[Mike Lewis]

Scott,

Yes, that's pretty well right.

You can (up to a point) think of this technique as an alternative to subclassing. They both introduce an extra layer which can insulate you from the internal workings of the control.

With native VFP controls, you would always use subclasses. You could do that with ActiveX controls as well, but the container approach is often simpler.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[Scott24x7]

Mike,
Yeah, I ALWAYS subclass VFP controls. Have had little need for ActiveX controls to date. I think I'm using an ActiveX for RTF in one application, but because the VFP report writer has never supported RTF at the Form level, I've abandoned it... looks great on screen, but if I can't print it later it's no good to me.
But, I see the truth of it. Very clever. Anything to be "wary of" or "Gotcha's" with it?


Best Regards,
Scott

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

 

[Mike Lewis]

Scott,

Anything to be "wary of" or "Gotcha's" with it?

Nothing special that I can think of.

If you want to seen an example, you can grab a copy of my Simplelist control from

http://www.ml-consult.co.uk/foxst-28.htm.

You'll see that the container encapsulates three ActiveX controls, and that all the PEMs that the developer needs to know about are on the container, not the controls themselves.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[Scott24x7]

Mike,
Very cool... thanks for that.


Best Regards,
Scott

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