Leaderboard

@David Schwartz I made a wrapper for assigning anon methods to TField events. My experiences: Pros: a.) quick and straightforward to assign them wherever you want. Cons: a.) debugger can't evaluate sh*t inside the anon methods b.) you will never ever find again in the code jungle wtf. is happening and why The moral of the story: Moon landing was fake.

In 1961, when Pres. Kennedy announced that mankind would go to the moon by the end of the decade, there wasn't a single person alive who knew how to do it. When Henry Ford told his engineers he wanted an 8-cylinder engine, there was nobody alive who believed it could be done. And here you are redoubling your efforts to explain to me in ridiculous detail why the simple thing I want to see possible at the source code level is impossible to do. The purpose of the compiler is to hide complexities like this from the user. Automatic reference counting wasn't viable ... until it was. Generics weren't considered viable ... until they were. There are so many things that people thought would be "nice to have" but weren't considered viable, and at the time there were perfectly valid technical arguments that were made about why they weren't either practical or even possible. Until they were. A lot of contemporary programming languages support stuff that Delphi could support, but there needs to be the willingness on the part of the folks who maintain the Delphi compiler to actually embrace them. Delphi was revolutionary when it launched, but within a few years, it got stale, and the language has only improved slightly (IMO) in ways designed to appease the marketplace just to keep people from bailing out to other platforms entirely. C# has so many cool language features that I doubt we'll ever see in Delphi. I don't know why, because adding new language features to a product that's supported by pretty hefty annual fees makes a lot more sense than adding features to a product that's mostly funded by other product sales (as most of Microsoft's language products are). I mean, what incentive does Microsoft have to keep adding new features to a language that generates relatively small revenues? For one thing, you can argue customer lock-in. For another, newbies want to hitch their wagon to technology that's more leading-edge rather than stuff their parents or grandparents used. I'm really not interested in the technical reasons why this suggestion isn't possible today. Just like I'm not interested in justifications why you can't use strings in case statements in Delphi while most other languages today allow it. There has to be a willingness on the part of the vendor to add these sorts of upgrades to the language instead of defending their absence, which is the normal case with Delphi. You're just defending the status quo. BTW, C++ was introduced about 10 years before Delphi. The first ANSI standards effort for C++ started about the same time Delphi was introduced. And now they just approved the 3rd iteration of the C++ standard, with work progressing on the 4th iteration. Meanwhile, Delphi has hardly had anything new added since the first C++ standard was released. People pay Embarcadero a lot of money every year to maintain and upgrade Delphi. The backlog of bugs keeps increasing, and the language enhancements progress at a snail's pace. What are we paying for exactly? Most of what we get are lots of technical arguments about why this or that language enhancement is not worth considering, while job reqs for Delphi dwindle and vendors want to hire people with experience using the latest language features that aren't even on Delphi's radar. Why in the world would anybody want to choose Delphi to develop a new product with a 10-15 year life span today? All the jobs I find advertised are for maintaining legacy apps. Where's the NEW product development happening with Delphi? Why would anybody want to hitch their wagon to an old, stale technology that's so far behind the language technology curve?

I'm a mORMot fan. not just because I've successfully building several application (in production) basing on it, not just because it's fully cross-platform and cross-compiler, not just because it's fully documented (the PDF manual has near 2500 pages), not just because the author @Arnaud Bouchez is full of passion, fast to respond, fast to fix issues and have a tendency to always optimizing for speed - just search their github commit logs (309 results for the word 'optimize', 'speed' and 'performance'). But also because mORMot has a good balance between a full-ORM and raw SQL. With raw SQL, CRUD become tedious and repetitive. With full-ORM (which means thing data reading/manipulation has to go through the ORM framework), you'll find everything to be limited and hard to optimize beyond CURD and simple query. With mORMot, CURD is easy (just define a class inheriting from TSQLRecord). Want to do more flexible things? Just utilize the power of SQL!

Hi Andrea, Thanks very much. Confirmed working with Postman and the delphi demo client. Still can't get my HTML to work though - it just uploads the file name not the file contents. Looking into this now. *Edit* My bad forgot the enctype="multipart/form-data" attribute from the form tag (which is ironic given that I was testing multipart/form-data, ha ha) Kind regards, Stuart

Not really, I would say. TNotificationCenter is considered to be used in DesignTime only. EMBT would respond to this issue as "by design" probably

Yes, when someone from "outer world" comes to Delphi ecosystem IDE is the first thing to be discouraged with. Because there are many serious problems indeed. It's a good idea to take an existing high quality and extensible IDE and use it as a base for new Pascal IDE. I think it's much better than try to extend Delphi IDE with plugins. The base platform should be designed with many things in mind: indexing, threading, data integrity, real time code analysis, cross platform to name a few. UI is also an important (and often underestimated!) part. On the other side I see no reason to recreate a form designer. It's good enough in Delphi (or Lazarus). What's about a language server - it's good to have to bring Pascal support to many editors at once, but it's not a way for first-class IDE.