Anders Melander

...and how did these people get their experience?

Can someone explain why this fails to compile with E2029 Expression expected but 'ARRAY' found: begin var Stuff: array of integer; end; while this works: type TStuff = array of integer; begin var Stuff: TStuff; var MoreStuff: TArray<integer>; end;

Never mind. Known problem: RSP-21729: Inline var case complier error RSP-22359: Nameless types are not allowed within inline variable declarations

Yes I believe there are slight differences in the syntax but I simply can't remember them anymore. BRCC32 used to be a superset of RC back when Borland was a leader in development tools... So quite some time ago. If I could find some documentation of BRCC32 I could probably tell you what they are. See also:

Ah yes. I didn't spot that one. Easy to fix I guess. I don't understand the problem. Please educate me.

I can't see why using Move would be a problem as long as it just moves entries within the buffer array (which it does as far as I can tell). However there does seem to be a problem with not clearing empty slots in the array. E.g. by assigning Default(T) to them.

Well that a bug then. Report it and get it fixed. Since we're (you're) talking about external documentation the first part doesn't really matter but it's true that the link to the external help is broken when the signature changes. That rarely happens though.

Document Insight can use external XML files. Very useful when you don't want to make the source unreadable with XML DOC comments.

Welcome @Kim Madsen

Sure, but I mean.. I know it sucks to use arrays of resourcestrings but this must be hell to maintain. And no spell check or automation of any kind.

Hard coded translations... Wow

So you're complaining about stuff like this?: type TFooBarKind = (fbFoo, fbBar); TFooBar = record This: integer; That: string; end; const FooBars = array[TFooBarKind] of TFooBar = ( (This: 1; That: "Foo"), (This: 2; That: "Bar") ); Apart from the little detail that PHP doesn't have enums at all the solutions are pretty much the same for Delphi, PHP, C, C++ and C# as far as I can see... Are you maybe confusing compile-time with run-time?

How is that relevant?

Did you mean WordPad and not Notepad? Notepad is for plain text and uses the same Windows control as the standard TMemo control. WordPad is for RTF and uses the same Windows control as the standard TRichEdit control.

No.

AFAIR brcc32 can handle both 24- and 32-bit icons. It is PNG-compressed icons it has problems with. Just use the Microsoft resource compiler instead (rc.exe). It's part of the SDK but can also be found in Delphi\Bin. var PNG: TPngImage; Stream: TStream; begin PNG := TPngImage.Create; try // Load a resource named 'MyImage' from a RCDATA resource Stream := TResourceStream.Create(hInstance, 'MyImage', RT_RCDATA); try PNG.LoadFromStream(Stream); finally Stream.Free; end; ... finally PNG.Free; end; end; Since we can call the resource types anything we want I usually use just name it 'PNG' for PNG images. Stream := TResourceStream.Create(hInstance, 'MyImage', 'PNG');

If either of the operands in a boolean expression is a variant then both operands are converted to variants. This is documented. Expressions on variants are evaluated using intrinsic functions implemented in system.variants.pas (_VarOr, _VarAnd, _VarAdd, etc. etc.). Because of the result of an expression isn't known until these functions has been called the compiler can't do short circuit evaluation on the expression. Look at the asm generated and it will all make sense No offense taken, but don't cry wolf just because the dog meows.

Who says it need fixing? Do you realize how much code it would break if the behavior was changed now? Also, maybe find out why it works the way it does before calling it a bug.

https://www.google.com/search?q=free+resource+editor+res http://melander.dk/reseditor (I'm the author)

You should ask @pyscripter about that. My guess is that the original SynEdit is used in a lot more applications and probably maintained more. You can check the commit logs yourself.

Nonsense. Evaluation is always left to right. Period. No. That will suffer from boolean short circuit which is the whole point of this thread. Actually at this point it seems that the point of the thread has become for everyone to have a different opinion. I wonder why the simplest questions, with the simplest answer, always gets the most attention.

If you use {$BOOLEVAL ON} and {$BOOLEVAL OFF} instead it will be a bit clearer what's going on. There's no point in passing Result along as a parameter. You're just doing an logical OR on the values in the list anyway. - and I do think you're being too clever. It's not a solution I would allow.

Okay then. There's none that I can think of that doesn't fall into the "too clever" category so I would choose the solution that is the most human readable.

Your first two solutions are fine. Why try to be "clever"?