Bill Meyer

17 minutes ago, Stefan Glienke said:

The general hints in the readme are very valuable (and made me revisit some of my ifdef checks) - apart from that it reminds me a bit of https://xkcd.com/927/

As a former colleague was fond of saying, the nice thing about standards is that we have so many from which to choose.

27 minutes ago, Edwin Yip said:

@Bill Meyer My first time hear about Affinity Designer, did a google and it seems to be very powerful with an affordable  price tag.

But I'm out of curiosity - do you have any design background to be able to make professional-looking icons? Or is Affinity Designer that user friendly to be able to enable a programmer to make good looking icons? Thanks.

I only do occasional graphics work, and Affinity Designer is a more realistic option for me  than an Adobe subscription. I am not a graphics designer, but have done quite a bit of graphics work over the years. And I would say that Affinity Designer does make it relatively easy, even for a dabbler, to produce good results. There are many good videos on youtube. I would recommend this one, to start: 

My limited experience with SVG in Delphi is very recent. I was in need of some icons, and after a bit of rooting around, I found that the TcxImageList from DevExpress supports SVG. I used Affinity Designer to create a few suitable images, and used them with no difficulty. I did discover the lack of text support, but resolved that in the one icon I made which had characters in it by converting them to curves. An added benefit to me was that Affinity Designer has a collection of simple shapes ready for use, and most of what I needed I was able to base on those shapes. Being able to use SVG was a huge benefit. I would have passed altogether if I had to color images pixel by pixel.

17 hours ago, Fr0sT.Brutal said:

Yep, I always wondered why so many people use concrete version defines that make the whole code unusable when a new version arrives.

I suspect it is because that was the first model anyone created, and others simply grabbed it, following Design Pattern #1: Copy and Paste. At some point it became a matter of intertia.

7 hours ago, Fr0sT.Brutal said:

I gathered most valuable ones of them in https://github.com/Fr0sT-Brutal/Delphi_Compilers (intended for library devs that have to support many compiler versions)

One of the best things I have seen online in a long time.

2 hours ago, Vincent Parrett said:

I would approach this from the point of view that all data provided by the client is bad until proven otherwise - seriously, expect bad data, when it' encountered report that and exit/stop gracefully (with an error message that enables the client to fix the data).  

In contractor role, I would, as well. But if my manager determines we're not to do that, then I'd be stuck.

7 hours ago, Lars Fosdal said:

Add a Caption: string to TResult and try again.

It will set TResult.Caption to A, and you get no hint or warning that there is a name space collision.

 

Using inline variable declarations - you can eliminate with without a lot of extra code.

procedure TForm1.FormCreate(Sender: TObject);
begin
  var r := GetResult;
  Caption := r.A;
end;

 

  var p := GetComponent as TPanel;

 

And even without the inline variables, it is pretty minor compared to the pain which comes with with.

22 minutes ago, dkprojektai said:

Thank you all, what I found - disable all to False (for frxPDFExport9). It helps a little. There is picture (8 KB), but I think, it's not this who gives low speed for building PDF. For me 5000 records was build thru 15 seconds. It's too much for me. I use 6.6.9 version and D10.3.

Again, with no knowledge of content, it is impossible to speculate. If one row per record, you are talking about roughly 60 pages, and though we always want things to be fast, 15 seconds for 60 pages doesn't sound terrible.

You need to do some profiling. Also isolate the timing of the report production from any data preparation. Lacking any detailed knowledge of your code, we can offer no specifics.

5 hours ago, dkprojektai said:

Hello, 

 

Does any body face with problem - generating pdf speed...

 

I use Fast Report:

    frxReport9.PrepareReport();
    frxPDFExport9.ShowDialog := False;
    frxPDFExport9.FileName := FormatDateTime('hhnnss', Time)+'_Report.pdf';
    frxReport9.Export(frxPDFExport9);

 

this code works extremely slow with more then 5000 dateset records.

 

Is there any speedy alternative?

 

That code is not much help in understanding the speed issue. What is the data source for your report? Is it the actual report generation which takes time, or the data preparation? In other words, what is happening in PrepareReport? And what do you mean by "extremely slow?" How many pages are produced, and in what time period?

I work routinely in ReportBuilder, and these are the issues I would look at. One more: If you produce in your report a line saying page x of y, I would guess that FastReport will generate the report twice. Certainly that is how ReportBuilder does it.

Apart from these issues, I found a few years ago that there can be huge performance differences among the different in-memory datasets, so I wonder whether that may be a factor for you.

14 hours ago, Lars Fosdal said:

OMG, Yes! 

A year ago, I was able to reduce the total unit dependency cycles in a large app by 25%. The build time reduced by a factor of 8, even though the cycle count is still embarrassingly high.

14 hours ago, Lars Fosdal said:

Well, the next MacBook Pro will be ARM64.

If that exercise works out, will any of the Macs remain x64? There already is a Windows for ARM64. The only constant is change. 

Mac who???

2 hours ago, Lars Fosdal said:

There is no shortage of things that can be improved in Delphi.

Too true.

2 hours ago, Lars Fosdal said:

I wish they would do more with the language. Especially generics constraints need more love. Attributes are still somewhat half-baked.

 

I wish they would do more to improve the generated code for efficient memory access and math / vector math. I'd love an ARM64 compiler for Windows, as well as Linux/R pie.

Agreed on generics. Toiling in legacy code, I am so far from attributes I can't even imagine using them.

Code efficiency certainly needs attention. ARM64, meh. Linux... been trying to make it a thing for myself for a quarter century. But in my area of work, it;s just not a factor.

2 hours ago, Lars Fosdal said:

I wish the debuggers just worked and kept working and were smarter with regards to multi-threaded code. 

 

I wish the IDE would do incremental background compilation so that running your edited code was near instantaneous.

Yes! Reliability of IDE and debuggers are bedrock. Background compilation would be nice, but not essential if compiler speed is high.

I'd wish for better tools for dealing with legacy issues. MMX identifies unit dependency cycles, but in a large app, the challenge is then to discover in which units they are actually created, and which modules are merely caught in the chain.

I would rant, but need the energy more for finding patience with IDE and debugger problems. 😉

13 minutes ago, Anders Melander said:

And the only one that knows what it does left ages ago... So it's not even possible to test if the new implementation works the same as the old because nobody knows exactly what or why the old did.

Yup. That's what I deal with. Every. Single. Day.

We are in the same trenches.

41 minutes ago, Kas Ob. said:

...hypothetically written and developed by best of the best (grade A+ experts)...

All teams have turnover. New team members are typically ignorant of product intricacies. They may be expert developers -- or unseasoned but well educated recent graduates -- but in either case, they may easily overlook details which create issues. This is simple reality, and applies not only to Delphi, but to any specialized and complex product.

2 minutes ago, Lars Fosdal said:

That said, when modifying or refactoring legacy code - unit testing and integration testing is more than a little helpful.

Testing is the only way to ensure that you have achieved only the changes you intended and haven't inadvertently introduced something unfortunate.

All true, but legacy code tends to contain massive routines and an unpleasant degree of coupling. Testability requires unit isolation, and -- ahem -- comprehensible routines.

Gentle and iterative refactoring is the only viable approach I see to dealing with some of the code monsters which live in legacy apps. And rewriting is rarely an option, since it would often be necessary to refactor to achieve enough comprehensibility that you could write a design spec.

6 minutes ago, Lars Fosdal said:

When you sit on millions of lines of code, in projects with several developers, implementing thousands of functions, and integrating with numerous systems, you need automated unit testing, automated integration testing and dedicated testers with proper test plans.

 

We are not talking about one-man toy projects. here.

Sometimes, you can only creep toward unit testing. There is a tremendous amount of legacy code out there.

4 minutes ago, Mike Torrettinni said:

Well, we see these things differently. I see the progress, the changes - I like all the buzz being created around Delphi. We could argue the effectiveness, but compared to prior Idera times... I welcome the changes.

And Embarcadero is software company, there are some limitations on how marketing to attract new customers is effective with software products vs the cost of it.

Efforts are encouraging; positive results are better.

As to the titular question of the thread, I consider "cash cow" to be prejudicial to the discussion. Embarcadero is a company, not a charity, and Delphi is a commercial product, not an open source free tool.

I rather suspect that all of us here labor for a pay check -- does that make us evil?

At any event, the term cash cow is normally applied to a product, not to customers.

11 hours ago, Mike Torrettinni said:

Compared to 10 years ago, they definitely increased their online presence, just look at the website. The email campaigns have become annoying especially before new releases, but seems they are better coordinate across offices.

Cool App competition, online academy, t-shirt design contest, ... I don't remember were they doing all this prior 2015?

And how are people not already using Delphi being led to the site? Yes,  it is good that the site has been improved, but it is likely preaching to the choir. The other items you mention have, I think, been mostly promoted on the site. So again....

13 minutes ago, Mike Torrettinni said:

- improve marketing, sales channels - I think we can all agree that they are doing a lot in this area, in some ways more successful than others

Marketing? Doing a lot? Examples?

21 minutes ago, Anders Melander said:

True, there's no wizard that can, clickety-click, write your template code for you, but it's really not that hard to do yourself once you've decided how to apply the pattern.

And that is probably at the heart of the complaints.

22 minutes ago, Anders Melander said:

It makes no sense to insist that one tool should be good for all problems or that Delphi should support all patterns. There are patterns that work well in Delphi but which doesn't fit for example JavaScript. That doesn't mean there's something wrong with JS. It just means you need to use a different pattern.

To refer again to Brooks: There is still no silver bullet.

On 8/29/2019 at 3:56 AM, Stefan Glienke said:

IMO not - the beauty of MVVM comes from things that I have not seen yet seen achieved in Delphi.

It requires special support for every existing control by either subclassing or other ways, CoC and existing data binding solutions are very brittle and easily break when renaming things, functional approaches like done in ReactiveUI are almost impossible or create clunky and bloated code.

The problem of "special support for every single control" will not be easily remedied. I doubt it will be addressed at all.

9 minutes ago, Dalija Prasnikar said:

Delphi devs always complain all logic is dumped in form (event handlers), Android devs always complain all logic is dumped in Activity (Delphi form equivalent), iOs devs always complain all logic is dumped in ViewController (again Delphi form equivalent)...

Ah, but the "dumping" is inevitably triggered by a thoughtless coder. I have never seen Delphi insert an event handler without human action. 😉

21 minutes ago, Javier Tarí said:

Delphi programming makes way too easy writing messy code, with iron-clad coupling between interface code and business rules

That's a big point against Delphi

You can write bad code in any language. It's a poor workman who blames his tools. Delphi is not perfect, and certainly we battle defects in the IDE, but failure to design is a plan for failure in any language.

Just now, Javier Tarí said:

You provided a good example of what I'm arguing...

 

Do you mean that in Delphi we don't need MVC, MVP, MVVM and so on?

 

Or perhaps is just that in Delphi we don't have anything like that?

I mean that not all patterns fit all languages. XAML is not a feature of Delphi. Examples have been written of MVC and MVP in Delphi. A book has been written about MVVM in Delphi, though it is not clear that what it describes is actually MVVM -- an objection raised by Stefan Glienke, to whom I defer.

In my experience, one of the most common patterns in Delphi legacy apps is the anti-pattern of large routines on forms in event handlers. That is something the double-click on a button and write code makes all too common. Thoughtless coding. Patterns are no guarantee of good design.