Should TMemo have property FileName: String? lazarus / 7-LCL ---------------------------------------------------------------------- Avishai · 2012-07-23 12:38 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? ---------------------------------------------------------------------- KpjComp · 2012-07-23 12:50 Quotebut I would think the same would apply there as well.  Any thoughts? I'd say no,  a TMemo is just that.  It can get it's data from anywhere, eg. TDbMemo/registry etc. You might say if you don't use it, then you can ignore it.  Problem here is that on a 64bit machine that's wasted 8 bytes for something you don't use. ---------------------------------------------------------------------- Avishai · 2012-07-23 14:15 Hi KpjComp   I might agree with that if it weren't for the fact that there are already countless properties that are either very rarely used or can not be used throughout Lazarus.  It seems like almost every component has something like that.  Just a quick look at TMemo and I see 'PasswordChar'.  I can't believe that is used very often in TMemo.  There is also 'AutoSize' which at first glance seems to do nothing in TMemo. ---------------------------------------------------------------------- KpjComp · 2012-07-23 14:43 QuoteHi KpjComp   I might agree with that if it weren't for the fact Hi Avishai,  We have a saying in this country -> Two wrongs don't make a right. Unfortunately it's one of the problems of Single inheritance object model. Multi-Inheritance might have been a good solution but unfortunately such concepts were deemed evil and never came to pascal, one nice thing of C++. Maybe smart linking can help here, but I'm not sure to what level smart linking can go.  Removing Class private vars seems like it might be pretty hard for the compiler to optimize out. ---------------------------------------------------------------------- Blestan · 2012-07-23 14:44 The idea is that TMemo IS a textarea component ... if you want create a new class with this property ... if i store a result from ajax call it must have a url property also? and another hint to no create a array of memos ... use array of TStrings ---------------------------------------------------------------------- Avishai · 2012-07-23 14:53 Thanks Blestan, but I need the TMemo in this app.  It is just a very basic text editor with TPageControl and a TMemo on each TabSheet.  So I need an Array of TMemo. I started with just one TMemo and an Array of TStringList.  For each Tabsheet, I just changed the Parent of the TMemo, stored the Text in a TStringList... But it got much too complicated for such a simple app and the memory savings were tiny. ---------------------------------------------------------------------- KpjComp · 2012-07-23 14:58 @Avishai. There is a little trick you can do to give you extra properties. If you define say another unit called StdCtrls2, and you make sure this unit comes after the default stdCtrls you can extend at runtime extra properties fields you can see from the TMemo.  The advantage here is you don't need to create say a TMyMemo and register it, or create these TMyMemo at runtime, all your designtime TMemo's will get this extra property. eg. Code: [Select]unit stdctrls2; {$mode objfpc}{$H+} interface uses   Classes, SysUtils, stdCtrls; type   TMemo = class(stdCtrls.TMemo)   public     filename:string;   end; implementation end.    It's a bit like a class helper, but class helpers don't allow extra variables, only methods etc. ---------------------------------------------------------------------- Avishai · 2012-07-23 15:09 Thanks KpjComp!  I din't know that one.  I'm not even going to ask how you learned this   It works perfectly. ---------------------------------------------------------------------- Martin_fr · 2012-07-23 15:13 Are you sure that works? If you tested it in a sample project, then yes it may seem to work. BUT... IRC the lfm reader has still a reference to StdCtrls.TMemo. So when reading the LFM, that is created, and memory allocation only gets memory for that. If you access the extra field, you would (If I am right) access unallocated memory. That wouldn't immediately cause an error, so it may SEEM to work at first. But if you have other objects, then you may overwrite them.... It may work, if your app registers the new TMemo with the reader (there is a function to do this). But I have not tested this. And I certainly do not recommend it. --------- Besides "Array of TMemo"  is not read from LFM? So you could do TMyMemo? If you do not want to create a TMyMemo, then instead of    Array of TMemo do   Array of Record     Memo: TMyMemo;     FileName: string;   end; ---------------------------------------------------------------------- Avishai · 2012-07-23 15:20 Thanks Martin_fr.  I'll have to do some more testing of course, but I hope it works out.  It's just too cool not to want to see it work But the original question was whether 'FileName' should be a property of TMemo.  I'm not saying that it should be.  I'm just asking for opinions.  To me it seems logical, but there are always other things to consider. So far I have 1 vote for NO. ---------------------------------------------------------------------- KpjComp · 2012-07-23 15:21 Hi Martin_fr, No, it does actually create your customized instance of TMemo. eg. Code: [Select]constructor TMemo.Create(AOwner:Tcomponent); begin   inherited Create(AOwner);   showmessage('my instance created'); end;  The above showmessage will get called. ---------------------------------------------------------------------- BigChimp · 2012-07-23 16:04 Quote from: Avishai on July 23, 2012, 05:20:51 pmBut the original question was whether 'FileName' should be a property of TMemo.  I'm not saying that it should be.  I'm just asking for opinions.  To me it seems logical, but there are always other things to consider. So far I have 1 vote for NO. Ok, you're asking for it... Another vote for NO. Of course, you could always raise a bug report with a patch... after all, regardless of our opinions, the Lazarus committers get to decide. Don't know about the chances of the patch getting in... but if it is that important for you, you can always try. Regards, BigChimp ---------------------------------------------------------------------- Avishai · 2012-07-23 16:13 Thanks BigChimp.  That's why I asked the question.  I don't want to go to BugTracker and ask for something that most people don't see a need for.  I think they have enough to do as it is.  And I appreciate your response. ---------------------------------------------------------------------- BigChimp · 2012-07-23 16:17 Avishai, I think this shows you're a very considerate person. I'd say there's nothing wrong with posting the patch and seeing what happens... but I commend you for your tact and diplomatic skills. (Some issue tracker requests are very vague and I think[1] the devs would have a lot of work. In this case, I think it's a simple decision if you give all the details. If you provide a patch as well, there wouldn't be much work involved in implementing it as well.) [1] Not a Lazarus/FPC dev myself, just a compulsive issue/patch submitter, so can only guess Regards, BigChimp ---------------------------------------------------------------------- Avishai · 2012-07-23 16:28 Thanks BigChimp, but so far I seem to be the only person that thinks it 'might' be a good idea, and I have a solution without it so I think I'll wait see if there are any other comments. I have seen some of the 'Feature Requests' on Bugtracker.  Some of them are, well, strange. ---------------------------------------------------------------------- KpjComp · 2012-07-23 18:47 QuoteIt'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 · 2012-07-23 19:06 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 · 2012-07-23 19:36 QuoteI don't like creating very specialized components. Yes I agree, it can become never ending otherwise. QuoteBut 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 · 2012-08-27 17:37 Quote from: Avishai on July 23, 2012, 02:38:30 pmI 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 · 2012-08-27 17:54 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 · 2012-08-27 18:29 Quote from: Avishai on August 27, 2012, 07:54:47 pmThanks 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...