aehimself

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!

3 hours ago, David Heffernan said:

I love these kind of posts. Just because you don't understand the problem does not mean the problem does not exist. 

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

13 hours ago, mel2024 said:

I am real tell me then why Edge Browser is still supporting windows 32bit and windows 7???
have you got an answer?

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

2 hours ago, Celso Henrique said:

How long does it take to buy a new server and restore a backup?

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

7 hours ago, gioma said:

I REPEAT: The problem with Delphi 11 is that the more you use it, the more it corrupts, until it becomes almost unusable!.

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.

I'm not entirely sure if that is the case but what I understood you want to write your own program to communicate with (and maybe to control) said thremostat. To do that you'll either have to have the full protocol description used (which the manufacturer can provide) OR you have to reverse-engineer it by yourself. Be warned though - reverse-engineering even a part of a propriatery solution might be completely forbidden by the EULA and / or your regional law so make sure you are permitted to do so.

If you can and would like to proceeed you don't need any Delphi application for that; just install Wireshark and connect with your PC program. That will give you enough hints to start.

If you have FreeOnTerminate := True and you call .Free, you can have 2 destructors but one will raise an AV as you are .Free.ing the StringStream instead of FreeAndNil.

49 minutes ago, rvk said:

You didn't set DoubleBuffering to false for the TFrame itself (at least not in the code I saw). So if there (for TFrame) it is still true, then SingleBufferingInRemoteSessions = false would make the difference.

 

Talking about the small program I attached; it is not present in the code or in the DFM - you are right about that. That means it is using the default, which is False for DoubleBuffering.

At least this is how I believe it should work.

Aaaaand jackpot! Adding Application.SingleBufferingInRemoteSessions := False solves the issue for good, no more dimmed memo is visible through RDP!

The only question which I have remaining - if DoubleBuffered is false everywhere in the test application, how come enforcing single buffering makes a difference? Shouldn't that be the default, if .DoubleBuffered is false on the form and on the frame?

Even if DoubleBuffered is on for the frame and the form, and Application.SingleBufferingInRemoteSessions is true, I still see the memo in the test application if I execute it in an RDP window.

No, double buffering seems to have no effect on this particular issue.

30 minutes ago, rvk said:

https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Double-buffering_and_Remote_Connections

 

Interesting read! Do I understand it correctly that if you do NOT override anything, themed and un-themed controls do not use double buffering (even if set in object inspector) if a remote session is detected?

If yes, it means we can completely exclude double buffering as a potentional suspect for this particular issue.

But, it actually reminded me to also note: the issue only appears on the system (Windows) style. If any custom style is selected, the frame (panel?) will become solid again.

Double buffering is a valid point as it's turned on in my main application. It is however is off in the test program, and unfortunately enabling it (and changing DoubleBufferedMode) doesn't change the behaviour.

Logging on to the same machine with the console session does not reproduce the issue.

Also, I doubt RDP is at fault, as it only affects Delphi 12 binaries.

Confirmed.

When building the same project with Delphi 11.2 the panel shows up solid, so this seems to be a Delphi 12 "issue".

...but why only through RDP?

Edit: updated topic title

Well that’s something I didn’t think of as a possible root cause, that’s why I did not mention that I am using D12 to compile.

I tried on remote Windows 10 and Server 2019, both behaved the same way.

I’ll check with some earlier Delphi versions.

1 hour ago, rvk said:

What are the settings under the Experience tab in your RDP connection? Ser it to highest speed and disable bitmap caching and see if that helps.

Settings are the highest possible as I was testing it on a local VM where connection speed isn't an issue. While the idea is good, disabling bitmap caching did not solve the issue.

What I am really interested of is that in DimPanel I am not calling inherited in the overridden Paint method. How come ParentBackground has any actual effect...? Probably some weird window message to set the color, I don't know...

Hello,

I have an application which utilizes DimPanels. A couple of days ago I was notified that there are some buttons barely visible; however they are supposed to be on a solid background. The issue is, something is being drawn different when the application is executed in an RDP window. Locally I receive a solid form while through RDP everything is transparent, revealing the component underneath:

Attached is the minimum test case... it simply creates a DimPanel on the form and embeds an empty frame into it. The solution is rather easy: enable ParentBackground in the DimPanel or disable ParentBackground on the frame. My question is; does anyone know why drawing differs?

DimPanelTest.7z

It seems the typo was not very long lived.

Delphi 10 Seattle

Delphi 10.1 Berlin Update 2

The Wikipedia page @Lajos Juhász linked clearly explains you cannot use anything else other that a..z and A..Z:

As for UTF8 that is used in PDF documents, which is not the same as the barcode format.

5 minutes ago, softtouch said:

Thanks, I tried that already, but was not able to have it measure the execution time of my procedures.

That's a good thing!

Quote

 

Sampling profilers on the other hand do not require instrumentation and proceed by a statistical analysis by periodically looking at which code is currently being executed by the profiled application.

The statistical nature means that not all code may be seen by the profiler (only code that takes time to execute),

 

The component itself already heavily relies on generics and other quality-of-life improvements later versions brought so as it is no, it won't compile.

However, the base principle is SendInput and an array of TInput records which should be present / can easily be imported in D7. Since it does nothing else but translating your string into TInputs and call the WinApi method, with a little bit of work invested (which I was too lazy to do so) yes, it should work just fine.