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.

Like... through a COM port. With an IDE within an IDE? I'm still not convinced.

It seems to me you are attempting to reinvent the wheel. The criterias you listed are basically equal to an IDE... and why do you want to write an IDE as a Delphi component if there is an official one already? Afaik interaction with microcontrollers are still through serial ports (whether native or over USB) and there are even free components for Delphi to talk to a COM port. If you are sure you want to go through with this, I'd start there.

When I had an error which caused my threads to lock up, until the issue was actually found and fixed I simply created a watchdog thread. It’s only job was to query the other threads and if they are found unresponsive, dump their remaining work queue, force-close, restart them and reload the work queue. The signal was a simple boolean called “alive”. The watchdog set this to false at each thread, and each thread set it to true within processing the queue. If the variable is false after 5 seconds (processing an item was < 1 s) it was considered hanging. You can implement the same logic within applications too, using window messages, TCP or memory mapped files as your signal.

So the process of finding these is not that easy but not that hard either, I'll put it here so future visitors don't have to research / experiment. - Download @Anders Melander's Map2pdb, compile it and run it against your applications .map file. You'll get a .pdb file. - Download WinDbg and install it. Once done, go to File -> Settings -> Debugging settings and add the folder where your .pdb file is to the Symbol path list - Launch your application and when it's in the state you want to examine, go to File -> Attach to process and select your application. - In the lower-right pane select the "Threads" tab and double-click the offending one (TID = ThreadID in HEX) - Now go to the Stack tab and if everything is good, you get readable stack traces In my case @Stefan Glienke was absolutely right: As I am not using thread pools, I need to find out what does... and get rid of it, somehow...

@mvanrijnen Did you find an effective way to debug this? My application started to do the same, with a similar call stack in the offending thread: It's important to note that this thread is not a worker of mine, I don't know what or when it was created. It also safely can be killed and won't cause any (noticable) disturbances. I also couldn't find a way to reproduce the issue, one time it just thinks it's time and then it locks up.

In my experience when timing can cause errors it always can be tracked back to incorrect thread data / UI access. - Instead of just one critical section have one for each of your properties and enter / leave in every getter and setter. - Make sure none of your thread accesses any UI elements directly (e.g. Form1.Memo1.Text) - Make sure that every callback what your thread has is properly synchronized - A dialog IS a part of the VCL thread. Do not show any dialog boxes in any threads!

Like we all never said “it works on my machine” 😄

Because Win7 is the upgrade of XP on kiosks and built-in devices. If even say ATMs.

<Sarcasm> Considering the pricetag on Delphi they might still be saving for it xD </Sarcasm>

We upgraded to Delphi 11.2 at work a few weeks before 11.3 came out and using it ever since. We have at least 15 3rd party components installed, plus our own ones derived from those. The only IDE error we have is the occasional “internal error” which can be avoided by using Shift-F9. While the quality of LSP in Delphi 11 was questionable indeed I still strongly disagree with you on this. Delphi 11 really did not suffer from any other major defects.