Leaderboard

Although it has been mentioned before: The license isn't invalidated after subscription has run out. It keeps working and it can even be installed on another system. In case the installation counter needs to be bumped one has to contact Embarcadero Sales (in contrast to Support while on subscription) to get this increased. I have not heard of anyone where that has been denied.

Ehm, what were your hope based on then? Random mutations of code caused by solar flares?

It is commonly recommended that you should obtain a Network Named User license instead, so that you can then manage your own licensing locally without having to contact Embarcadero. You would just have to download and install the License Server onto a machine in your local network, and then you can issue/revoke your own licenses as needed.

And here we go again!

@Uwe Raabe That sounds good, but it simply is not the case unless something has changed. Some time ago I decided after having paid for the Pro version as a hobbyist, that I would be satisfied with the version I was running and did not renew my subscription. 2 months later I changed my computer name from the default Desktopxxx to a more recognizable name. That invalidated my license, and I needed an install bump. I could not get Embarcadero to do it no matter who I talked to. They eventually allowed me to renew the license at the renew rate instead of full price, even though I was outside the grace period. Of course they backdated it 2 months as well. I consider Delphi ransomware, at least the renewal (Ransom) is not that high. I prefer Delphi to anything else I have tried. It's far easier for someone without a formal computer science education, at least the connection between code and UI. Embarcadero's policy on this is reprehensible and probably illegal. Any company with an install limit policy should be required to allow their users to deactivate/reactivate installs. I have several other software programs that do just that, and even when I have forgotten to do that, a simple email to support to move the license gets a quick response, with a reminder to remember to do it myself 🙂 I even have an original Delphi 2009 Pro CD in the case with Codegear serial numbers on it that I cannot register.

If that's the case, take them to court. I'm pretty sure that's illegal in most countries.

There is a simpler way that doesn't involve keeping a second list. You can simply read in the INI values into a temporary unsorted TStringList first, and then you can loop through that list adding each entry to the live MRU normally, where the MRU insertion function looks for a duplicate in the live list and if found then removes it before then adding the new entry to the top of the list. I have updated my earlier example to demonstrate this.

While Delphi 12 supports ZIP encryption, the actual encryption algorithm has to be provided by the developer itself or a library implementing the new IZipCryptor interface. For the common PKWARE Zip 2.0 encryption (see APPNOTE.TXT) an implementation can be found in PKWAREZipCryptor.pas. The usage is shown in the following example, which extracts all files from an encrypted zip file: var bytes: TBytes; fileName: string; zipFile: TZipFile; begin zipFile := TZipFile.Create; try zipFile.Cryptor := TPKWAREZipCryptor.Create; zipFile.Password := cPassword; zipFile.Open(zipFileName, zmRead); for var I := 0 to zipfile.FileCount - 1 do begin fileName := zipFile.FileNames[I]; zipFile.Read(I, bytes); TFile.WriteAllBytes(fileName, bytes); end; zipFile.Close; finally zipFile.Free; end; end;

I'm sure they're working on it for Delphi 13 codename "Salem". (Edit: Please ignore this, if you are looking for facts!) But for now https://docwiki.embarcadero.com/RADStudio/Athens/en/What's_New#Moving_Deprecated_Features and because the formatter is not explicitly mentioned here, it's deprecated through the modeling support.

More features, better performance, fewer bugs (and if there are any not having to wait for the Delphi version that fixes them), less binary code bloat.

Looks to be yet another Bitbucket glitch - I have seen others report the same behavior recently and in the past. One more reason to move forward to another place rather sooner than later (99% sure it will be github which only lost to bitbucket back then because it did not have free private repos at that time).

That is because you are not writing to the Memo while the reading loop is running. You are writing to the Memo only after the loop is finished. Change the code to write the current Buffer to the Memo after each successful read. And don't use the Memo.Text property to do that update, either. That will be very inefficient. A better way to append text to the end of a Memo is to use its SelText property instead, eg: procedure GetDosOutput(Output: TMemo; CommandLine: string; Work: string); var ... begin ... repeat WasOK := ReadFile(StdOutPipeRead, Buffer, 255, BytesRead, nil); if WasOK and (BytesRead > 0) then begin Buffer[BytesRead] := #0; Output.SelStart := Output.GetTextLen; Output.SelLength := 0; Output.SelText := Buffer; end; until (not WasOK) or (BytesRead = 0); ... end; procedure TForm7.Button1Click(Sender: TObject); begin GetDosOutput(Memo1, 'python mtk payload', ExtractFilePath(application.ExeName) + 'bin\'); end; If you don't want to pass in the TMemo directly, you could pass in a TStream instead, and then write a custom TStream descendant that overwrites the virtual Write() method to append to the Memo, eg: procedure GetDosOutput(Output: TStream; CommandLine: string; Work: string); var ... begin ... repeat WasOK := ReadFile(StdOutPipeRead, Buffer, 255, BytesRead, nil); if WasOK and (BytesRead > 0) then Output.WriteBuffer(Buffer, BytesRead); until (not WasOK) or (BytesRead = 0); ... end; type TMemoAppendStream = class(TStream) private FMemo: TMemo; public constructor Create(AMemo: TMemo); function Write(const Buffer; Count: Longint): Longint; override; end; constructor TMemoAppendStream.Create(AMemo: TMemo); begin inherited Create; FMemo := AMemo; end; function TMemoAppendStream.Write(const Buffer; Count: Longint): Longint; var BufferStr: AnsiString; begin Result := Count; SetString(BufferStr, PAnsiChar(@Buffer), Count); FMemo.SelStart := FMemo.GetTextLen; FMemo.SelLength := 0; FMemo.SelText := BufferStr; end; procedure TForm7.Button1Click(Sender: TObject); var Strm: TMemoAppendStream; begin Strm := TMemoAppendStream.Create(Memo1); try GetDosOutput(Strm, 'python mtk payload', ExtractFilePath(application.ExeName) + 'bin\'); finally Strm.Free; end; end;

It's definitely a significant release, a major overhaul of the collection classes which reduces generic code bloat a lot. I've been using the develop branch for the last year or so in my develop branch - while it's broken things occasionally (I just revert to a previous working commit) the fact that it's tagged as beta.1 suggests it's on the home stretch and major breaking changes from here on in are unlikely. I can tell you I removed all references to system.generics.collections in FinalBuilder (dev branch, 4M lines of code so not a small task!) and am using the DI container and it's made things significantly faster (faster startup, faster at runtime). I'm also using spring4d develop extensively in the dpm package manager project. If you don't mind some risk then I would go for it.

The history of stupid licensing conditions in the USA is as old as shrink-wrapped EULAs. The one ray of hope was the original Borland "just like a book" policy.

I am not sure they would get away with that - at least here in Germany. As long as the customer actually paid for the perpetual license (this excludes the CE), the ability to use it legally cannot be prohibited just because there is no current support contract. At least a reasonable fee for the registration bump would perhaps be acceptable, but definitely not denying it completely.

If this is true, then Embarcadero is not anymore a Partner you can trust.

As an aside to this. What happens if Emba goes bust? are we all just locked out of the software? I have an active subscription but I'm of the opinion that this change makes using Delphi a very risky choice as Emba seem prepared to cut us off from using the software we own. Why can't we just move an activation from one machine to another without needing to go through the process of phoning in to ask permission?

That is outrageous. Especially for older versions which were sold as a perpetual license. Now it seems that customers cannot legitimately continue to use software they own and have paid for. Is Delphi ransomware now?