Uwe Raabe

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

I can assure they do know.

@Anders Melander Assuming the property backed by FValue is also called Value, the name of the local variable seems to be a bit questionable. TransformedValue looks appropriate. Then the parameter may indeed be named Value, even if that clashes with the property name. We often have these name clashes that only work because of scope. This could be one of the situations I would tend to actually accept it. At least I rate it much better than fighting with case sensitivity. Could it be we strive a bit off topic here?

Only speculating, but perhaps the delay is due to some major overhaul in respect to this: VCL WelcomePage Making wuppdi Welcome Page a plugin for the new Delphi Welcome Page introduced in Delphi 11 may give us the best of both worlds.

Indeed there is. That has probably been the trigger to revamp the old style guide to support the newer language features and establish it inside the developer team at Embarcadero. I hope we can expect more consistency here in the future. That doesn't invalidate the argument, though. The standard style is widely spread and most developers are quite proficient to read it. A lot of style guides in the wild are more or less small variations (if at all) of this standard. You won't ever surprise any developer presented with sources following this style. That somehow makes it unique and means it has an advantage.

Of course, everyone has its own take on these things. Most preferences just came out of habits. You like what you do and everything else looks strange. That doesn't make one superior to the other if taken out of your own perception. I'm still proposing the original style guide now available in a newer form: Delphi’s Object Pascal Style Guide. Not because it is superior or more readable. A big advantage is that I don't have to switch mentally when looking at the Delphi sources (although they don't even adhere to it everywhere) and my own sources. That said, a style guide is something a team has to agree on and follow it. While this can vary from team to team, it is not a strict law that has to be enforced. That's why it is called Guide instead of Rails. At the end, style guides evolve as Marco perfectly states in his article New Delphi’s Object Pascal Style Guide:

Having a concrete test is always useful.

I cannot see the part where FDQuery actually makes use of the pooled connection montetest.

I happen to have downloaded a copy right after publishing. Here it is... Object_Pascal_Style_Guide_-_Developers_Guide.pdf

I'm not even sure that Embarcadero can do much about it. AFAIK the server infrastructure is managed by the Idera IT department. Not rating that as an excuse, though. On the other hand, there still is the Offline Help.

Welcome to the club! For me it often helps to refresh the captcha a few times before answering it.