Board index » delphi » Problem(?) with a TStringList as a property

Problem(?) with a TStringList as a property

Hi all,

OK, here's the deal. I have an object which has a TStringList called
QuestionText as a property.

property QuestionText: TStringList read FQuestionText write
SetQuestionText;

My problem is that I can call QuestionText.Assign(NewQuestionText) from
anywhere and basically
sidestep the write access specifier and the private method
SetQuestionText. And as far as I can
tell that's the only way I can see to set the property since
QuestionText:= NewQuestionText
ain't gonna work. How do I fix that? Do I have to subclass TStringList
and override its Assign
method? Am I missing something simpler.
Thanks in advance.

David de Vogel
dd...@alphad.csd.uwm.edu

 

Re:Problem(?) with a TStringList as a property


"David C. de Vogel" <dd...@csd.uwm.edu> openly revealed:

Quote
>Hi all,

>OK, here's the deal. I have an object which has a TStringList called
>QuestionText as a property.

>property QuestionText: TStringList read FQuestionText write
>SetQuestionText;

>My problem is that I can call QuestionText.Assign(NewQuestionText) from
>anywhere and basically
>sidestep the write access specifier and the private method
>SetQuestionText. And as far as I can
>tell that's the only way I can see to set the property since
>QuestionText:= NewQuestionText
>ain't gonna work. How do I fix that? Do I have to subclass TStringList
>and override its Assign
>method? Am I missing something simpler.
>Thanks in advance.

the actual value QuestionText property should never be changed,
therefore its write procedure wouldnt really be called. its only (and
correct me if im wrong) the pointer to the object.  If you want to
create an event so you know whenever the object was changed, you
should do soemthing like this

type
 TMyComponent = class(TBlahBlahComponent)
  private
   FQuestionText: TStringList;
   procedure OnQuestionChange(Sender: TObject);
  public
   constructor Create(AOwner: TComponent); override;
  published
   property QuestionText: TStringList read FQuestionText write
FQuestionText;
end;

implementation

constructor TMyComponent.Create(AOwner: TComponent);
begin
  inherited Create(AOwner);
  FQuestionText := TStringList.Create;
 {im too lazy to include it, but this should be freed in the overrided
Destroy method}
 FQuestionText.OnChange := OnQuestionChange;
 {the procedure is now set to its OnChange event}
end;

procedure TMyComponent.OnQuestionChange(Sender: TObject);
begin
 {this code would be called whenever the QuestionText property is
chaanged}
end;

other junk =]

i really hope i didnt leave anything out

-=
-= "I'll make weapons out of my imperfections."
-= legi...@mindspring.com

Re:Problem(?) with a TStringList as a property


David C. de Vogel wrote:

Quote

> Hi all,

> OK, here's the deal. I have an object which has a TStringList called
> QuestionText as a property.

> property QuestionText: TStringList read FQuestionText write
> SetQuestionText;

> My problem is that I can call QuestionText.Assign(NewQuestionText) from
> anywhere and basically
> sidestep the write access specifier and the private method
> SetQuestionText.

        You should be able to call QuestionText.Assign(NewQuestionText)
"from anywhere". That should perform a FQuestionText.Assign(NewQuestionText),
(which will succeed or not depending on whether you've Created
FQuestionText.)

Quote
> And as far as I can
> tell that's the only way I can see to set the property since
> QuestionText:= NewQuestionText
> ain't gonna work. How do I fix that?

        What do you mean it ain't gonna work? It "works" fine,
exactly what it does depends on what the SetQuestionText
method does.

        If your code compiles then your SetQuestionText must
look like

procedure SetQuestionText(AList: TStringList);
begin
{whatever}
end;

Now what happens when you say QuestionText:= NewQuestionText
depends on what that method does. What do you _want_ it to do?
If you want it to literally set the value of your stringlist
to the NewQuestionText object you could say

procedure SetQuestionText(AList: TStringList);
begin
FQuestionText:= AList;
end;

Of course you could accomplish that by saying "write FQuestionText"
instead of "write SetQuestionText". If OTOH you want the "assignment"
(ie the QuestionText:= NewQuestionText) to make a copy of
NewQuestionText you could say

procedure SetQuestionText(AList: TStringList);
begin
FQuestionText.Assign(AList);
end;

Quote
> Do I have to subclass TStringList
> and override its Assign
> method? Am I missing something simpler.

        I may be missing something - if not all you have to do is
decide what you want the "assignment" to the property to actually
do, and then tell the write method to do that.

--
David Ullrich

?his ?s ?avid ?llrich's ?ig ?ile
(Someone undeleted it for me...)

Re:Problem(?) with a TStringList as a property


Quote
Keenan Marshall wrote:

> "David C. de Vogel" <dd...@csd.uwm.edu> openly revealed:

> >Hi all,

> >OK, here's the deal. I have an object which has a TStringList called
> >QuestionText as a property.

> >property QuestionText: TStringList read FQuestionText write
> >SetQuestionText;

> >My problem is that I can call QuestionText.Assign(NewQuestionText) from
> >anywhere and basically
> >sidestep the write access specifier and the private method
> >SetQuestionText. And as far as I can
> >tell that's the only way I can see to set the property since
> >QuestionText:= NewQuestionText
> >ain't gonna work. How do I fix that? Do I have to subclass TStringList
> >and override its Assign
> >method? Am I missing something simpler.
> >Thanks in advance.

> the actual value QuestionText property should never be changed,
> therefore its write procedure wouldnt really be called. its only (and
> correct me if im wrong) the pointer to the object.  

        OK: The fact that it's only a pointer to an object does not
imply that its value should never be changed - the actual value of
pointers to objects gets changed all the time.

        Much more important: Supposing that we agree that that the
actual value of the FQuestionText field should never be changed, in
this particular situation (there's really no such thing as the "actual
value" of a property.) That does NOT say that the write procedure
wouldn't really ever get called! The write procedure could do
something other than change the value of the field. This is not
just theoretical, this is how properties are used.

        A while ago someone said something about

Memo1.Lines:= SomeStringList;

I jumped in and said something stupid about how wrong this was, it
should be Memo1.Assign(SomeStringList) instead. Whoever it was
explained that that's exactly what the formal "assignment" did...

Quote
> If you want to
> create an event so you know whenever the object was changed, you
> should do soemthing like this

        The question was how to change the property, not how to be
notified when it was changed.

--
David Ullrich

?his ?s ?avid ?llrich's ?ig ?ile
(Someone undeleted it for me...)

Other Threads