Leaderboard

I don't like it either. Like everyone else I would love for every bug to be fixed yesterday, the compiler to produce better code, the VCL and RTL to support all the new shiny stuff and that my wife was 20 again. I'm assuming Embarcadero has the same wishes (Okay, maybe they don't care about my wife) but obviously their first priority is to make money. They're not in it for the Karma. I myself used to be very vocal in the field test newsgroups in my critique of the decisions made by the various owners of Delphi during the years, to the point that I was asked not to participate in the field tests. So it's not like I don't understand the frustration or the need to vent it. However I also know that I don't know all about why they make the decisions they do. If I were in their shoes I might make the exact same decisions. Of course they make mistakes. They make huge mistakes sometimes *cough* Delphi 8 *cough*. That is obvious to all. But it gets really tiresome to constantly read this whining about how bad Delphi is or how evil Embarcadero are. It's leading nowhere. Not a day goes by that I don't curse some part of Delphi to hell, but at the same time Delphi has payed for my house, my cars, my children's education and all my vacations. Anyway, this has nothing to do with hash tables. Sorry for hijacking the thread.

@Alberto Fornés Currently you can have any number of THtmlView component inside report bands, each component can have own source and render div, table, etc.

Worthless, they give a crap about win32 codegen. There are way more severe issues open for ages...

Okay. This explains everything. This is the Message Of The Century.

@microtronx thank you, this month.

Most likely so, but on other hand without issue in bug tracker, chances it'll get fixed is even lower 😄

Report Builder

You can use SVG images defined via href, standard FR DB fields (as shown in video) which may contains HTML too, or load complete HTML using http or other protocol, but last one requires overriding one component method.

Every instance construction can fail because of out of memory error. But there is nothing special in surviving such exception. It only depends what you are doing at that time. Whether it will be recoverable error or not depends on the developer. Also throwing exceptions during construction is not a trap... Delphi has mechanisms in place that allow full cleanup and recovery. That is all that matters. If we didn't have exception throwing construction, we would still have to deal with all kind of "exceptional" situations where you would have to be prepared for handling them. And it would not be any simpler than what we have now. Basic problem in this particular case is non trivial ownership transfer, not the exception throwing constructors per-se. Solving ownership transfer solves the problem. Moving construction of dependent class to within owning class eliminates ownership transfer and solves core issue. (Another approach would be using reference counted classes and automatic memory management)