Lajos Juhász

In case of the FireDAC there is already OpenOrExecute.

1.) Create a new application. 2.) Set scaled false for the main form, set it's width to 100x100 3.) Run the application. Delphi will ignore the size of the from inside the DFM and will display the default 640x480 form. I cannot check the QP portal as I cannot log into. I admit this is a perfect tool to check whenever you have somewhere scaled false but also quite an interesting bug. Examine the DFM there is no With or Height for the form: object Form1: TForm1 Left = 0 Top = 0 Caption = 'Form1' ClientHeight = 61 ClientWidth = 84 Color = clBtnFace Font.Charset = DEFAULT_CHARSET Font.Color = clWindowText Font.Height = -12 Font.Name = 'Segoe UI' Font.Style = [] Scaled = False OnActivate = FormActivate PixelsPerInch = 96 TextHeight = 15 object Label1: TLabel Left = 33 Top = 43 Width = 34 Height = 15 Caption = 'Label1' end end Add those properties to the DFM and save it. Run the program the form is displayed correctly. Display the form again (Alt + F12) execute the application Width and Height are deleted from the DFM and again the form will ignore the ClientHeight/ClientWidth properties.

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.

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?

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.

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.

Maybe they removed this option. For me it doesn't work even in Delphi 10.4.2 (worked in earlier versions of 10.4).

You can check: if VarIsNull(DBGrid1.Columns[1].Field.Value) then .... Usually it's null not empty string or: if DBGrid1.Columns[0].Field.AsString='' then

I've spent a day using the new IDE. The Access Violations while building the project group still there. What's new for me is that once I got an error that some component already exists and compiling stopped working. The plus side is that I was able to move some code base from D10.4.2 to D11 very easily. There was only a few data type changes in the methods in the RTL that required changes in my code.

Come on what about the way they've changed the high dpi support (it's almost working.).

You're reaching the memory limit of the 32 bit applications. You can choose between to switch to 64 bit or to limit the query.

They left the function names to make the codebase compatible with pre D2009 versions. Some libraries unfortunately still support those versions.

That's correct the ExecSQL will create the TFDQuery object without an owner and you've to free (no matter if there was an exception or not).

type TTwenty: string [20]; This is a shortstring and should not be used in programs as it is only for backward compatibility.