Should TMemo have property FileName: String?

[KpjComp]

It's just too cool not to want to see it work

Yeah, it's pretty neat.  It's known as an Interposer Class, so I can't take credit for inventing it. 

@martin_fr comment logically make sense.  But both Lazarus & Delphi take unit scope into account when streaming, so the correct class does indeed get initialized.

I used to find Interposer Classes handy when testing the development of new components, I could visual place some descendant controls on the Form, do my modifications and see them at runtime without having to register them with the component palette.

[Avishai]

I don't like creating very specialized components.  Sometimes that the best choice, but you can get carried away and end up with a lot of controls on the pallet and none of them do what you need for you next project.  I prefer using base components and adding whatever code to get what I need.  An example is a 'TCurrencyEdit'.  I prefer a TEdit and add the code I need in the OnKeyPress and some Validation.  I also borrow code from other projects so I don't end up rewritng the same thing over and over.  I think this is the way most programmers work.

But the method you showed me opens up many doors I didn't know were there.  I've already added it to my 'CodeSnippets' file, and I made sure to add your name as my source.  Credit due is Credit due.

[KpjComp]

I don't like creating very specialized components.

Yes I agree, it can become never ending otherwise.

But the method you showed me opens up many doors

No problem.. 

I've only a couple of warnings when using Interposer Classes.

1.  Be careful of overuse, as somebody else looking at your code might get well confused. 

2.  Always make sure you Interposer class descends from the same class your Interposing, what I mean by this, don't do things like  TMemo = class(TEdit)  etc.  It will compile fine, but your likely to get lots of RunTime errors.

But for small extras like the one you required, I think Interposer classes are perfect.  As it keeps  the OOP paradigm.  Having arrays that add extra properties to other classes breaks this.

[Stubborn]

I am using an Array of TMemo and keeping track of the FileName for each TMemo became a problem.  So I extended TMemo with property FileName: String.  Problem solved. 

Extending it is easy, but shouldn't this property already be part of TMemo to begin with?  I haven't checked TSynEdit but I would think the same would apply there as well.  Any thoughts?

I would rather implement the Filename property in a TStringList descendant, so basically in the data. as you would basically just use a TMemo to represent the data: Memo.Strings.Assign(MyCustomStringClass) and when the Memo changes: ( MyCustomStringClass.Assign(Memo) ). Even if this example is not very efficient I think it's an error to blend Gui and data.

[Avishai]

Thanks Stubborn.  I am glad to get some feedback on this.  As for your suggestion, it would not be so easy for one of my projects.  I would have to create an array of TStringLists because I have as many as 8 TMemos in view at the same time.  It could be done, but it is easier with my extended TMemo.FileName. 

Code: [Select]

with Sender as TMemo do begin
  if FileName<>'' then
    Lines.LoadFromFile(FileName)
end;


[Stubborn]

Thanks Stubborn.  I am glad to get some feedback on this.  As for your suggestion, it would not be so easy for one of my projects.  I would have to create an array of TStringLists because I have as many as 8 TMemos in view at the same time.  It could be done, but it is easier with my extended TMemo.FileName. 

Code: [Select]

with Sender as TMemo do begin
  if FileName<>'' then
    Lines.LoadFromFile(FileName)
end;


Quite clear...In the case you would have only a single editor for the Strings and maybe a "document selector", a specialized StringList would have been better.
But as you display all the documents at once...it's not worth...