Board index » cppbuilder » Why does BCB3 force ActiveX control creation from VCL control

Why does BCB3 force ActiveX control creation from VCL control

The BCB ActiveX control wizard forces me to derive a control from an
existing VCL component only.

Why cant i create a ActiveX control which doesnt derive from any VCL
component.
Some kinda bare bone control which i wanna write from scratch.

Even VC++ allows me to do this. I do agree BCB is better than VC++,

But Please lemme know abot this stuff. It will be of great help!
Also BCB3 forces the use of ATL for this kinda work.
And i dont know ATL.

VC++ allows me to write a ActiveX control from scratch without using
ATL!

Thanks.

 

Re:Why does BCB3 force ActiveX control creation from VCL control


I guess the reason is that BCB is used for rapid development of visual
applications. And it only makes sense to derive from VCL forms when
doing that. You can always write bare-bone C++ COM code if you need to.

Alex

Quote
Roshan wrote:

> The BCB ActiveX control wizard forces me to derive a control from an
> existing VCL component only.

> Why cant i create a ActiveX control which doesnt derive from any VCL
> component.
> Some kinda bare bone control which i wanna write from scratch.

> Even VC++ allows me to do this. I do agree BCB is better than VC++,

> But Please lemme know abot this stuff. It will be of great help!
> Also BCB3 forces the use of ATL for this kinda work.
> And i dont know ATL.

> VC++ allows me to write a ActiveX control from scratch without using
> ATL!

> Thanks.

Re:Why does BCB3 force ActiveX control creation from VCL control


Does that mean i cant use the ActiveX control Wizard To write a new control
!
That's a little hard to digest I'd say.
It isnt always necessary that i need to write a control tahts based on the
VCL.
Also It doesnt Allow me to subclass those TCustom*  ones.

It is understandable that BCB is RAD. But then It is up to the the
programmer to decide whether His control needs to be subclassed from a
existing control.

What if the VCL doesnt provide the right kind of control from which u need
to derive !
So then I will have to resort to non RAD style development if i have to
write a ActiveX control inspite of using BCB.

I dont understand why u say that-- " It only makes sense to derive from VCL
" !
Writing simple ActiveX control that have nothing in common with the VCL are
routine i say !

//-------------------------------------------------------------------------------------------------

Quote
Alex Bakaev [TeamB] wrote:
> I guess the reason is that BCB is used for rapid development of visual
> applications. And it only makes sense to derive from VCL forms when
> doing that. You can always write bare-bone C++ COM code if you need to.

> Alex

Re:Why does BCB3 force ActiveX control creation from VCL control


Quote
Roshan wrote:
> What if the VCL doesnt provide the right kind of control from which u need
> to derive !
> So then I will have to resort to non RAD style development if i have to
> write a ActiveX control inspite of using BCB.

> I dont understand why u say that-- " It only makes sense to derive from VCL
> " !
> Writing simple ActiveX control that have nothing in common with the VCL are
> routine i say !

It's almost invariably easier to implement a custom control as a VCL,
derived from TCustomControl or TGraphicControl, than to write a raw
ActiveX.  The VCL approach is just SO much easier to work with.

I haven't tried any ActiveXing recently, but I remember spending a
couple of months trying to implement (in VC++) an control I had knocked
out in Delphi in a couple of weeks (read, problem had already been
solved, but our development platform changed).  This control did
everything via the Windows API (I still prefer it to TCanvas for control
development) so I don't feel unduly constrained by the VCL.  However,
trying the same thing from scratch as an ActiveX drove me crazy, trying
to get that sort of access, and trying to implement properties was a bad
joke.  VCL is a MUCH simpler way to develop, end of story.

As a bonus, if you develop your control as a VCL first, all those
builder developers out there (and Delphi too, depending on which tool
you use) get access to a tighter, faster version of your control!

AlisdairM

Re:Why does BCB3 force ActiveX control creation from VCL control


Quote
> It's almost invariably easier to implement a custom control as a VCL,
> derived from TCustomControl or TGraphicControl, than to write a raw
> ActiveX.  The VCL approach is just SO much easier to work with.

But my dear friend It doesn't allow me to derive from any of the TCustom* or
TGraphicControl classes !
I would've loved to use them if it allowed me to. It allows them only while
writing a vcl control !
Check it out urself. The Dropdown listbox in the expert doesn't have any of em i
really wished were in there.

Re:Why does BCB3 force ActiveX control creation from VCL control


The idea is to write your ActiveX control as a VCL custom control first, then derive
from that VCL custom control. I agree with you that Inprise could have ( and should
have ) created a visual environment for creating an ActiveX control from scratch as
VC++ does. But creating a VCL custom control is well explained in the Developer's
Guide and creating an ActiveX control from your VCL custom control is also explained
there ( and in Charlie Calvert's C++ Builder 3 Unleashed, which is almost de rigeur
for serious ActiveX work with BCB3 ).
Quote
Roshan wrote:
> > It's almost invariably easier to implement a custom control as a VCL,
> > derived from TCustomControl or TGraphicControl, than to write a raw
> > ActiveX.  The VCL approach is just SO much easier to work with.

> But my dear friend It doesn't allow me to derive from any of the TCustom* or
> TGraphicControl classes !
> I would've loved to use them if it allowed me to. It allows them only while
> writing a vcl control !
> Check it out urself. The Dropdown listbox in the expert doesn't have any of em i
> really wished were in there.

Other Threads