Uwe Raabe

So what do you expect a roadmap being written in?

The advantage of TFDMacro.AsIdentifier is, that it automatically quotes it according to the current DBMS.

A table name cannot be treated as a parameter. Instead you can use a macro like this: DELETE FROM &TableName and then set the actual table name with MacroByName.AsIdentifier := DestinationTableName;

Yeah, I know. Unfortunately one can only do so much as a beta tester, but the results are nevertheless far from doing nothing. One really has a chance to make a change.

If it is moving content from a backup or whatever to a new system, that can be some tedious manual work. Currently the docs for Alexandria look promising, although search doesn't work yet. Older versions may be added later.

Actually that works as expected. The problem seems to be a wrong configuration in a derived form. A simple test inheriting a form showed that this works, too. Must be some other reason for the problem seen. Up to now I cannot see a bug in Delphi here. Perhaps someone can reproduce?

Don't you think that could be seen as a bit rude by the beta testers working on it for quite some weeks now? I mean, as long as you have an active subscription you are welcome to participate in the beta and weed out all the things itching you.

Actually I prefer this method anyway. It is simple, deterministic and failure proof.

Well, I cannot reproduce that here. My testing scenario looks like this: drop a TDateTimePicker and a TButton on a plain VCL form set DateTimePicker1.Kind to dtkDateTime (leave Format empty for the moment) add a Button1Click event with the following content: ShowMessage(FormatDateTime(DateTimePicker1.Format, DateTimePicker1.DateTime)); run the program: Date/Time is displayed with missing seconds, but that was expected click the button: Date/Time is displayed with seconds select date and time control and edit date and time values click the button: new Date/Time is displayed with seconds the same holds true when the Format property is set as you suggested

When do simply reading property DateTime fail? And for versions below Delphi 11 it is sufficient to set Kind to dtkDate;

Can't you just buy a FastReport Standard license? That should work with the Community Edition as well.

Yes, it does.

Indeed, that seems to be more disturbing than the outage itself.

You can specify a different target path with the -o parameter. I know this option is missing in the help.

This is probably a project last edited with an older Delphi version, which always wrote two spaces. Alas, I don't remember which one.

D7 doesn't use dproj files. AFAIK, they were introduced with D2007.

AFAIK, there is none. If you can be a bit more specific about what you actually are after, I may be able to give some help.

Are you sure that still works with Delphi 11?

The original PDF can be found here: https://en.delphipraxis.net/topic/6357-a-book-about-object-pascal-style-guide/?do=findComment&comment=55267

That's why I suggested a lazy scheme for the calculation. When date changes invalidate the calculated value. When comparing and the value is invalid calculate it. As every list has to be compared to each other, calculating at first use or before will still have its benefits. As stated above this depends on the time range the lists cover. It is possible that one rooms list matches another ones only partly. I am unsure if this is also something being asked for.

I still suggest my string representation approach. With each dates list store its string representation, which is calculated each time the list changes (or with a lazy scheme). When comparing use the string representation. Comparing strings is usually pretty fast in Delphi.

AFAIK PDF-XChange Editor supports this.

Simple approach: Create a string representation of each list and compare the strings when needed. Of course you have to re-create the string whenever a list changes.

Note that Unit2.Mytable.FieldByName will not work because it misses the datamodule where MyTable is declared. Sticking to the concrete example and assuming that the datamodule in Unit2 is named DataModule2, declare a public function in Unit2 like this: function U2MT: TTable; begin Result := DataModule2.MyTable; end; Now in Unit1 and everywhere else you can write things like U2MT.FieldByName as long as Unit2 is in the uses clause.

The problem is caused by a change in the TStream.CopyFrom code made in D11. Someone forgot to override TZCompressionStream.GetSize returning -1 to make it work with that change. TZCompressionStream raises "EZCompressionError with message 'Invalid ZStream operation!'" TZCompressionStream.CopyFrom raises SZInvalid Zlib, tZCompressionStream.GetSize() throws an unnecessary exception Fortunately its is said to be fixed in D11.1. For the meantime I added a workaround available in the latest version: https://github.com/UweRaabe/EncryptedZipFile