Board index » cppbuilder » Bug in VCL form constructors...

Bug in VCL form constructors...

Quote
Jurko wrote:
> 3. Add another parameter to the second forms constructors declaration
> like this:
>     __fastcall TForm2::TForm2(TComponent* Owner, const int a )

Uh oh!  That overrides another constructor defined for TCustomForm by
the VCL.  I can't remember where it is used (check help for further
details) but you are indeed going to see unexpected side effects :? (

One solution I have seen suggested is to reverse to order of the
parameters, like so...

Quote
> __fastcall TForm2::TForm2( const int a, TComponent* Owner );

Fortunately, it is not a problem that has hit me yet!

To clarify the problem in your mind, you might try declaring your
original constructor without the __fastcall convention, and see if you
get any compiler errors!

--
AlisdairM
Team Mongolian Wok

 

Re:Bug in VCL form constructors...


Quote
Jurko <Jurko> wrote in message news:3b4f238d$1_2@dnews...

Adding to Alisdair's comment, you *must* look up the online help for
TForm::TForm.  That function signature is already taken.

Quote
> 3. Add another parameter to the second forms constructors
declaration
> like this:
>     __fastcall TForm2::TForm2(TComponent* Owner, const int a )

Are you modifying IDE-generated code?  It also sounds like you are
mixing visually dropped component code with dynamically creating
component code, which would be wrong.  That's not how to derive your
own TForm-like component.  Component derivation is done like other C++
inheritance, starting with a new class, like

__fastcall TMyForm::TMyForm(TComponent *Owner) : TForm(Owner, 0)
    {
    Caption="Derived Form";
    }

That constructor (built in to BCB) is specifically designed to keep
the IDE from demanding a *.dfm file for what is normally a visual
component.

Quote
> Note that this does not happen if we do not add another parameter or
if
> we add a different type parameter (tried with a pointer, a char, an
> AnsiString, all
> worked)... haven't got the time to got deeply into it now, so I

haven't
-------
Timothy H. Buchman
========================================
City Center Theater, New York NY
mail address tbuchmanPLEASE(at sign)REMOVEcitycenter.org
Please treat this signature information as confidential.
========================================
Search .borland message archive on http://www.mers.com/searchsite.html

Re:Bug in VCL form constructors...


Hmmm the funniest thing kept me busy all day today...

There seems to be a bug in VCL... or it could be just my
installation that is wrong but something is most definetivaly wrong...

When I do this:

1. Create a new project. (has only one form TForm1)
2. Add a second form (TForm2)
3. Add another parameter to the second forms constructors declaration
like this:
    __fastcall TForm2::TForm2(TComponent* Owner, const int a )
Note that it is an integer parameter!!!
4. Now add an OnClick handler on the first form and to the following in
it:
{
    (new TForm2( this, 5 ))->Show();

Quote
}

Never mind the potential memory leak... it's not important now...
Also for thie to work you need to include the the second forms header
file in the first form unit.

But when I run this application and click on the first form I get a stack
overflow error. It happens somewhere inside TCustomsForms constructor...
It seems that somehow magically the second forms constructor is called
again...

Note that this does not happen if we do not add another parameter or if
we add a different type parameter (tried with a pointer, a char, an
AnsiString, all
worked)... haven't got the time to got deeply into it now, so I haven't
checked
whether it works if there are more parameters or something... anyways...
I'm so mad now...

Anyone got any suggestions? At least tell me that it's a well known bug and
that
I was stupit not to know about it... :-)))

Jurko

Re:Bug in VCL form constructors...


Quote
> Are you modifying IDE-generated code?  It also sounds like you are
> mixing visually dropped component code with dynamically creating
> component code, which would be wrong.  That's not how to derive your
> own TForm-like component.  Component derivation is done like other C++
> inheritance, starting with a new class, like

> __fastcall TMyForm::TMyForm(TComponent *Owner) : TForm(Owner, 0)
>     {
>     Caption="Derived Form";
>     }

Erm... I am modifying IDE generated code... but an IDE generated constructor
is still just a constructor, and there is nothing wrong with modifying its
parameter
list, as long as I am the one to call that constructor later (which I am
doing :-))

Anyways... I guess the problem is with that other constructor... hmmm I'll
go
check it out now... hmmm that would explain it... :-)))

Thanks for the comments...

Jurko

Re:Bug in VCL form constructors...


Quote
> Uh oh!  That overrides another constructor defined for TCustomForm by
> the VCL.  I can't remember where it is used (check help for further
> details) but you are indeed going to see unexpected side effects :? (

Erm... thanks!!!! that explains it... mental block on my part I guess...
didn't stop to think of that possibility...

I looked up that constructor and it's a 'VCL hack' that allows you to
instantiate a form without automatically streaming in the component
data from the resources... :-)) d*mn... should have caught that one...

Thanks again!!!

Jurko

Re:Bug in VCL form constructors...


Quote
Jurko <Jurko> wrote in message news:3b4f85ed_2@dnews...
> Erm... I am modifying IDE generated code... but an IDE generated
constructor
> is still just a constructor, and there is nothing wrong with
modifying its
> parameter
> list, as long as I am the one to call that constructor later (which
I am
> doing :-))

> Anyways... I guess the problem is with that other constructor...
hmmm I'll
> go
> check it out now... hmmm that would explain it... :-)))

Well, I'm not the Borland Police, so I can't reprimand you!  But if
you modify the IDE generated code, you sort of lose the right to
diagnose bugs, if you know what I mean.  That's all I meant to point
out.  It's also possible to make changes that prevent the IDE from
parsing its' own code when you save the Project, and then all your
work is "down the tubes."

The real point is that a visually created component is just that, and
there are even a *few* properties that should not be changed after a
vcl object is created (for instance, ->Name).  But if the IDE creates
it for you, you can't change them later.  I'm just trying to give
another example of why run-time creation and "visual" code should not
overlap.  It's liable to come around and bite you in the ...

--
Timothy H. Buchman
========================================
City Center Theater New York NY
tbuchmanPLEASE(at sign)REMOVEcitycenter.org
Please treat this signature information as confidential.
========================================
Search .borland newsgroup archives at:
http://www.mers.com/searchsite.html

Other Threads