Lajos Juhász

When you've a simply example than it's trivial to see a bug. Trouble is when you change old code in hurry (critical error for what a fix must be delivered instantly) and introduce another one. For example, when you have a TStringList with objects you can cast the string instead of the object. For example, in a longer code it can be difficult to spot (you read in hurry and looks ok, you know that the object is inside the list): TMyObject(fMyStringList[lItemIndex]).DoSomething instead of: TMyObject(fMyStringList.objects[lItemIndex]).DoSomething. while this will not compile: (fMyStringList[lItemIndex] as TMyObject).DoSomething. The same goes with the original example in this thread as operator instantly shows that the cast is not valid. Disclaimer. With generics you can reduce the required typecasts however I still have to work on some D2007 code and most of the code was writen using Delphi 5.

As operator checks whenever your are doing a valid type conversion or not (if not exception is raised), while when writing TypeName() it will do the conversion without a check. Thus it's a valid in Delphi to write: TStringList(4).Add('Test') Now the compiler will pretend that the constant 4 is a TStringList and call the Add method on it. This is an easiest way in Delphi to have an Access Violation. (BTW. This is a reason why I started to use as instead of hard type cast recently.)

Even if you leave png or bmp as image source you should move to ImageCollection and VirtualImageList to support various DPIs your users could use. You can also watch this video:

This forum is not supported/sponsored by Embarcadero or Idera. You cannot expect an answer here. (Lately they don't feel any need to anser any of the product related questions.)

Only minor changes are released to not require uninstall.

When in the release notes they write full installation it means uninstall and reinstall. On webinars more than once was a question why they request the uninstall steps why not just replace the files. The answer is that it's easier to test and less change to have an error. (It makes sense but a bit more work when you have to install a "patch" of 6GB).

Here it is: https://blogs.embarcadero.com/available-today-the-cbuilder-and-rad-studio-11-1-5-c-code-insight-update/ The relevant part is: Being tightly focused on C++, the 11.1.5 C++ Code Insight Update has no benefit for Delphi customers and we do not recommend Delphi customers to install it. Other than the C++ Code Insight changes, 11.1.5 is identical in features to 11.1. RAD Studio 11.1.5 is a full installation, and includes all hotfixes issued for 11.1.

I know that this will not help, but Delphi has only __history and __recovery folders by default. I don't see any _astcache. From the name it should be some kind of cache folder and should not be in the git repository.

As far as I remember this should be i:=0; SetLength(CompanyDataBase, FileSize(f)) while not eof(f) do begin Read(f, CompanyDataBase); inc(i); end; Last time I wrote a code like this was in Pascal. (Btw. to be on the safe side you should also define the record as packed).

Check out the AutoFill property of the VirtualImageList. It should be true in order to load all the images from the image collection.

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.