dummzeuch

Yeah, I should have written "not trivial" that rather than "cannot". I basically did it this way because it was easy. Unfortunately I'm not as good at this as Andreas Hausladen. He would probably have just hooked the code an be done with it.

Have you checked whether this code is ever called? Since it must have resulted in runtime errors, I doubt that. So maybe there is a design flaw there.

This code must crash horribly on the first call to FreeAndNil with a non-nil pointer. So this code was either never used or the memory is already freed and the pointer set to nil before that call.

At least the Borland/Codegear/Embarcadero version of FreeAndNil never supported anything but instances of TObject descendants. And I doubt that there is a good way to implement this with overloading for other data types in any safe way.

The Delphi IDE shows a notification dialog when an exception occurs during debugging which allows to break or continue: I know what the text on the English version is, but I need the text of the German and French version. (and probably Japanese, though I doubt that I can really use it). Could you please help me out here?

I even got the Japanese text (using bdssetlang): 'プロジェクト Project1.exe は例外クラス Exception （メッセージ 'bla'）を送出しました。' Not sure whether this is correct though and I wonder whether TRegExpr will work with Japanese. But hey, there is an easy way to find out: Simply test it. 😉 Thanks everybody.

'Le projet Project1.exe a déclenché la classe d'exception Exception avec le message 'bla'.'

No, no idea.

Found it: BDSSetLang.exe in the bin folder.

Thanks. The latter is useful. The first not much, but maybe you could copy and paste just the text (Ctrl+C will copy the whole text of the dialog to the clipboard). How did you get the Japanese (I guess it's Japanese) text? Is there an option to switch the IDE language? In that case I could just do that myself. (Hm, now that I think about this, I seem to remember that this topic came up before in a different context.)

Nobody? If I don't get the the translations, the latest feature addition for GExperts will only be available for English versions of the IDE, which would be a pita.

You can't. Only moderators can. For that you need to "report post" it.

Recent IDEs are supposed to use up to 3 GB and since the language server is a stand alone executable it might use another up to 3 GB. And 6 GB might be sufficient but definitely is not plenty to run Windows 10 + the Delphi IDE, especially if you also want to run/debug your own executables.

Depends which OS runs on it. 6 GB ram is a bit low for Windows 10. But if it runs Windows XP I'm sure Delphi 2007 will work fairly well (I've got a 6 years old netbook with only 2 GB ram that is useable with it). I guess that goes for any version that still officially supported XP and probably some later ones too. 6 GB is wasted on XP though, since it supports only up to 4 in the widely used 32 bit version. Buteven with Windows 10 it should run recent versions of Delphi, probably not very fast though. Personally I have no use for that kind of computer. My office / workplace at home has enough room for a full sized tower computer, I need more space for the monitors. And I like to be able to upgrade and replace components.

A bug in the TStringGrid implementation in Delphi 10.4. https://quality.embarcadero.com/browse/RSP-28821

fixed in revsion #3182 on 2020-06-06

Matthias Eissing works for Embarcadero, so it's an official offer by the company, I guess. On the other hand, I can understand why Andreas might not want to accept it. There are always strings attached, even if they don't come in the form of a written agreement.

As far as I know, he does not have a current Delphi license any more and needs the community edition of 10.4 before he can even start working on it.

In that case you could get rid of some lines in the .dpk file. VER200 is the first Unicode version (Delphi 2009), It's also the first version that introduced Generics (no idea how usable/buggy they were in that version).

function TMemoryStream.Write(const Buffer; Count: Longint): Longint; var Pos: Int64; begin if (FPosition >= 0) and (Count >= 0) then begin Pos := FPosition + Count; if Pos > 0 then begin if Pos > FSize then begin if Pos > FCapacity then SetCapacity(Pos); FSize := Pos; end; System.Move(Buffer, (PByte(FMemory) + FPosition)^, Count); FPosition := Pos; Result := Count; Exit; end; end; Result := 0; end; This is TMemoryStream.Write from System.Classes (which apart from using Int64 now seems to be unchanged since at least Delphi 2007). It looks rather inefficient to me: It checks for Count >= 0 while in my opinion it should check for Count > 0 because otherwise nothing gets written anyway and Result gets set to 0 (Remember Count is 0 in that case) which is done after the if statement anyway. If it did check for Count > 0 it could simply omit the Pos > 0 check because we already know that it must be because FPosition >= 0 and Count > 0, so FPosition + Count must also be > 0. So, my implementation would look like this: function TMemoryStream.Write(const Buffer; Count: Integer): Longint; var Pos: Int64; begin if (FPosition < 0) or (Count <= 0) then begin Result := 0; Exit; //==> end; Pos := FPosition + Count; if Pos > FSize then begin if Pos > FCapacity then SetCapacity(Pos); FSize := Pos; end; System.Move(Buffer, Pointer(Longint(FMemory) + FPosition)^, Count); FPosition := Pos; Result := Count; end; Am I missing something? Another oddity is that the GetSize method is not overridden to simply return FSize rather than calling Seek three times. Given that there are quite a few places in the RTL / VCL (and also JCL / JVCL, Indy and of course my own code) which use TMemoryStream as a convenient way to move around some bytes, it's odd that it still has these inefficiencies.

Judging from the VERxxx constants in the package source, SynEdit2 supports Delphi 2006 and up, correct? Could you please add that to the project description? @pyscripter

Quite possible. But on the other hand I had not yet arrived at the optimization step. I was still looking at the code and tried to understand what it was doing and why. And of course there is always the "I'm doing this because it's fun" part of optimizing. Btw: The best optimization for the code I actually care about (it's about writing JPEGs and text to an MJPEG video) probably is not using TMemoryStream at all but a simple byte buffer instead. That stream just was a convenience there.

Longint = integer since basically forever.

OK, so I understand that there might be the possibility of an Int64 overflow, here: which could result in Pos becoming negative. On the other hand that would mean a stream with about MaxInt64 bytes of data, which is quite a lot: 9,223,372,036,854,775,807 or 2^33 gibibytes. Do 64 bit processors actually have the capacity of addressing that much (virtual) memory? Are there any other bugs in my implementation? There might also be no performance gain at all due to highly sophisticated features of the CPU. And of course: There might be other possible improvements If I want this to be optimized I should submit a report to Embarcadero Why did I actually bring this up? I was looking at some code that was extensively using TMemoryStream as a buffer for various operations, where it accessed the Position and Size properties all the time and thought about the possible overhead of these method calls. Then I looked at the implementation of GetSize and found 3 calls to Seek in there, just to eventually get the value of a field. And then I looked at various other methods of T(Custom)MemoryStream and thought WTF is this? That I used the Write method as an example above was pure chance, it was just the last method I had been looking at.

In ISO 9001 consistency is everything. You must have rules and follow them. It doesn't matter whether the result is correct or not, it must reproducible every single time. (OK, I'll stop now, I just have suffered too much pain due to this idiocy.)