Sherlock

It is always good to try and be better than the hosting OS, and if the service is that vital, I'm sure you made risk assessments leading to counter measures for DLL-injection and the overall adverse effects of DLL-Hell. If you did it just because you could...I strongly advise to reconsider. But we are drifting away from the topic. Sorry for that.

Considering you'll have to compile all the DLLs with every new release anyway in order to avoid at least part of DLL-Hell I fullheartedly agree. Furthermore DLLs are quite a security issue: https://www.youtube.com/watch?v=HVigruKph74

https://cc.embarcadero.com/item/30870 Clearly the more, um, agreeable source.

We are a peculiar kind, that expects simple but prefers to do complicated.

Oh, thanks. I thought there was an article on FMXExpress. I'm sad to say I don't have time to inspect code that comes without any explanations regarding purpose, function or instructions. So I wont be looking into this, but thanks anyway.

Do you have a link for the original? Can't seem to find it on FMXExpress.com. Thanks.

OT: JSON is cool and all, but it also promotes dropping all kinds of junk in it without thinking. Well maybe a little: "Let the next guy take care of this" Sherlock

While I believe performance benefits to be true, I wonder how often this is checked and verified. The compiler team may indeed have sped up things in the more recent releases.

Correct! Luckily I have very few records and if I need a list of them I use generic lists and the readability is just fine. Edith also feels the need to mention I have no legacy code to deal with aside from Delphi (hahaha, small joke). So, of course Thomas' method is a very good and simple way to increase readability in such problematic code segments.

And I would identify the type behind @SomeArray[SomeStructure.SomeIndex] which you would have to do for that typed pointer you're using anyway and gotten a variable of that type. Making this just as readable without explicit use of pointers: Element := SomeArray[SomeStructure.SomeIndex]; Element.bla := 5; Element.blub := 10; // and 10 more lines like this I am very well aware, that there are pointers floating around behind the scenes all the time. But I prefer developing with a high level language also because I wont have to deal with them.

Aside from performance I have never considered pointers to be an improvement for readability, it's something that's messed up in my brain I guess. And the way it was taught back in the day: Calling it "pointer arithmetic" really did not help understanding the simple things that are going on there. Luckily there is no syntactical need for pointers in Delphi anymore. Been living free of ^ and @ for years now. Of course sometimes some API smuggles in PBytes or PChars, but its nicely encapsulated.

My 2Cents: Storing all kinds of (overall) useless information into the registry is a nuisance. It is like back in the day where everyone stored useless information into the win.ini increasing boot time severely. Which forced MS to up the game and introduce the registry. Of course, the registry is much more performant and flexible, but it still is actually something used by the OS for the OS. It is MSs fault to actually let all the hoodlums in and manipulate it. Nowadays reading and writing registry items can cost a noticeable amount of time. And considering that 90% of the applications that write into the registry don't bother deleting their entries at deinstallation time (at the latest), it is full of dead stuff (hence the registration cleaners, that tend to break stuff). So I applaud the idea to store size and position information into a simple, easy to find and delete, file.

Please consider RSS together with an appropriate App. For RSS details check this thread

As I have understood the licensing statements, the 10.2.3 CE will no longer be working, once the serial expires. As usual, I understood nothing...carry on.

I know how to populate a TListView, I just can't figure out how to collapse all entries for a header. Here is a mock up of what I mean: Clearer now?

In http://docwiki.embarcadero.com/RADStudio/Rio/en/What's_New see the chapter "Fix Pack improvements": So nothing connected to the compiler. Way to go that extra mile, EMBT.

Just gotta love those hi res pics 😄

Simple and great! Thanks for that.

Minor hint on that subject: That is what the heart in the lower right corner is for.

It works for Microsoft, why not for us?

I believe this is the most common problem in our line of work: not realizing what really is the problem. 😄

Guys? Topic? @David Schwartz I am a classic Delphi developer and I can't follow your step from Client/Server to ... well what, really? All I'm reading is that the Client no longer communicates with the database server directly, but via something like REST. So there is an extra layer added. But Multi Tier architectures have been around for quite some time, and Delphi copes just fine. Am I missing something? It still is Client/Server, only with 1 to n middle men. Of course you can toss all DB connectivity components, but who cares? Its just work, and that is what we are paid for. With every new layer between the Client and the rest (no pun intended), there comes change to the Client. As well as any change to that last layer will result in yet more changes to the Client. Again, just work. So what, in essence are you getting at? Does Visual Studio support total immersion of every tier into the IDE? Was that what this was about? If so, wow. Just wow. Gotta look into that sometime. But I would not build DLLs, and I would not use Delphi, nor C#. I would build Python modules that would be run in an Apache or whatever. Also work I know. But do you really want to put us out of work? 😉

Vai ce nebun ești! 😄

157 reports, looks like the product is being used. Nice! I chose to look at the world positively today.

Yes, please!