Lajos Juhász

The warning was introduced in D2009 as sets can only contain only ANSI characters not Unicode. CharInSet was introduced that you signal to the compiler that you're aware of the limitation and know what "you think you're doing" and how the compiler will handle the code. Of course they could handle the entire thing differently.

No, Yesterday a couple of time have had this problem. After I posted I didn't got it.

This is the first search result on youtube.

Now it's also working for me. I will have to try to find when it's not working. When I started this thread I was able to reproduce it multiple times.

@David Millington . I have only one question WHY!!!!!! I really like how the main menu in Windows works. You do an ALT+F opens the file menu and then select the submenu. That way should work every program. Now for some reason it's changed in the IDE. You have to press and release the ALT only then the main menu is selected. For years I am using Alt+F O to open files. Now the same sequence leads a letter o in the source (in case I have something selected that is overwritten).

On My System using reticle (https://chapmanworld.com/2018/10/04/custom-vcl-control-for-getting-window-handles-spy-style-reticle/) I get: Handle: 2952088 Class: Windows.UI.Core.CoreWindow Caption:Calculator Ancestor handle: 396212 Ancestor class: ApplicationFrameWindow Ancestor caption: Calculator I can focus Ancestor handle but it will not get the keyboard focus. In order to focus I have to do: ShowWindow(<Ancestor Handle>, SW_SHOWNORMAL ); SetForegroundWindow(<Ancestor Handle>); ShowWindow(<Handle>, SW_SHOWNORMAL ); Tomorrow I am going to try to find a way to get the handle of the Windows.UI.Core.CoreWindow didn't managed to get it using FindWindowEx.

The calculator. It's a kiosk type application and the user will have only one instance of calculator open at a time.

On my laptop doesn't work. Even cannot use directly FindWindow as it returns a window handle from the ApplicationFramHost.exe instead of the Calculator. Tried on Window handles from the calculator but the reasult is same as with ShowWindow or SetWindowPos.

In older versions of windows this worked: h := FindWindow( nil,'Calculator') ; if h = 0 then WinExec('calc.exe', sw_ShowNormal) else ShowWindow(h, SW_SHOWNORMAL); Unfortunately on Windows 10 this doesn't work anymore. I can see that the application has 2 top-level windows unfortunately after ShowWindow, SetWindowPos or SetForegroundWindow the calculator application get focused on the taskbar and the "calculator" window turns into dark grey and doesn't get the focus. How should I adjust this code for Windows 10?

You've to find the last released ISO image before your subscription ended.

I am not going to work on that project in the near future. When I go back to that project most probably will have to find a way to improve high DPI and to report whatever anything I can make a simple test project.

I am still using 96DPI for designer. I also have problems with the ScalingFlags property. The VCL is changing it's value during the loading of the component from the DFM. I have to "lock" QuickReport to 96 in order to work correctly. On the other hand for some controls when rescaled for higher DPI the font changed but not the width so the data doesn't fit into the controls on higher DPI.

Should not be a problem, maybe I am just lucky and the uses in my project was "correct" already in 10.4.2 for me only change was the breaking changes in the interfaces that were incorrect prior to Delphi 11.

So far I have spent only a couple of days using Delphi 11 and the project I am rewriting using it is a very small one. A couple of times LSP have had trouble to catch up with changes, I almost made a test case for Embarcadero, however magically after five minutes the LSP managed to process the code.

I experienced that the mouse stopped responding after compile. In those cases after that I was able to compile using keyboard shortcuts but it did required to restart the IDE.