Board index » cppbuilder » Re: The Silent Majority

Re: The Silent Majority


2004-12-21 11:58:05 AM
cppbuilder79
"Patrick McConnell" < XXXX@XXXXX.COM >wrote:
Quote
"Randall Parker" < XXXX@XXXXX.COM >wrote in
message news:41c4a714$ XXXX@XXXXX.COM ...
>BCB puts all the code for a form into a single class. So that stuff
doesn't scatter.
>Though if you have relationships between forms obviously that has to be
more complicated.
As ugly and buggy as it was, I missed OWL's Doc/View when we moved
over to BCB. It was a real let down to lose it.
 
 

Re:Re: The Silent Majority

Kevin Mitchell wrote:
Quote
I'll vote with my wallet. When C++ Builder is integrated into BDS, I will
definitely buy it.

I'd be more than happy to vote with my wallet right now and buy Delphi
2005 if it included a free update/upgrade to the version that includes
C++(Builder) support.
I know you can trade-up from C++Builder to Delphi 2005 right now but
unless C++ support is released as a free update to Delphi 2005 it
makes no sense to do so as you'd have to pay again to upgrade Delphi
2005 to get C++ support.
Maybe Borland should come up with a new trade-up/upgrade path so it
can start bring in some revenue from it's C++ customer base.
jeff
Quote
- Kevin


"Db" < XXXX@XXXXX.COM >wrote in message
news:41c3ab9c$ XXXX@XXXXX.COM ...

>I've used BCB since 1.0 and have developed a half dozen
>major systems with it though version 5.0, and made a living.
>
>It is the best Win32 C++ development environment hands
>down for the vast majority of Win32 applications, nothing
>comes remotely close.
>
>C++ Builder can make user interfaces that are virtually
>impossible to create with VC++, or any other tool except
>Delphi.
>
>Anything can be improved, and I hope Borland will make
>massive improvements to C++ Builder. Now that they've
>made this commitment, it's in their best interest.
>
>However, I'm just extremely grateful that C++ Builder will live
>on in BDS and an upgrade path will be provided.
>
>-db
>
>
>
>



 

Re:Re: The Silent Majority

Jeff Weir wrote:
Quote
Maybe Borland should come up with a new trade-up/upgrade path so it
can start bring in some revenue from it's C++ customer base.
I second that. I have to present budget proposals for research funding,
and the sooner I know how, much the better.
--
Ken
planeta.terra.com.br/educacao/kencamargo/
* this is not a sig *
 

{smallsort}

Re:Re: The Silent Majority

Ditto.
"Kenneth de Camargo" <INVERT:rb.moc.arret@jcrk>wrote in message
Quote
Jeff Weir wrote:

>Maybe Borland should come up with a new trade-up/upgrade path so it
>can start bring in some revenue from it's C++ customer base.

I second that. I have to present budget proposals for research funding,
and the sooner I know how, much the better.
 

Re:Re: The Silent Majority

OBones < XXXX@XXXXX.COM >wrote:
Quote
Not really, but basically, don't use Align on the frame itself or you
will "suffer".
You can set it at runtime, no drama there.
But setting it at designtime will mean that the components inside it
that use align or anchors will resize themselves weirdly. Most notably,
they will grow larger than the frame.

As to the inheritance problems, the symptoms are that when opening an
unrelated frame, it will complain about missing declaration for
components that are in the other frame. Really strange, but that's the
way it is. A bit like if the designer only knows of one frame type for
the complete project. Not much one can do here, but close the project
when this happens and then reopen it.
Late to the party as usual. So, given the problems with Frames, why
would anyone use them vs using Forms?
 

Re:Re: The Silent Majority

Hello Leroy
"Leroy Casterline" < XXXX@XXXXX.COM >wrote in message
Quote
Late to the party as usual. So, given the problems with Frames, why
would anyone use them vs using Forms?
Think of frames as customised component sets. You can create a frame, add
components, code default behaviour etc, then you can add this specialist
frame to as many forms as you like (as if it was a component). Also any form
can have any number of frames on it.
As an example, say a lot of your forms had a button navigator at the bottom
(next/back/close etc). You would create this as a frame and then simply
include it on any forms that needed it.
Hope this helps.
Des
 

Re:Re: The Silent Majority

"Des O'Toole" <des>wrote:
Quote
Think of frames as customised component sets. You can create a frame, add
components, code default behaviour etc, then you can add this specialist
frame to as many forms as you like (as if it was a component). Also any form
can have any number of frames on it.

As an example, say a lot of your forms had a button navigator at the bottom
(next/back/close etc). You would create this as a frame and then simply
include it on any forms that needed it.

Hope this helps.
Thanks for the explanation. I don't think I asked my question very well,
however. I've been using frames since they were added to the VCL. Before
that, I used forms in exactly the same manner - I could embed them in
container components just as I can frames.
I've noticed some of the problems associated with frames, and was
wondering what advantage frames offered over forms. I don't remember
having these size issues when I was using forms (or perhaps I just
didn't run into them then).
I've also run into another issue with frames, although it's not their
fault. I am using DevEx components heavily in my current project, and
not long ago found that I can't place their menus directly on a frame -
the can only be placed on a form. So I'm thinking of converting my
frames to forms and was looking for opinions on this.
 

Re:Re: The Silent Majority

Leroy Casterline wrote:
Quote
I've noticed some of the problems associated with frames, and was
wondering what advantage frames offered over forms.
The main advantage is reusability. I have a couple of frames that
appear in several forms. By using a frame I can avoid having to
duplicate the code associated with those components. It also means that
if I need to change the frame those changes will get carried across to
all the forms that use it.
--
Andrue Cope [TeamB]
[Bicester, Uk]
info.borland.com/newsgroups/guide.html
 

Re:Re: The Silent Majority

"Andrue Cope [TeamB]" < XXXX@XXXXX.COM >wrote:
Quote
The main advantage is reusability. I have a couple of frames that
appear in several forms. By using a frame I can avoid having to
duplicate the code associated with those components. It also means that
if I need to change the frame those changes will get carried across to
all the forms that use it.
As I recall, I've done the same thing with forms. I create an instance
and set its parent to be a panel, for example, and it displays in the
panel just as a frame would. I can then create another instance and
display it in a different panel. Am I not remembering correctly?
 

Re:Re: The Silent Majority

"Leroy Casterline" < XXXX@XXXXX.COM >wrote in message
Quote
"Andrue Cope [TeamB]" < XXXX@XXXXX.COM >wrote:

As I recall, I've done the same thing with forms. I create an instance
and set its parent to be a panel, for example, and it displays in the
panel just as a frame would. I can then create another instance and
display it in a different panel. Am I not remembering correctly?
As far as I am aware you cannot embed a form within another form (put please
feel free to prove me wrong).
Des
 

Re:Re: The Silent Majority

Des O'Toole wrote:
Quote
As far as I am aware you cannot embed a form within another form (put
please feel free to prove me wrong).
Yup TCustomFom is a TWinControl, and has a Parent proprty like any
other. I have been embedding forms for years, for instance it greatly
reduced the complexity of tabbed dialogs if each page is a form in its
own right.
The big difference between forms and frames is that you cannot embed a
form at design time, which is the task frames were invented for.
AlisdairM(TeamB)
 

Re:Re: The Silent Majority

"Alisdair Meredith" <alisdair.meredith@ XXXX@XXXXX.COM >
wrote:
Quote
The big difference between forms and frames is that you cannot embed a
form at design time, which is the task frames were invented for.
Ah, thanks for clearing that up. I don't see embedding at design time as
being too big a deal since you can design the form stand-along. Do you
know if embedded forms have the same sizing problems as frames?
 

Re:Re: The Silent Majority

Quote
Yup TCustomFom is a TWinControl, and has a Parent proprty like any
other. I have been embedding forms for years, for instance it greatly
reduced the complexity of tabbed dialogs if each page is a form in its
own right.
Can you provide an example of how to do this?
I think I may like forms better than frames from the standpoint
that a form with many tabsheets with many nonvisual controls
gets littered with the icons of the NV controls. This is true with frames
as well. At least with forms the NV controls remain on their own
form.
Dave
 

Re:Re: The Silent Majority

I opened an old project and copied what I'd done. It's simple:
Chart = new TFormChart(NULL);
Chart->Parent = TabSheetChart;
Chart->ClientHeight = TabSheetChart->Height;
Chart->ClientWidth = TabSheetChart->Width;
Chart->Top = 0;
Chart->Left = 0;
Chart->Show();
"Dave" < XXXX@XXXXX.COM >wrote:
Quote
>Yup TCustomFom is a TWinControl, and has a Parent proprty like any
>other. I have been embedding forms for years, for instance it greatly
>reduced the complexity of tabbed dialogs if each page is a form in its
>own right.

Can you provide an example of how to do this?

I think I may like forms better than frames from the standpoint
that a form with many tabsheets with many nonvisual controls
gets littered with the icons of the NV controls. This is true with frames
as well. At least with forms the NV controls remain on their own
form.

Dave