Attila Kovacs

So you are expecting and handling exceptions from the constructor but not expecting and not handling exceptions from any further method calls? Interesting.

It is. like if Parameter1 = null then raise...? What if that object is freed before you will use that in some of the methods? What is the advantage of this early-validation? It's just flow control in this case.

Can't see a damn question about memory management. Maybe I'm reading a different thread.

I was curious so I made this useless statistics over one of my projects WSL (always backup your files before playing with scripts on them) for i in `find . -name "*.pas" -type f`; do cat $i | sed -nr '/\bconstructor\b/I{:a;N;/end\;/I!ba;/begin/Ip}' | sed -e '1i\'$i'' | grep constructor; done | wc -l; 250 constructors (180 with parameter) for i in `find . -name "*.pas" -type f`; do cat $i | sed -nr '/\bconstructor\b/I{:a;N;/end\;/I!ba;/\sraise/Ip}' | sed -e '1i\'$i'' | grep constructor; done | wc -l; 11 explicit call for raise in a constructor (with parameter) if my scripts are right btw. Delphi sources 5137 / 306 (3937/244 with parameter)

@Dalija Prasnikar Hm, I really don't know what would I do on out of memory, never had to deal with that.

Actually I only handle exceptions where I have a plan B, otherwise I could only translate the messages to other languages.

what if time is a factor on that calls? are you swearing while you writing the code?;)

I'm always rising them there where it's not needed and mostly when I don't know. Sometimes not. You should have come up earlier with that.

Nothing. It's the class' design pattern. There could be an extra "Open" where the exception raises, makes no difference for me. But, following a design pattern makes life easier, so I'm trying to follow some rules, and yes, this can make things easier "better". It does not always work though.

If those methods are time critical you can do a lazy initialization or validate outside or even avoid OOP or whatever, but I would not validate in the constructor if I don't have to.

I can't think of everything right now but the LA := TRaiseOnMinus.Create( -2 ); //<== Raise seems to me a double act. Instantiate an object and doing something which raises an exception because of the parameter. In the constructor I mostly store the argument into a class field so It will cause an exception later, thus the constructor is not affected. Similar to Uwe's solution, but without initialize, just let it fail somewhere, but not in the constructor. Also, I suspect that you are using in this example exceptions to control the app. Don't do that if you can. Make the parameter type unsigned or let it fail somewhere if the parameter is negative but do not check it in the constructor and call raise. (If you can)

Events could be useful. OnProgress OnError OnQueryCancelled etc... Or fire up a brand new empty project and both projects should be able to use the same unit. But only that one. But, as far as I can see, this is not Ian's main goal this time. He is learning different things first.

As long as it's a windows application yes, use GetTickCount64. Whereas both will count the time the computer is in sleep or in hibernation. Not sure about TStopWatch.

just use the 2 TDateTime values, start/stop and use System.DateUtils.SecondsBetween(start, stop).

What do you mean with always?

He is right on this one.

since when is that?

I did not change anything since then. However I'm starting to encounter problems with Thunderbird too. Sometimes it just hangs and returns with unknown error. forsix.MapiMail.pas

well, in this case you could derive TMyForm from TForm which has a .Show[Modal]: returntype; method and do many more things for every form in one place, and no need for a global "utils.pas". Just edit the class declaration at the top of the file from class(TForm) to class(TMyForm) (after you implemented TMyForm of course)

For VCL: TWhateverForm.Create(whoever).Show[Modal]; and in OnClose event Action := caFree; and remove every form reference like "Form1: TForm1" except the main form's which is needed. If you need to pass arguments or need results then you can add a method to the Form class like public function ShowForm(myarguments): resulttype etc.. FMX, I don't know, I'd be surprised if it would be much different.

for curiosity's sake, is there any compiler hint on that concat?

Just got the similar case, I was removing published properties from existing visual components and did not open every dfm in the IDE so there were dfm's having old non-existent properties complaining at runtime. Can't remember the error message though.

I'd say it's the TReader and the property does not exists in the class not in the dfm. Seems like you have different versions in the path or the component's package is used in other packages which are not rebuilt? Try to create a batch file which rebuilds everything from scratch, it could be helpful to debug such things.

buhh, I'm so tired, Uwe, can't you make MMX coding for me while I'm sleeping? pleeease!

If not, you should not use that product.