Uwe Raabe

One should mention that Delphi or C++ Builder for Linux are not able to create GUI applications for Linux. For that a 3rd party library like FmxLinux or CrossVcl is needed and both are not free either. (FmxLinux is free with the Enterprise version, though.)

To get any DFM containing the old TPNGObject loaded you need to install TPngComponents. Make sure that RegisterOldPngFormat is in the Defines (it should be by default).

Make it TComponent: function SetDBSessionNames(AContainer: TComponent; const sSessionName: string): boolean; begin // for var i := 0 to AContainer.ComponentCount - 1 do begin // var cmp := AContainer.Components[i]; if cmp is TEDBSession then TEDBSession(cmp).SessionName := sSessionName; ...

A couple of years ago I worked with a team moving from SVN to Git. They followed my advice to use Fork right from the beginning. We had two courses based on Fork to get some guide through the workflow. Both, the money spent for Fork as well as the courses was worth it. Since then SVN is history. Fun fact: The trainer giving the courses switched his own team to Fork as well after that.

It seems it was introduced in 10.2 Tokyo.

More recent Delphi versions have TThread.ForceQueue, which does something similar. Regarding the docking: I never tried it, but as it is a TCustomForm, you should be able to dock it in code. It might be tricky to find the correct target, though.

Can you try with the latest version V15.1.6 please? As I wasn't able to reproduce it at will, I cannot be sure to actually have fixed it.

I am not affected here. The Welcome Page closes when a project is opened and opens again when it is closed.

Favourites are included in Open Recent. They are marked with a heart symbol and moved to the beginning of the list.

I wouldn't remove the Welcome Page completely, but configure it to show only the relevant parts. For me that is the Create New and the Open Recent plugin. Both don't rely on external services.

That sounds easier as it is. In the DFM the links are stored as texts (the name of the linked component). When the DFM is loaded the names are resolved to the actual instance. So after loading the names don't exist anymore outside the instance. Later when the DFM is saved, the instance names are written to the DFM. To achieve what you propose, each linked property needs a place to store the loaded name when the link cannot be resolved and restored when saved. Alas, this can get pretty tricky in the case when the link was not found and you want to deliberately remove it. If we step back and ask for a simple warning without the option to keep the missing links, that may be much easier to implement.

Perhaps I am too used to add methods with MMX Code Explorer, which inserts a TODO to each method by default.

Usually this will only happen to published event handlers with empty var and code (except inherited) sections. A simple line comment in the code section prohibits it. Also, if the method is created manually it probably shouldn't reside in the published section, unless it is meant to be wired automatically on load. In that case it is questionable why it is created manually in the first place.

So it boils down to adding a comment after the event body prohibits the deletion. This sound like a valid bug report.

This highly depends on the actual code. Without one can hardly reproduce.

All the other separators have a default value provided by the operating system according to the current locale.

I'm not with you here. Format strings are interpreted as described in the documentation (Note: For the overloaded versions the AFormatSettings parameter is used instead of the mentioned global variable). So even on a German system you get 31.12.1986 while the format string is 'dd/mm/yyyy'. If the format string is 'dd/mm/yyyy hh:mm:ss.zzz' my expectation would be a result of 31.12.1986 23:55.32,456, because ss.zzz describes the seconds as a real number with 3 decimals. If this expectation is flawed because there is some rule how seconds and milliseconds have to be separated in each country, then your proposal may be valid. Unless you can provide such a standard I keep offering my suggestions from above: Either use the DecimalSeparator or always use a dot.

AFAIK, it doesn't contain milliseconds unless you change it yourself.

I guess, the bug is that DateTimeToStr uses whatever is given in the format string for the separator, but StrToDateTime/ScanTime uses the DecimalSeparator. So when you provide a dot like "ss.zzz", I would expect to see the given DecimalSeparator like it is when formatting a float, but I see a dot. While there might be ways to workaround this, it can be difficult when the calls are made inside a library using the global FormatSettings and you cannot or are not allowed to tweak that code. To make conversion be consistent in both directions, DateTimeToStr should replace a dot with the DecimalSeparator as well. If a dot is replaced with DecimalSeparator when formatting a float, why is it not also replaced when formatting fractional seconds? If I really want a dot I still can escape it. Unfortunately there seems to be no formal specification which character to use for different locales and I neither support the proposal for a MicrosecondsSeparator. So we should either handle fractional seconds like a float or constantly use a dot for all locales. Currently the implementation between formatting and scanning differ. As ever so often it happens to work on the English locale...

As what you describe usually works, there must be something you still missed to tell us. Hard for us to guess.

This turned out to make the Object Inspector unusable - better don't try this.

Usually all classes appearing in the interface section of the form are registered automatically. That doesn't cover components on the form without that corresponding field, whether the unit is added to the uses clause or not.

It seems to use whatever you put into the format string. My expectation was that it replaces the dot with the current DecimalSeparator, which would be logical as secs/msecs are decimals, but that isn't the case. After some searching I wasn't able to find some docs for milliseconds in local time formats. There are only international norms. I suggest to file a bug report and see what they have to say about it.

I found that the other way round it uses a dot when formatting the milliseconds. So either way is obviously wrong.

BTW, if you find the current behavior is wrong, please file a bug report. Otherwise the chances of changing it are pretty low.