Anders Melander

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"?

https://github.com/SynEdit/SynEdit

Yes

No. I claimed that they would exhibit the same symptoms. I.e. incorrect result due to accumulation of rounding errors. That's not twisting anything. The degree of imprecision will be the same for the same data type regardless of the compiler since we're dealing with a native data type implemented on the CPU. The exact error might differ, but that doesn't make any difference. I'll take your word for that. It's all GrΣΣk to me

Yes they both suffer from floating point rounding errors. The fact that the exact error values differ doesn't make any difference. All compilers will suffer from this as the imprecision is inherent in the nature of floating point precision. Higher precision will make the error smaller but there will still be errors. As David points out the only way to avoid that is to use another algorithm. If that isn't practical then one might try to implement with an arbitrary precision library.

Why would that make a difference? If the problem is caused by rounding errors then FP will exhibit the exact same symptoms.

So... SO is better than a forum?

stackoverflow