Leaderboard

That reminded me about a nice quote :

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.

I didn't read the book, but I'm guessing that only applies when you add those programmers to the same problem. Luckily Delphi has a ton of problems, that could each feed a programmer for at least a month

That's just nonsense. I've written plenty of applications in Delphi that applied the MVC or MVP patterns. 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. 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.

I literally just started typing same sentence. 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)...

Dear Delphi developers, first of all, I do not want to have any "Delphi Development Team" bashing here. I just try to summarize the current big picture and show the dilemma. Not going to much into details, the today status of 10.4 is: 10.4 went clearly into the right direction the development team is highly motivated and shares information the development team is open to arguments and suggestions of the community Why I am not really happy? a lot of issues have to be fixed (which are BETA level but should not be in a final product) fixing takes several n-months using the full resources until then 10.4 cannot be considered fully productive Macro, Bruneau, Dmitry etc, … they all know the problems and work really hard. The performance of the team is great but the output limited I cannot agree with the argument that 10.4 had too many new features. It's more the minimum to survive new basic strategic developments (modern language elements, compiler optimization, etc) not even started The real problem is that the resources are far too small for the real-world challenges of a full development environment. Why is that the case? Are the sales to small? (I would say no) Is the percentage of reinvestment into R&D just too small? (I would say yes) The numbers under https://medium.com/@sammyabdullah/successful-saas-companies-spend-23-of-revenue-on-r-d-3602e9dc2de are rather interesting (marketing driven versus technology driven companies). But what does the Embarcadero management and owners think, given these private equity companies bought Idera/Embarcadero for some crazy amount of money? As long as the sales (software renewals) are still flowing … why should they invest more? This means we come to the cynical conclusion that paying "as long as we pay the software renewals, no additional R&D resources will be hired". But If we do not pay anymore then they just freeze the product?! Ideally there should be a contract form that assures "software renewals go for 50% into R&D". Why? No-more marketing is needed. The renewal is (should be) a fully automatic process without large handling costs. Not easy! regards Günther

There are plenty of historical examples of Venture Capital/Private Equity takeovers in the software industry. I would assume five main reasons an investment company buys a software company: #1: Expand an under-funded company to get exponential growth. (Pour cash in to reap future rewards at a high return.) #2: Replace key management to yield better results with the same base. (Also seen as 'take it to the next level' as the original owner is incapable.) #3: Merge existing companies to scale out / share similar resources to yield a higher combined bottom line. (one HR group handling multiple companies, joint purchasing power to reduce costs...) #4: Buy and keep it afloat with 'streamlined operations'. (basically kill as much payroll and overhead as possible to keep it running and pocket the monthly recurring revenue at a much higher return due to the cost cutting.) #5: Merge technology from multiple companies to provide a new industry-changing offering. (Assumes greater worth together than apart. Cox/Dealer Track, Vista/DealerSocket are two large software company examples in the auto industry.) Which of the 5 does Embarcadero best fall into since Idera purchased them in fourth quarter 2015? Idera itself was purchased by private equity in 2014. And another PE firm took over in first quarter of 2017. Since then, they have went on a bit of a purchasing spree: Sencha, AquaFold, Ranorex, Whole Tomato, Froala, Lansa, Webyog, Travis CI, Fusion Charts... We are seeing a tiny benefit with the ancient customer portal being partially redone in Sencha. But it's a project taking many months with no end in sight with very few progress reports (so it seems to actually be a 'would appear cool to dogfood our own tools' type project with no real financial support.) We do see AquaFold now included in the Architect Edition...which seems to be a much better option than the previous offering from Idera. But look at what was purchased, including RAD Studio, and consider possible reasons for these purchases. They could be combining resources of all of these companies...something they wouldn't really announce and we wouldn't neccessarily see. They do not appear to be plowing additional cash into any of these companies to accelerate growth. So unless they have some master plan on providing an industry-changing/Visual Studio Killer project that integrates much of this technology, the general trend of each of these seems to be #4. But we really don't have any insight into their grand strategy so this is all speculation. We do have the knowledge of the previous cuts in their R&D staff with acknowledgement that they are using more lower-cost contractors instead (also easily seen in some of the new code being generated.) On the other hand, they currently state that they "invest nearly 2x the industry average in R&D as a percentage of sales" All I hope for is that Delphi continues as long as possible. I don't expect some magic re-awakening where Delphi takes a significant market share. I expect it to be hard to kill as there is just so much code out there. I also expect to see some eventual growth given all the time wasted on other new technology that needs rewritten every 9-12 months. I also expect some sort of patch/update for 10.4 very soon. I was a 10.4 fan-boy extreme but I've turned off the LSP-based Code Insight as it's just often annoyingly wrong. There were 85 days between 10.3 and 10.3.1 with 3 patches in between. We're at 50 days since release of 10.4 with one minor installer patch. I hope it's not 30+ more days before some of these major problems in 10.4 are addressed.

I see that from two sides. VCL-Side Is quite mature, bugfixes and new features OK, but who REALLY needs that ? No time pressure, low investment is maybe argueable. FMX-Side: Is under high pressure from more and more platforms (including Windows-10). Much more buggy than VCL, less mature, needs a lot of care in the future. Always time pressure, by Android/iOS time schedules, high investment is needed to cover all that. From the VCL-Side I feel quite relaxed, here and there a new language feature will do the job. Nothing is really missing here for my daily work. From the FMX-Side I can spot a massive under-investment. I regularily check the changes and additions to the feature API or mobile platforms. No or very little investment i to new API's and API changes there, only when its absolutely necessay. Why don't we have full API support for the platforms already, or at least 80% ? Why not simply put a task-force to translate all platforms API into Delphi, where mostly this would be routine work for mobile experts ? For example, why is not yet the cool AR/VR added, why did sensor-date had (maybe still have), why is camera still so slow, why not yet full Maps support, why not included full SSL-solution, ... ? Ok, there are solutions like TMSMaps, but why should I use them when Maps already were in the package. Thats what I always also have seen in VCL very sadly, why are many basic components so poorly and minimal designed, not meeting a minimum requirement in real world, just good for demo purposes. I want to use a Delphi FMX-Function, and want forget about the issues and problems behind. Embarcadero should flatten our way, and fix Location, Sensors, Permissions, etc. etc., so that the developers can use and rely on any function. Still there is too much special-knowledge needed, to get a many things running. I'm a lazy developer, want to use API's that do what they promise, don't need to know all details behind. The FMX-Side would be the right place to turn Embarcadero's future, if they could profile themself well as all platforms solution. In marketing yes they do already, but in realiity many of the promises were missing, and I can see not much work on this. A good indicator are also the demos and samples, which were revolutionary at those days, but getting lame and non-functional nowadays. Why is no ony improving, cleanup these features and add new demos permanently, because this is the main entrance for new customers too. I hope everybody understands, that when newbies checking an IDE where 50% of interesting demos don't work, they immediately take a step back and look elsewhere ( at least I do that with new technologies ). If everything works as expected, and without a lot of fumbling around, then the newbies will be catched more easy. These are only a few points where I would like to see a lot more investment. Still I hope for the time factor, so that it might get better in the near future, but for me an IDE which can support platforms out-of-the box should have a good weight in the market. For me mobile, cloud is clearly the future, combining with front- and backend desktop this is a killer feature. There are other nice boys in town, but they all have their pros- and cons as well, and IMHO RadStudio does not so bad in comparison. For the goal to achieve less "investment" gaps, I would like to see a much faster system of updates, patches and hotfixes, to keep us developers up running with high and accelerated pace against all other solutions.

We usually hold off moving to new major versions until Update 1 is out, but we do make the move. As far as I am aware, nobody on my team has ever had a problem with moving their IDEs to new hardware after XE4, and we use the regular named user licenses w/o any license server. Apart from the quality of the initial release, my biggest Idera/EMBT gripe at the moment is understanding why the f..k they keep spamming me with emails suggesting that I order 10.4 with a discount. Not only do I get these from EMBT, but also from the local reseller. I am on a subscription, FFS!

Still actively developed (by me). RAD Studio 10.4 includes an updated trunk version from Indy's GitHub repo from about 2 months ago. I'm not in charge of, or involved with, how Embarcadero incorporates help files for 3rd party components. But I do recall that Indy's help files are included, somewhere. Although, Indy's documentation is quite dated, it hasn't been updated in many years. There have been property/interface changes made over the years that still need to be documented.

For me I'd go with AddObject as its better than using Pair<Name, Value>. However you can either set CheckListBox1.Style to lbVirtual and then handle all data event. Or simply set Style to lbOwnerDrawFixed and owner draw your control: // CheckListBox1.Style := lbOwnerDrawFixed; procedure TMain.CheckListBox1DrawItem(Control: TWinControl; Index: Integer; Rect: TRect; State: TOwnerDrawState); var Flags: Longint; Data: String; FCanvas: TCanvas; CheckListBox: TCheckListBox; begin CheckListBox := TCheckListBox(Control); FCanvas := CheckListBox.Canvas; FCanvas.FillRect(Rect); if Index < CheckListBox.Count then begin Flags := DrawTextBiDiModeFlags(DT_SINGLELINE or DT_VCENTER or DT_NOPREFIX); if not UseRightToLeftAlignment then Inc(Rect.Left, 2) else Dec(Rect.Right, 2); Data := CheckListBox.Items.Names[Index]; DrawText(FCanvas.Handle, Data, Length(Data), Rect, Flags); end; end; EDIT: Removed ExtractName function.

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

I found this forum searching for anything related to MVVM and Delphi; there is a Stefan post here where he says something on the line of Delphi MVVM won't work together I have the book; I've read most or perhaps all that is written about MV* and Delphi I'm working with some friends towards MVVM, but time is scarce 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

Particularly since MVVM appears to have been created largely to fit the specifics of C# and XAML.

Nothing is stopping you from doing DI. Why do you need that "in the box"? As for MVVM I'm not convinced Delphi should do it at all. Not every pattern fits every language.

The book has many (good) points. One of them is that you can't naively solve a deadline problem by throwing more manpower at it; Time=Work/Resources is a meaningless equation. I assume this is what you allude to. However it also points out that you can solve a 2000 man-hour job in less that 2000 hours by allocating more manpower if the job can be split into separate, largely independent, tasks. I think that applies here.

Everywhere but in Delphi, we see MVVM, MC, MVP architectural patterns Everywhere but in Delphi, many techniques as Dependency Injection are common About DI, there is some work out there, but MVVM and such, just doesn't exist All that should come in the box IMO, Delphi programming hasn't changed so much on the latest 25 years. Yes, I program since D1, and before that, since Turbo Pascal 3

The problem with that is the the problems tend to interact with each other.

That reminded me of

We all know that it still takes some time (at least based on all the open serious issues). But my topic was to change something for the future. I am sure that Marco and the team is clever enough to solve a lot more problems and enhance the product if they get more money (very simple calculation). But the money is "used" elsewhere and this should change.

10.4 was very late, so (I estimate) 10.4.1 will be late, too. It seems where is a shift from 2 versions a year to an version every 2(+) years. (With less new features btw.)

I guess this bug may be some inheritance from DOS/TurboPascal years... when the 8087 was already there and no thread was involved.

Rethinking Delphi Floating Point Control Register Management.pdf

I agree with you. IMHO it is less a breaking change than a bugfix. The behavior you propose seems more stable, in terms of thread-safety. Note that FPC RTL mimics the same behavior, and is affected by the same bug. Is just calling Set8087CW() at thread start enough as a workaround in user-code?

I don't think so. It's very important that code behaves the same way for both 32 and 64 bit compilers and indeed for the non Windows platforms too.