Visibility of Components in a form

Robert Harvey

unread,

Jun 14, 1996, 3:00:00 AM6/14/96

to

Does anyone else find it irritating that the components of a form are
visible to the user of a form?

Is there any way of making them private?

I've just wasted several hours trying to find the silly bug in code
similar to this (apologies for any syntax errors):

in file 1:
TForm1 = class(TForm)
Table1: TTable;
...

in file 2:
TForm2 = class(TForm)
Table1: TTable;
...

with TForm1.Create(Self) do begin
ShowModal;
Table1.Refresh;
...

Expecting that I was refreshing TForm2.Table1 but instead it was
TForm1.Table1 :-{

Surely it would make more sense if access to a forms components was
only available via properties or public procedures etc? I would have
thought they were part of the implementation rather than the
interface.

Rob
--
Robert Harvey
Robert...@dial.pipex.com
http://dspace.dial.pipex.com/town/square/aai99

Mark Vaughan

unread,

Jun 14, 1996, 3:00:00 AM6/14/96

to

In article <4prkm9$3...@soap.news.pipex.net>,
Robert...@dial.pipex.com (Robert Harvey) wrote:
]-Does anyone else find it irritating that the components of a form are
]-visible to the user of a form?
]-
]-Is there any way of making them private?

sure...put 'em in the private section of the TForm object. of course
if you do this you can't just drop your (private) components onto your
form from the component palette; you have to create them manually, in
code.

Mark Vaughan

Robert Harvey

unread,

Jun 15, 1996, 3:00:00 AM6/15/96

to

m.a.v...@larc.nasa.gov (Mark Vaughan) wrote:

>In article <4prkm9$3...@soap.news.pipex.net>,
> Robert...@dial.pipex.com (Robert Harvey) wrote:
>]-Does anyone else find it irritating that the components of a form are
>]-visible to the user of a form?
>]-
>]-Is there any way of making them private?

>sure...put 'em in the private section of the TForm object.

:-)

> of course
>if you do this you can't just drop your (private) components onto your
>form from the component palette; you have to create them manually, in
>code.

Borland need a compiler switch like the M+ one except that it makes
these private *and* allows you to use the component palette.

And while they are adding compiler switches ;-) can we have one for
case sensitivity during compilation? ie: Not necessarily allowing
variables with the same name but different cases, but telling you when
the case is incorrect.

Boris Ingram

unread,

Jun 15, 1996, 3:00:00 AM6/15/96

to

In article <4ptlih$9...@soap.news.pipex.net> Robert...@dial.pipex.com (Robert Harvey) writes:
>From: Robert...@dial.pipex.com (Robert Harvey)
>Subject: Re: Visibility of Components in a form
>Date: Sat, 15 Jun 1996 06:34:44 GMT

>m.a.v...@larc.nasa.gov (Mark Vaughan) wrote:

>>In article <4prkm9$3...@soap.news.pipex.net>,
>> Robert...@dial.pipex.com (Robert Harvey) wrote:
>>]-Does anyone else find it irritating that the components of a form are
>>]-visible to the user of a form?
>>]-
>>]-Is there any way of making them private?

>>sure...put 'em in the private section of the TForm object.

>:-)

>> of course
>>if you do this you can't just drop your (private) components onto your
>>form from the component palette; you have to create them manually, in
>>code.

>Borland need a compiler switch like the M+ one except that it makes
>these private *and* allows you to use the component palette.

This would be really doff IMHO, because the advantages of making the memembers
publicly available far outweigh this kind of problem,

In best occam's razor tradition - think horses not zebras, why don't you just
be a bit more imaginative in namimg your components. I find it really helpful
to give things meaningful names, which you just then have to make unique

MHO

Boris Ingram, Cyborg Software
bori...@iafrica.com
10007...@compuserve.com
http://www.pcb.co.za/users/borising/cyborg.htm

Robert Harvey

unread,

Jun 15, 1996, 3:00:00 AM6/15/96

to

bori...@iafrica.com (Boris Ingram) wrote:

>>Borland need a compiler switch like the M+ one except that it makes
>>these private *and* allows you to use the component palette.

>This would be really doff IMHO, because the advantages of making the memembers
>publicly available far outweigh this kind of problem,

That's ok, you just wouldn't use the switch :-)

Anyway, I thought one of the important parts of OO was encapsulation,
ie: hiding implementation details from the users of a class. Surely
all the nitty gritty of user interface components count as
implementation details? IMHO it is better OO not to make form class
interfaces dependent on which particular components are used to
implement them.

>In best occam's razor tradition - think horses not zebras, why don't you just
>be a bit more imaginative in namimg your components. I find it really helpful
>to give things meaningful names, which you just then have to make unique

I used the name Table1 for simplicity in my example. My actual tables
were both called RMATable because they both accessed a table of RMAs
(my terminology). I'd didn't want to call them different things as
they both accessed the same data, and I want consistency in my naming
conventions.

Thomas Paul

unread,

Jun 18, 1996, 3:00:00 AM6/18/96

to

bori...@iafrica.com (Boris Ingram) wrote:

>In best occam's razor tradition - think horses not zebras, why don't you just
>be a bit more imaginative in namimg your components. I find it really helpful
>to give things meaningful names, which you just then have to make unique

This seems to be a common complaint among programmers. "My coding
style sucks so give me a better compiler to fix it." How about taking
responsibility for yourself and giving names other than Form1 or
Table2 to your objects? How about showing some concern for the poor
programmer who might have to look at your code and try to debug it?

In our shop we have developed a standard for naming all objects. We
give them all a prefix in lower case followed by a meaningful name in
CamelCase (who came up with that name?) So rather than Form1 we would
have frmReportOptions. Rather than Table2 we would have tblEmployee.
Now when I am looking at someone's code I can figure out the type of
object and what it is used for (in a vague, general sort of way). One
side benefit of this comes in the Object Inspector. Now if I hit the
letter 'f', I am immediately brought to the forms. If I hit 'q', I am
brought to all the TQuery objects.

If anyone is really desperate and can't figure out how to devise a
scheme for themselves, E-Mail me and I will send you a copy of our
documentation.

-------------------------------
Thomas Paul
TOM...@Pipeline.Com
Dean Witter, Discover & Co.
New York City, NY USA
----------------------------------

Robert Harvey

unread,

Jun 19, 1996, 3:00:00 AM6/19/96

to

TOM...@PIPELINE.COM (Thomas Paul) wrote:

>bori...@iafrica.com (Boris Ingram) wrote:

>>In best occam's razor tradition - think horses not zebras, why don't you just
>>be a bit more imaginative in namimg your components. I find it really helpful
>>to give things meaningful names, which you just then have to make unique

>This seems to be a common complaint among programmers. "My coding
>style sucks so give me a better compiler to fix it." How about taking
>responsibility for yourself and giving names other than Form1 or
>Table2 to your objects? How about showing some concern for the poor
>programmer who might have to look at your code and try to debug it?

As I have previously posted, the names I used in my example were
chosen for simplicity. In fact the actual names *were* descriptive,
both TTable names were the same because they were both accessing the
same data.

I have no problem with my coding style, but a compiler is a tool just
like any other, and any improvements that help eliminate obscure side
effects are surely a good thing.