Uwe Raabe

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.

Actually I don't know the rules. You can always pass a FormatSettings parameter fitting your needs.

Why is that nonsense? It is probably used to get the MSec part.

That may indeed be possible, but will probably turn out a bit tedious. It also doesn't have the flexibility to choose between both options. A more simple way could be to edit the compatibility settings for bds.exe and force high dpi support to one of the System values, but that also misses the flexibility. My personal favorite are the mentioned desktop links. Not only does it allow to quickly start Delphi in the desired mode, also dragging a Delphi file onto one of those also opens the file with the appropriate settings. Besides the dpi selection, I use this scheme for quite a while to handle different registry keys for Delphi.

You can do that with the command line parameter "/highdpi:unaware". That won't work with just a double click from Explorer, though. I have different links on my desktop to quickly choose between both behaviors.

I didn't say you need no query - you don't need the array.

Why the array? What hinders you to iterate through the dataset directly? Besides being easier it also avoids the memory problem when copying the complete query result into an array.

This behavior exists for quite some versions and is usually bound to the Application.MainFormOnTaskbar := True; command in the project file.

IIRC, the compiler emits a warning W1010 Method 'Create' hides virtual method of base type 'TComponent' for a construct like this: type TMyCom = class(TComponent) public constructor Create; end; That seems sufficient to fix the bug before the component is even registered in the IDE.

The former one. I was pretty sure I made that public a while ago, so that may indeed fall under the dream thing.