aehimself

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.

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.

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...

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.

That's a good thing!

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.

In the past I had an application which imitated keypresses to type text to any field in any application using SendInput. Later the typing logic has been extracted and is now accessible as TAEVirtualKeyboard for generic unicode or TAEVirtualEnUsKeyboard for forced EN-US keyboard layouts. The backdraw is, for this to work the window and the input field has to have focus. It might be a good starting point still, though.

As an alternate, the path where this file is attempted to be loaed from can be changed in Program Files\Embarcadero\Studio\xx\bin\Codegear.Common.Targets inside the PropertyGroup tag. This is what we ended up using on Azure DevOps at work: Be careful, though. Changing these to a static path will result all users on the same machine to use the very same environment.proj and/or envoptions.proj. This might be, or might not be wanted.

Importing an other 3rd party library seems to be a huge overkill just to use a simple mutex. I have the following code in my .dpr file before any form creations: handle := CreateMutex(nil, True, 'MyAppName'); Try If (handle = 0) Or (GetLastError = ERROR_ALREADY_EXISTS) Then Begin // TMessageDialog.ShowDialog('Only one instance can be running at a time!', dtError); handle := FindWindow('TMyApplicationMainForm', nil); If IsWindow(handle) Then Begin ShowWindow(handle, SW_RESTORE And SW_SHOW); SetForegroundWindow(handle); SetFocus(handle); End; Exit; End; // Form creations, initialization, run here originally from .dpr Finally CloseHandle(handle); End; Works like a charm, and you only need WinApi.Windows.

What about dimming out your UI and showing the wizard in the middle, in front of the dimmed UI? A while ago I managed to create a panel which does just that, feel free to check it out. How to "dim" a TabSheet? - VCL - Delphi-PRAXiS [en] (delphipraxis.net)

This bothered me for ages and never could figure out when it opens in the background and when it opens "correctly". What is even more strange I forgot about this behavior when I wrote my BDSLauncher... anyway, now it will attempt to bring the selected instance to the foreground after the file has been opened. Thank you for reminding!

It indeed exists, and works as advertised. I grabbed installation instructions from somewhere a long time ago: - Component -> Import Component -> Import ActiveX Control -> Select Terminal Services (mstscax.dll) - Palette page: MsTSC, unit dir name: Delphi Lib folder, Search path: empty. Check Generate component wrappers - Install to New package - Enter the same name (MsTSCLib_TLB.dproj) under Delphi Lib folder - Try to build package just to fail - Change Property type of ConnectWithEndpoint to "OleVariant", build package again - Right-click on MsTSCLib_TLB.bpl in Project manager and select "Install" After this different versions of the control will appear on the palette and everything can be set (RD gateway, compression, audio redirection, key capture, etc.) via properties what mstsc.exe allows. Kinda handy stuff.

I'm using the following code in my custom DBGrid-descendant to have a separate popup menu for the content and the header, which works well. I suppose with little to no modification it can be applied to a TStringGrid too: Procedure TDBGrid.MouseUp(Button: TMouseButton; Shift: TShiftState; X, Y: Integer); Var gc: TGridCoord; Begin If Button = mbRight Then Begin gc := Self.MouseCoord(X, Y); If gc.Y > 0 Then _gridpopup.Popup(Mouse.CursorPos.X, Mouse.CursorPos.Y) Else If gc.Y = 0 Then Begin _colindex := gc.X; If dgIndicator In Self.Options Then Dec(_colindex); _headerpopup.Popup(Mouse.CursorPos.X, Mouse.CursorPos.Y); End; End Else inherited; End; _gridpopup is the content popup menu, _headerpopup is the popup menu for the header, _colindex is an integer which can be used later on to determine which column the popup menu was popped up from.

The VS2022 you mean which ate up all 16 gigs of memory just when loading the project on all of the developer PCs, finally crashing the OS itself? Not sure if it got fixed since then, but the same project works just fine in 2019; this is why we are not switching. And btw, VS2019 still receives patches. We are all biased, we all have a preference towards one IDE or an other. The important thing is to stay objective even when we get frustrated.

Even at work, where we have DevExpress and a number of other, chunky components installed the IDE loads our big legacy project up in less than 20 seconds. Add 10-15 more seconds of compiling and I am in debugging. Compare that with VS2019, which needs ~1min until IntelliSense kicks in, 1,5 min of compiling, 10 seconds of after-compilation-thinking and finally the project launches. I'm sure there are faster IDEs out there, but Delphi really isn't that bad from startup perspective.

My advise would be to branch your master and do the conversion there. That way you can cherry pick bugfix commits between them but they would be separated enough. When conversion is done simply merge/cherry pick everything back to master. If you have no version control (which you definitely should) you can start to use IFDEFs to separate code. This will make it less readable and does not allow .dfm changes though.

This was the exact approach I took to convert our legacy application to 64-bit. Our custom component package took about 2 days (plus 2 to fix issues which weren’t obvious), the program itself (1,5M loc) was only one day (plus 7 for fixing the same). I’m not saying it’s the most sophisticated method but it’s one of the easiest and definitely viable.

The pros of using window messages is you can apply the same logic to TFrame-descendants too.

I met that site a couple of times but it never managed to gain my trust for the exact reason you mentioned - a compiled DLL is an extremely unusual way to distribute your code and can do things in the background what you don’t want. “Don’t fix something which ain’t broke” applies here as well. Don’t purchase something and start to adapt all your code for it if they are working without issues.

You can discover installed Delphi versions, list their running instances (or start a new one) and instruct them to open a file via TAEDelphiVersions. This is exactly what my configurable BDSLauncher is based on, maybe that one will fit your needs without any extra coding.