Lajos Juhász

I saw bugs when using custom title bars, but resizing worked always fine for me. I am using Delphi 11.2.

You should move this code to a class procedure in that case you can execute the dialog before you create the form. If it's a modalform before wm_close you have to set the modalresult. I've tested in Delphi 11.2: procedure TForm2.FormCreate(Sender: TObject); begin if not OpenDialog1.Execute then begin modalResult:=mrCancel; PostMessage(handle, wm_close, 0, 0); end; end;

I don't know how will the C++ handle the case when the Text property is empty string.

You can start from the help: https://docwiki.embarcadero.com/RADStudio/Sydney/en/Data_Change_Notifications_(FireDAC)#:~:text=The Data Change Notifications feature,database client about these changes. For more information of how to configure the the Change Views feature, you can find a demo project at: Start | Programs | Embarcadero RAD Studio Sydney | Samples and navigate to Object Pascal\Database\FireDAC\Samples\DBMS Specific\InterBase\ChangeView\Generic

You can verify your licence using LicenseManager.exe in Delphi's bin folder.

The FD reference was just to give context the reason why I have to lock all my users to a specific code page (also a nice example a problem when you're dealing with an ansi database using Delphi). it will: [dcc32 Warning] Unit1.pas(32): W1061 Narrowing given WideChar constant (#$045A) to AnsiChar lost information There is no runtime problem. The compiler will try to convert unicode string to ansistring, code points that cannot be represent in ansistring will be replaced with ? a well known behavior of windows.

That's easy for me. I use FireDAC with settings to string fields to widestring (unicode). When writing back the data firedac requires that windows is set for non unicode language to be the correct codepage (simply ignores client and db codepage). Thus I know for sure that if I convert a unicode string it will use the correct codepage. This is going to work until the database is using code page.

There is no "unicode" set in Delphi. Using CharInSet will only work on Ansi. For example on my Windows this will not show true on my laptop: procedure TForm1.FormCreate(Sender: TObject); var a: char; s: string; begin a:='њ'; if CharInSet(a, ['њ', 'а', 'м']) then ShowMessage('true'); end; Here is the reason: [dcc32 Warning] Unit1.pas(32): W1061 Narrowing given WideChar constant (#$045A) to AnsiChar lost information [dcc32 Warning] Unit1.pas(32): W1061 Narrowing given WideChar constant (#$0430) to AnsiChar lost information [dcc32 Warning] Unit1.pas(32): W1061 Narrowing given WideChar constant (#$043C) to AnsiChar lost information

You should open the Sysutils and verify the magic. A spoiler alert. There is no black magic it uses the same code as when you write ch in [.... just without a warning. When you use CharInSet you just admit that you're aware what's going on (that you string is converted to AnsiString and char into ansichar).

Can you explain how? The help clearly states CharInSet checks whether a given character is contained within a set of AnsiChar.

TApplication.CreateForm in the first place must create the instance (when the formcreate is called) and just after can assign it to mainform. You can do TMainForm.FormCreate(Sender: TObject); begin ..... MakeSurface(self); For me it's always a code smell when somebody uses a global variable or reference.

A simple debug would tell you the reason. At the moment of Application.MainForm.Formcreate the Application.MainForm property is nil.

I've noticed in the past that the IDE doesn't mark a file as changed when you only change the DFM and not the pas.

You should read the code: SQLQuery1.Fields[1].asInteger integer value of the field converted to a pointer. The problem here is that the id is not going to be a continous enumeration starting from 0.

I think this is a very bad idea. You code doesn't compiles as you're missing a letter s, the property nam is objects: Combobox1.ItemIndex := Integer(Combobox1.Items.Objects[Combobox1.ItemIndex]);

For me this is working with VCL. I set the timer to 250ms. unit Unit1; interface uses Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics, Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.ExtCtrls; type TDirection = (dinone, diup, didown, dileft, diright); TForm1 = class(TForm) box: TShape; Timer1: TTimer; procedure Timer1Timer(Sender: TObject); procedure FormKeyDown(Sender: TObject; var Key: Word; Shift: TShiftState); private { Private declarations } fDirection: TDirection; public { Public declarations } end; var Form1: TForm1; implementation {$R *.dfm} procedure TForm1.FormKeyDown(Sender: TObject; var Key: Word; Shift: TShiftState); begin case key of ord('W'): fdirection:=diup; ord('A'): fDirection:=diLeft; ord('D'): fDirection:=diRight; ord('X'): fDirection:=diDown; else fDirection:=diNone; end; end; procedure TForm1.Timer1Timer(Sender: TObject); begin case fDirection of diup : box.Top:=box.top-10; didown : box.Top:=box.Top+10; dileft: box.left:=box.Left-10; diright: box.Left:=box.Left+10; end; end; end.

If Movement = 'Down' then Square.Top:= Square.Top + 10;

You can have a strong belief that the Earth is flat but that will not change the fact that isn't. Yes, I know that the Flat Earth Society has members from all around the globe.

For Delphi the future could be Skia. There was a weak promise that in the next major release maybe the VCL is going to use it.

ballpointer:=ballpointer+1; // +1 here is SizeOf Most probably you're using a Unicoder version of Delphi where the compiler is aware that PChar is 2 bytes.

You should post a real demo that we can compile where you get that kind of error. When it's correctly you can not get thet runtime error.

Only Delphi 11 supports binary constant in the code prefixed with %. In order to use the source in older version of Delphi you should convert the constant to hex or decimal numbers.

Unfortunately I can reproduce the bug.

Now I see that TFDDataSet.SaveToStorage indeed is calling CheckFetchedAll - now I would like to know the reason why is that required.

You cannot hook up DB controls to an unidirectional query but that should not stop you from inspecting and saving it. I am using FireDAC with ODBC driver from the first version (to connect to Informix database). The data is never corrupted. The only problem I am aware is when writing to database FireDAC ignores the database locale and uses the default Windows locale for non-unicode language to write data.