aehimself

Based on this, you can use the old paint.exe to force-launch the new Paint 3D: mspaint "C:\TEMP\A.jpg" /ForceBootstrapPaint3D As far as I know though even "modern" apps have executables they just reside in unimaginable places somewhere under your local appdata folder. Unfortunately though I can not confirm this as Paint 3D is one of the first things I uninstall from a new Windows 🙂

Also, there's no real benefit of copying your memory stream to a string stream and loading it to the IXMLDocument that way; it just adds one more point-of-failure when it comes to encoding (if not specified, TStringStream considers the data to be ANSI encoded): constructor TStringStream.Create; begin Create('', TEncoding.Default, False); end; What I'd do is save both binary data to the disk and inspect them with a HEX editor. It will quickly reveal the differences what you might have to adjust, like encoding differences, absence / presence of BOMs, etc.

I know, I should write some documentation about most of my stuff... Until then, there's a minimum example on how to create a sample update file in this post. However, I started thinking. If you simply want to show it, why not a simple TMemo, which loads the information from a .TXT file / embedded resource / HTTP?

Do you want to embed this into your .exe version information or just to display it somewhere? I'm asking because TAEUpdateFile which comes with TAEUpdater bundles all this information - you just have to fill them. The method FileVersion returns most what you'll need.

If there is a new patch / version available it will always show up in this forum. This is how I get informed 🙂

What about writing a bds.exe which starts Delphi's (now renamed) bds.exe but deletes the shortcut once it's closing? 😄

I started to experiment with Delphi 12 shortly after it came out at work with a fairly large project. It is using ~100 home-brewn components, consists of thousands of frames (with multiple levels of visual inheritance which is a deathbed for Delphi as far as I recall) in about 1,5M LOC (excluding all external packages which we use from DCU). Until we make the decision to officially switch I'll keep using Delphi 12 as a daily driver, supporting the same codebase as everyone else and in my experience even the unpatched Delphi 12 gave less internal errors than 11.2 (which we are currently on).

You can go extremely hacky and create a "transparent" panel - and simply put all your components on this. Since TPanel is a TWinControl descendant, .BringToFront will work properly on it. You can use the source here, just change the painting slightly: Procedure TDimPanel.Paint; Begin // Omit the call to inherited in general. Self.Canvas.Draw(0, 0, _bitmap, 255); // Might need 0 instead of 255 for opacity - I don't know by heart End;

The medium and the format where your data arrives is irrelevant. Just assemble the text in your receiver routine and go on from there.

I think we used this, before getting rid of COM altogether: https://github.com/CWBudde/ComPort-Library

One issue what already stands out: for i := 0 to Length(strArray) do This should be Length - 1. This can give you a range check error.

The only “issue” I personally experienced with DCPCrypt was string encoding. While a PHP library was working on UTF8, using the built-in functions of DCPCrypt used Unicode - there’s why the end result didn’t match. Once I converted my string to UTF8 TBytes and encoded that everything started to work perfectly.

So you use a program to even write the question for you and when we don’t get what you wanted at the first place you get frustrated; am I getting this right? Don’t forget that this forum is to discuss, share and help one another; not to do what you don’t/can’t even state clearly. I wish the best of luck with your project. I spent way too much time figuring out what you want.

Sure; this is why I added that the same can be implemented between applications. You have a watchdog application which queries your main application via TCP, window messages, mapped files, etc. The logic is the same, but instead of a watchdog thread you have a separate executable, and instead of a Boolean / TEvent the signaling channel is different. I personally would go with a window message which your main program has to reply to. Easy to implement on both sides: use SendMessageTimeout in the watchdog and one extra method in the main program.

From this: It probable that AI didn't exactly say what you wanted to, but reading what you wrote tells me you want an IDE within an IDE as component and that makes no sense to me.