Gary

>
> Which, with this control were specifically what?
>

?????? You mean which problems? Nothing that has to do with the Control itself. As with all ActiveX controls You are actually running another application.

When You use an activeX-Control like let's say the ctPush, You may imagine VFP cutting a rectangular hole in the form where the button "shines" through. Every other VFP-Object You might ever place on top of the button will "fall" into this hole and vanish (visibly). In the case of the button this is not really a problem as You hardly ever place anything on top of a button but using it in a pageFrame, You will realize, that it sometimes does not show or hide as You'd like it to.

Setting

this.OLEButton.Visible=.T.

or .F. for instance sometimes does not work as expected, if the button already believes it has this state.

this.OLEButton.Object.Visible = .T.

sometimes is the cure, sometimes not.

I found

this.OLEButton.Visible = .F.
this.OLEButton.Visible = .T.

(or was it this.OLEButton.Object.Visible) always working but it takes time to come to such a solution (and for me to accept that this is the way it is).

Little thing like that bite You, when You think "I'll do this in an afternoon".

Another problem is Subclassing. You can visually (i.e. VCX) create one Subclass, lets say Your BaseClass OLE-Button. But if You need an OK-Button a Cancel Button ... You either end up creating each class directly from the OLEControl itself, put it in a Container, or do the subclassing in PRG.

If You subclass each time from the Control itself, You will have to modify all Your Button-Classes when the issuer of the AcitiveX has the idea to change the interface (New Properties, Renaming Properties or adding a new Method)

Now, when You have a subclass of Your button in a VCX, You can add it to Your Form - fine. If You after a while decide "I am absolutely fed up with ARIAL" and change it to "TAHOMA", You Forms probably will say "But I still like ARIAL". Once Added to a form, changes will not be carried over to the form. That is because with OLE-Controls not only the non-default PEMS will be stored in the SCX, but also the complete OLE-Code. By that time all of Your buttons have code, Images, Text etc. and You cannot simply remove them from the form and drag the modified classes onto the designer.

A nice sideeffect is that due to all the OLE-Code, Your forms become bigger - not with one or two controls but I have a TouchScreen-Cashier that is covered with buttons.

Best thing You can do is subclassing in code and adding the controls at runtime. In the designer Your Form is almost empty and You need some coding to instanciate the buttons, adjust them properly, add the images etc.
This way however, You cannot write code in the CLICK-Event (which is not good anyway as I'll describe a bit far down).
So my OLEButtons received a Property "cCommand" that will be executed uppon the click. The code executed will then have to be in form-Methods or better in a Business-Object.

The really worst thing however is that, if an error occurs while in a method of an OLEControl (You call another form from the button's click and an error occurs in the init of the form) that leads to termination of the Application You will almost surely send a "Letter to Bill" as I call it. Sometimes if You're lucky the application just hangs and the processor goes up to 100%.

Same, when You have an error in a with ... endwith. In these cases You cannot get rid of the Object-Reference.
Dangling References is always a big trap when dealing with OLE-Controls.

Why? Imagine Your Button Click says something like

 local lcCMD
lcCMD = this.cCommand
&lcCMD

where lcCMD is something like "ThisForm.Save". If You have the debugger open (or simply think of the program-chain) You will see that as long as Thisform.Save is not terminated, You are still IN the Click of the button.

The solution to that is, leave the control alone as soon as You can. I don't know how others do this but my "really working solution" is that I employ a small timer that receives the "cCommand"

something like this in the Click

thisform.tmrAction.SetTimer(This.cCommand)

"SetTimer" keeps the command and enables the timer. then back to and out of the click. About 20ms later the timer fires ONCE and excecutes the command. By that time the button easily idles around and does not know (and care) whatever happens in the VFP-World.

You can really do cool applications using OLE-Controls and my Cashier smoothly runs for several years now in different places. But to make it cool and safe it takes a lot more work than with native VFP-Controls.