Lajos Juhász

You can compress the file before sending. Should give you the best result.

As far as I understood XCode is needed to sign the application (I don't touch those things as I develop only for Windows and just read about other platforms in case I must do some work on them).

https://docs.microsoft.com/en-us/windows/win32/api/setupapi/nf-setupapi-setupdigetdevicepropertyw Minimum supported client Available in Windows Vista and later versions of Windows.

It's by design. Delphi form and VCL should be used only in the main thread.

In this code snippet you don't have how you set up the connection and that's the error you got. My guess is that in your code somewhere the connection's ConnectionDefName property is set to C:\Prog2\employee.fdb instead of EMPLOYEE.

Wait for the next Delphi release and try to use custom title bar. Unfortunately, in D11.1 custom title bar have bugs that should be addressed before it can be used.

Especially true for roadmap and release plan. Like we don't have to plan our releases based on new versions of the Delphi (that can ship bug fixes).

You can have it on Windows 8 or newer. In the CreateWindowHandle method set the WS_EX_LAYERED window style and use https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setlayeredwindowattributes.

Not with a new empty application and two forms.

Yesterday with a Delphi 11 application I had a situation when a modal formed showed normally on top of the main form. Opened another application and when moved back to the first application the modal form was behind the main windows. It was not possible to move the modal form forward. When before calling showmodal set the popupparent to be the main form the application behaved as should.

The exact same is with Delphi 11. Tested with: procedure TForm1.FormCreate(Sender: TObject); var f: pointer; begin f:=0; end; [dcc32 Warning] Unit1.pas(29): W1013 Constant 0 converted to NIL Here is what helps says about this warning: The Delphi compiler now allows the constant 0 to be used in pointer expressions in place of NIL. This change was made to allow older code to still compile with changes which were made in the low-level RTL. program Produce; procedure p0(p : Pointer); begin end; begin p0(0); end. In this example, the procedure p0 is declared to take a Pointer parameter yet the constant 0 is passed. The compiler will perform the necessary conversions internally, changing 0 into NIL, so that the code will function properly. program Solve; procedure p0(p : Pointer); begin end; begin p0(NIL); end. There are two approaches to solving this problem. In the case above the constant 0 has been replaced with NIL. Alternatively the procedure definition could be changed so that the parameter type is of Integer type.

After you save the data to the file. Someone can edit the file or the original data in the database, thus the program should figure out how to merge back the data.

In this case we were discussing object vs interfaces. If those were interface references it would be a bit different outcome.

My first suggestion was and still is to learn how to write a correct code. Interface is much better than constantly using FreeAndNil as band-aid solution. For example free and nil will not save you here: var x1, x2: TMyClass; begin x1:=TMyclass.create; ..... x2:=x1; ...... FreeAndNil(x1); x2.SaveTheWorldAndMakeItABetterPlace; end; Here maybe you will think you have an excellent code as there is FreeAndNil, however that will not help and x2 is still a stale reference.

No, you missed the part that you have only to learn how to manage objects. Using FreeAndNil you solve nothing. If you're unsure how to write quality code I suggest use always interfaces.

This was my first suggestion as that is the way that always works.

var a:TThing; begin a:=nil;//counter warning (I) try if //only in some cases begin a:=TThing.Create; //... end; //... if a<>nil then begin //use a for something end; //... finally if a<>nil then (II) begin a.Free; a:=nil; end; end; end; (I) Wrong comment. a is a local variable and doesn't have to be nil. Thus the nil is required to signal that there is no object assigned to variable a. (II) In this code a is nil or a valid reference thus it's not required to check if it's nil that will be done in the free method. In the next line it's not required to assign nil to a. A is a local variable and finally after the finally it will go out of scope.

Delphi help: https://docwiki.embarcadero.com/Libraries/Sydney/en/Vcl.ImageCollection.TImageCollection.Add

I never saw this kind of code, I saw: if Assigned(obj) then obj.free; Most of the time I only saw that a "developer" refuses to use free instead of FreeAndNil.

My guess is that they'll try to proove that you can use free instead of freeandnil. Often you can find code: var X: TMyImportantForm; begin x:=TMyImportantForm.create(self); try ... some boring code .... finally FreeAndNil(x); end; end;

Why not? Until it's removed from the language this topic will remain important. Unfortunately I believe even if it will be eventually removed everyone will create a private copy and continue to use that as an "important tool".

Tested with a persistent field and set the PK. It doesn't make a difference I still get: Project Project1.exe raised exception class EFDException with message '[FireDAC][Comp][DS]-200. Bookmark is not found for dataset [FDQuery1]'. Maybe UniDAC has a different implementation for bookmarks.

I've tested with fireDAC, the bookmark is never valid after reopen (however will find the record if you don't scroll the scrollbar). After every scroll I get: with a call stack: :763ec3a2 KERNELBASE.RaiseException + 0x62 FireDAC.Stan.Error.FDException(nil,???,26209084,???) FireDAC.Stan.Error.FDException($37E6CA0,???,200,???) FireDAC.Comp.DataSet.ErrorNoBmk FireDAC.Comp.DataSet.TFDDataSet.InternalGotoBookmark(???) FireDAC.Comp.DataSet.TFDDataSet.InternalGotoBookmark((144, 138, 137, 3, 81, 0, 0, 0, 5, 0, 0, 0)) Data.DB.TDataSet.GotoBookmark((144, 138, 137, 3, 81, 0, 0, 0, 5, 0, 0, 0)) Unit1.TForm1.Button1Click($37E6930) I know that this was the case with BDE, DBX and now FireDAC. For the reference my code is: procedure TForm1.Button1Click(Sender: TObject); var lbm: TBookmark; begin lbm:=fdquery1.Bookmark; fdquery1.Close; fdquery1.Open; if not FDQuery1.BookmarkValid(lbm) then ShowMessage('Not Valid!'); fdquery1.Bookmark:=lbm end;

Since Delphi 1. If you close and reopen the query the bookmark is invalid.

When you refresh the data the bookmark will no longer be valid. It's a pure luck if you don't see an error message. You shold remember the key of the active record before the refresh and call locate for it.