I've tried the demo version, built my OCX, set the constrained size, and added some event handler.

It works exactly like the old Borland CBuilder 6: the grab handles does not follow the constrained size, the OnCloseQuery and OnDestroy events are not fired, there's is not an OnAmbientChange event available.

Building OCX is an important feature for us, as our customer needs them... so, if i were the one that take the final decision, i'll migrate to MS developement tools.... i'm not that one, but i'll strongly push in that direction.

It's a shame, anyway.

If you are courious about these bugs, then build an ActiveX library, an ActiveForm, and add to that form event handlers until you get this code:
{code:cpp}
void __fastcall TProva_OCX_2010::ActiveFormCreate(TObject *Sender)
{
	this->OnCloseQuery = EventoCloseQuery;
	OutputDebugString("OnCreate");
}
//---------------------------------------------------------------------------
void __fastcall TProva_OCX_2010::ActiveFormDestroy(TObject *Sender)
{
	OutputDebugString("OnDestroy");
}
//---------------------------------------------------------------------------
void __fastcall TProva_OCX_2010::EventoCloseQuery(TObject* Sender, bool &CanClose)
{
	OutputDebugString("OnCloseQuery");
}
//---------------------------------------------------------------------------
{code}
Also set the constrained dimension for the ActiveForm, compile and place the OCX in any container you like (i both the MS TSTCON32.EXE and a simple VB6 form).

> Building OCX is an important feature for us, as our customer
> needs them... so, if i were the one that take the final
> decision, i'll migrate to MS developement tools.... i'm not
> that one, but i'll strongly push in that direction.

Er, and what MS development tool is receiving active development on its OCX creation capabiilties? More constructively, when using C++Builder or Delphi for COM development, you just have to expect there will be visible 'joins' between the VCL and COM to learn about.

> If you are courious about these bugs, then build an ActiveX library, an ActiveForm, and add to that form event handlers until you get this code:
> {code:cpp}
> void __fastcall TProva_OCX_2010::ActiveFormCreate(TObject *Sender)
> {
> 	this->OnCloseQuery = EventoCloseQuery;
> 	OutputDebugString("OnCreate");
> }

I take it you've never wondered why OnCloseQuery isn't surfaced in the Object Inspector at design time? In short, it isn't because it isn't appropriate. That you can still assign OnCloseQuery in code is just a product of the VCL's class hierarchy in combination with the Delphi language's 'friend' sematics for protected members - basically, a lot of stuff only appropriate for TForm is accessible from within a decendent of TActiveForm too since they both have TCustomForm as an ancestor. Presumably, creating
 TCustomActiveForm below TCustomForm made it easier to implement design-time support; nonetheless, ideally, it would have been one level higher, like TFrame.

> //---------------------------------------------------------------------------
> void __fastcall TProva_OCX_2010::ActiveFormDestroy(TObject *Sender)
> {
> 	OutputDebugString("OnDestroy");
> }

That said, instead of handling *any* form-level event, override the corresponding method, which in the case of OnDestroy, will be DoDestroy. FWI, the relevant methods are usually named the same as the events, only without the 'On' prefix (e.g., DblClick corresponds to OnDblClick) - DoDestroy is just an exception.

> Also set the constrained dimension for the ActiveForm, compile and place
> the OCX in any container you like (i both the MS TSTCON32.EXE and a
> simple VB6 form).

Works here, albeit using Delphi as the creator and an Excel UserForm as the consumer. I take you're talking about the Constraints property..?

> {quote:title=Chris Rolliston wrote:}{quote}
> > If you are courious about these bugs, then build an ActiveX library, an ActiveForm, and add to that form event handlers until you get this code:
> > {code:cpp}
> > void __fastcall TProva_OCX_2010::ActiveFormCreate(TObject *Sender)
> > {
> > 	this->OnCloseQuery = EventoCloseQuery;
> > 	OutputDebugString("OnCreate");
> > }
> 
> I take it you've never wondered why OnCloseQuery isn't surfaced in the Object Inspector at design time? In short, it isn't because it isn't appropriate. 
I may agree... but then i ask you: why a OnAmbientPropertyChange event isn't surfaced as well? I guess it is appropriate (VB6 have that event available) but not in CB... it happens that i strongly need it in past, and i have got to do a lot of "trick" to grab it from the IOle"something" (sorry, i'm at home and i don't have the code here).

> 
> > //---------------------------------------------------------------------------
> > void __fastcall TProva_OCX_2010::ActiveFormDestroy(TObject *Sender)
> > {
> > 	OutputDebugString("OnDestroy");
> > }
> 
> That said, instead of handling *any* form-level event, override the corresponding method, which in the case of OnDestroy, will be DoDestroy. FWI, the relevant methods are usually named the same as the events, only without the 'On' prefix (e.g., DblClick corresponds to OnDblClick) - DoDestroy is just an exception.
Well, the OnDestroy event is exposed in the Object Inspector, so i feel that it should work as it is. Having to override methods 'cause an exposed event is not fired sounds like a bug, to me.

> 
> > Also set the constrained dimension for the ActiveForm, compile and place
> > the OCX in any container you like (i both the MS TSTCON32.EXE and a
> > simple VB6 form).
> 
> Works here, albeit using Delphi as the creator and an Excel UserForm as the consumer. I take you're talking about the Constraints property..?
Yes. The resulting OCX will keep the given min and max dimensions... but the grabhandles will not follow that size, they instead remains where you put them, resulting in having them under the OCX surface (if you resize it too small). I've searched a lot (from years) about how to force the grabhandles to stay around the OCX, but i havent found any solution. If this matters, i'm running WinXP pro, and i use a VB6 form as the consumer, or the tstcon32.exe which is a "tool" in the old MS Visual Studio 6.

Meanwhile, thanks for your help.

<parduz zudrap> wrote in message news:161090@forums.codegear.com...

> {code:cpp}
> void __fastcall TProva_OCX_2010::ActiveFormCreate(TObject *Sender)
> {
> this->OnCloseQuery = EventoCloseQuery;
> OutputDebugString("OnCreate");
> }
> //---------------------------------------------------------------------------
> void __fastcall TProva_OCX_2010::ActiveFormDestroy(TObject *Sender)
> {
> OutputDebugString("OnDestroy");
> }
> //---------------------------------------------------------------------------
> void __fastcall TProva_OCX_2010::EventoCloseQuery(TObject* Sender, bool 
> &CanClose)
> {
> OutputDebugString("OnCloseQuery");
> }
> //---------------------------------------------------------------------------
> {code}

NEVER use the OnCreate and OnDestroy events in C++!  They are Delphi idioms 
that produce illegal behavior in C++.  Use the actual constructor and 
destructor instead.

Do no assign a handler to the OnCloseQuery event like that.  Override the 
virtual CloseQuery() method instead.

-- 
Remy Lebeau (TeamB)

Remy Lebeau (TeamB) wrote:
> <parduz zudrap> wrote in message news:161090@forums.codegear.com...
> 
>> {code:cpp}
>> void __fastcall TProva_OCX_2010::ActiveFormCreate(TObject *Sender)
>> {
>> this->OnCloseQuery = EventoCloseQuery;
>> OutputDebugString("OnCreate");
>> }
>> //---------------------------------------------------------------------------
>> void __fastcall TProva_OCX_2010::ActiveFormDestroy(TObject *Sender)
>> {
>> OutputDebugString("OnDestroy");
>> }
>> //---------------------------------------------------------------------------
>> void __fastcall TProva_OCX_2010::EventoCloseQuery(TObject* Sender, bool 
>> &CanClose)
>> {
>> OutputDebugString("OnCloseQuery");
>> }
>> //---------------------------------------------------------------------------
>> {code}
> 
> NEVER use the OnCreate and OnDestroy events in C++!  They are Delphi idioms 
> that produce illegal behavior in C++.  Use the actual constructor and 
> destructor instead.
> 
> Do no assign a handler to the OnCloseQuery event like that.  Override the 
> virtual CloseQuery() method instead.
> 


Just out of curiosity, why are the OnCreate and OnDestroy events even 
ALLOWED under C++ Builder, given that every recommendation is never to 
use them?  Or, conversely, why doesn't C++ Builder 'force' use of the 
constructor/destructor when OnCreate/OnDestroy are called (in C++ 
Builder), since they are obviously 'verboten'?

It's all fine, well, and good for those who've been using the product 
for ages, but the new user of C++ Builder (cynically asking, are there 
any?) is not going to be aware of these constraints/recommendations, and 
is likely to use them...

David Erbas-White

> {quote:title=Remy Lebeau (TeamB) wrote:}
> NEVER use the OnCreate and OnDestroy events in C++!  They are Delphi idioms 
> that produce illegal behavior in C++.  Use the actual constructor and 
> destructor instead.
Ok.

> Do no assign a handler to the OnCloseQuery event like that.  Override the 
> virtual CloseQuery() method instead.
Tried. It is not called anyway, in my ActiveForm.

In article <163173@forums.codegear.com>,
 David Erbas-White <derbas@arachneering.com> wrote:

> Just out of curiosity, why are the OnCreate and OnDestroy events even 
> ALLOWED under C++ Builder, given that every recommendation is never to 
> use them?  Or, conversely, why doesn't C++ Builder 'force' use of the 
> constructor/destructor when OnCreate/OnDestroy are called (in C++ 
> Builder), since they are obviously 'verboten'?

   I have a feature request in to mark them as deprecated in C++ and 
instruct the user (at compile time) to use the destructor/constructor.
-- 
David Dean (Embarcadero)
Lead C++ QA Engineer

> > I take it you've never wondered why OnCloseQuery isn't surfaced in the
>> Object Inspector at design time? In short, it isn't because it isn't appropriate. 
> I may agree... but then i ask you: why a OnAmbientPropertyChange event isn't surfaced as well? 

OnCloseQuery is a VCL event; AmbientPropertyChange is an OCX thing. If C++Builder/Delphi doesn't explicitly surface something unconncected to its native framework (namely the VCL), you have to do it yourself, as if you were doing things all manually in Visual C++.

> I guess it is appropriate (VB6 have that event available) but not in CB...

VB6 was based upon COM; C++Builder and Delphi merely support COM. I agree that VB was better for high level COM programming than C++Builder, but then that's a bit like saying C++Builder is better for VCL programming than Visual C++...

> Well, the OnDestroy event is exposed in the Object Inspector, so
> i feel that it should work as it is. Having to override methods 'cause
> an exposed event is not fired sounds like a bug, to me.

Sort of -- it's certainly sub-optimal, but fixing it would be difficult if breaking old code is to be avoided (the Delphi/C++Builder COM framework dates from 1997, so it's not exactly new). As I said, ideally, OnDestroy and the like wouldn't have been exposed in the first place (and pace the other responders, this affects Delphi as well as C++Builder).

> > Works here, albeit using Delphi as the creator and an Excel UserForm as
>> the consumer. I take you're talking about the Constraints property..?
> Yes. The resulting OCX will keep the given min and max dimensions... but
> the grabhandles will not follow that size, they instead remains where you put
> them, resulting in having them under the OCX surface (if you resize it too
> small).

I'm still not quite sure of the problem here - are you saying the grab handles don't 'snap back' to their constrained position after you let go of the mouse?

> {quote:title=Chris Rolliston wrote:}

> I'm still not quite sure of the problem here - are you saying the grab handles don't 'snap back' to their constrained position after you let go of the mouse?
Exactly. Sorry for not being able to explain myself better or properly.... i do my best (this is valid also for what i'm saying below)

> OnCloseQuery is a VCL event; AmbientPropertyChange is an OCX thing. If C++Builder/Delphi doesn't explicitly surface something unconncected to its native framework (namely the VCL), you have to do it yourself, as if you were doing things all manually in Visual C++.
> [cut]
> VB6 was based upon COM; C++Builder and Delphi merely support COM. I agree that VB was better for high level COM programming than C++Builder, but then that's a bit like saying C++Builder is better for VCL programming than Visual C++...
It may be just me, but i (well, my company) moved to CppBuilder6, and then BDS2006, from MS Visual Studio 'cause:
1) All our programmers works in C / C++ for the firmware of our hardware products, and we wanted to use the same language to develop the PC UI for them (so, no more VB)
2) It (claims) to be a full "visual" developement system, so we was not too far from our habids (drag a button, write property values, write an event - done). This is mostly true (really, i loved C++Builder 6 and the 2006) but fails in our main goal: building OCXs that needs to works in a lot of containers, the most infamous being RSVIEW32, which is not fully "standard" (it never destroys an OCX, but it just changes the ambient property from "design mode" to "run", as example).

What i'm trying to say is that i really "don't care" (take this with some flexibility) about COM, VCL, ATL... i just want to throw objects on a form and let it run ( :D )



P.S.
As we're talking about bugs, i've installed the RAD2010 demo in a fresh, brand new HP notebook running XP Pro updated manually to the last update available. I've tried the things we're talking abot here and then i've switched of the PC until today.... now the C++Builder does not start anymore, leaving only the bds.exe process in memory, so i'm not able right now to try any suggestion in 2010, but just in BDS2006.

Thanks for your time.

On Wed, 16 Sep 2009 17:55:51 -0700, Remy Lebeau (TeamB)
<no.spam@no.spam.com> wrote:


>NEVER use the OnCreate and OnDestroy events in C++!  They are Delphi idioms 
>that produce illegal behavior in C++.  Use the actual constructor and 
>destructor instead.
>
It seems in ctor we have all properties and form stuff available, but
in destructor they have been released, then a saving form state
routine is not possible from dtor. Currently I¡m doing in ctor and in
OnClose and seems being working well.
Microsoft Visual C++ MVP => http://geeks.ms/blogs/rfog
========================================
La suma de inteligencia del planeta es una constante; la poblacion esta en crecimiento.
		-- Axioma de Cole.

> {quote:title=Rafael Ontivero wrote:}
> It seems in ctor we have all properties and form stuff available, but
> in destructor they have been released, then a saving form state
> routine is not possible from dtor. Currently I¡m doing in ctor and in
> OnClose and seems being working well.

I don't know if we're saying the same thing.... but i've just discovered that OCX properties, edited from the VB IDE (i have just inserted the OCX in a VB6 form and changed a bool properties) are not saved.

Also, i have no OnClose event calls.

Remy Lebeau wrote:

> <parduz zudrap> wrote in message news:161090@forums.codegear.com...
> 
>> {code:cpp}
>> void __fastcall TProva_OCX_2010::ActiveFormCreate(TObject *Sender)
>> {
>> this->OnCloseQuery = EventoCloseQuery;
>> OutputDebugString("OnCreate");
>> }
>> 
//---------------------------------------------------------------------------
>> void __fastcall TProva_OCX_2010::ActiveFormDestroy(TObject *Sender)
>> {
>> OutputDebugString("OnDestroy");
>> }
>> 
//---------------------------------------------------------------------------
>> void __fastcall TProva_OCX_2010::EventoCloseQuery(TObject* Sender, bool
>> &CanClose)
>> {
>> OutputDebugString("OnCloseQuery");
>> }
>> 
//---------------------------------------------------------------------------
>> {code}
> 
> NEVER use the OnCreate and OnDestroy events in C++!  They are Delphi
> idioms
> that produce illegal behavior in C++.  Use the actual constructor and
> destructor instead.
> 
OK. 
Instead of Oncreate() I use __fastcall TFormMain::TFormMain(TComponent 
*Owner) : TForm (Owner)
{
....
}
Right?

But what should I use instead of 
TFormMain::FormDestroy(TObject *Sender)
{
....
}
which is created by clicking 'OnDestroy'.

Something like TFormMain::~TFormMain() does not work, because the compiler 
tells me, it's already existing (where).

Helmut

Registered User <nospam_nghe@nowhere.no> wrote:

>Something like TFormMain::~TFormMain() does not work, because the compiler 
>tells me, it's already existing (where).

That probably means that the compiler created its own version because
you didn't explicitly declare it yourself.

So, just declare it in the class, and do your own implementation.

Alan Bellingham
-- 
Team Browns
ACCU Conference 2010: 13th-17th April, Oxford, UK

Alan Bellingham wrote:

> Registered User <nospam_nghe@nowhere.no> wrote:
> 
>>Something like TFormMain::~TFormMain() does not work, because the compiler
>>tells me, it's already existing (where).
> 
> That probably means that the compiler created its own version because
> you didn't explicitly declare it yourself.
> 
> So, just declare it in the class, and do your own implementation.
> 
> Alan Bellingham

Thanks Alan

it worked.

The other question (to the CBuilder/RAD-Studio developers) for me is, how 
many of all those C++ programmers know about not to use OnCreate() and 
OnDestroy()? I have used this functions for a long time now and it looks 
like I did not have any problems.

> The other question (to the CBuilder/RAD-Studio developers) for me is, how 
> many of all those C++ programmers know about not to use OnCreate() and 
> OnDestroy()? I have used this functions for a long time now and it looks 
> like I did not have any problems.

At some point (around BCB3/4 I think) the TeamB guys published a sort of best practices guide.
It included this and a bunch of other nice hints.  I'm not sure where it can be found these days
but maybe some one still has a link to it...

Well, I'm talking about normal forms, no OCX or ActiveX... Perhaps
that's de difference.


On Mon, 21 Sep 2009 09:33:08 -0700, parduz zudrap <> wrote:

>> {quote:title=Rafael Ontivero wrote:}
>> It seems in ctor we have all properties and form stuff available, but
>> in destructor they have been released, then a saving form state
>> routine is not possible from dtor. Currently I¡m doing in ctor and in
>> OnClose and seems being working well.
>
>I don't know if we're saying the same thing.... but i've just discovered that OCX properties, edited from the VB IDE (i have just inserted the OCX in a VB6 form and changed a bool properties) are not saved.
>
>Also, i have no OnClose event calls.
Microsoft Visual C++ MVP => http://geeks.ms/blogs/rfog
========================================
Si supieras que pocas cosas me importan, y de ellas que pocas lograre.
						-- G. Torrente Ballester --