Anders Melander

That only resolves inter-package dependencies. Not application dependencies.

Tsk, tsk.

Something like this: var ZipFile: TZipFile; SourceStream: TStream TargetStream: TStream; LocalHeader: TZipHeader begin ... TargetStream := TMemoryStream.Create; try ZipFile.Read('foobar.dat', SourceStream, LocalHeader); try TargetStream.CopyFrom(SourceStream, 0); finally SourceStream.Free; end; ...do something with TargetStream... finally TargetStream.Free; end; end; There used to be a problem with unicode in comments but I believe that has been fixed.

Yeah, that one is really annoying. I used to have a class helper that added TZipFile.Delete and Remove methods but one of the Delphi versions after XE2 broke that one as the required TZipFile internal data structures are no longer accessible to class helpers.

Who knows what?

Have you read the help? Extract to stream: http://docwiki.embarcadero.com/Libraries/Rio/en/System.Zip.TZipFile.Read Extract to file: http://docwiki.embarcadero.com/Libraries/Rio/en/System.Zip.TZipFile.Extract

I can't see how that is relevant. Just because new control versions are added doesn't mean the old ones stop working. TRichEdit is a wrapper around the RICHEDIT20W window class (i.e. RICHED20.DLL). Override CreateParams to use another version if that's important.

If you need an example of what TRichEdit can do just run Wordpad. If you need examples of how to do it read the help or Google it. There are hundreds of examples. If you have an older version of Delphi installed there's even a richedit example project. I don't see the problem.

I would think that the compiler would do that for you - i.e. give you a compile or linker error. I must admit that my experience with run-time packages are a couple of decades old but AFAIR the dcu files of the packages are stored in a dcp file. If the linker uses the dcp file instead of the dcu files then a interface change should result in a linker error - but I might of course be remembering this completely wrong. Since run-time packages are just statically linked DLLs I believe you just need to determine if all DLL dependencies can be resolved. It would be trivial to create a small utility that loaded you application with LoadLibraryEx and have that do it, but unfortunately LoadLibraryEx only resolves dependencies when you load DLLs. Try Dependency Walker instead. It has a command line mode that you can probably use. I don't know what the output looks like though. Get rid of them (the packages, not the apps).

Move isn't the problem in this particular case. The problem is that once you logically remove an entry from the array then you need to finalize that entry in the array to clear the reference. You can do that by assigning Default(T) to the entry.

Because otherwise the buffer will still hold a reference to the T instance. For any managed type this will be a problem. For example what happens if T is an interface? Maybe some unit testing is in order...

...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.