Sherlock

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.

41 minutes ago, dummzeuch said:

I consider this

Ptr := @SomeArray[SomeStructure.SomeIndex];
Ptr.bla := 5;
Ptr.blub := 10;
// and 10 more lines like this

as more readable than

SomeArray[SomeStructure.SomeIndex].bla := 5;
SomeArray[SomeStructure.SomeIndex].blub := 10;
// and 10 more lines like this

 

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

11 hours ago, ertank said:

That is latest Community Edition 10.3. There was 10.2.3 Community Edition which is already running on my system.

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?

So I built a list of data grouped by devices where this data came from. Each device gets his own header in a TListView followed by its data. Pretty simple and straightforward. Now those lists may get long in total but also per device so I would like to be able to click on a header to collapse its list of data. I'm pretty sure VCL.TListView can do that. FMX.TListView...not so much. At least not that I'm aware of. I'm already having a hard time at getting the click event from a header. All TListViewItems with Purpose set to TListItemPurpose.Header sadly wont fire the OnItemClick event.

Did I overlook something or other in the documentation? Anybody have a suggestion as to how this can be accomplished. Thanks in advance.

In http://docwiki.embarcadero.com/RADStudio/Rio/en/What's_New see the chapter "Fix Pack improvements":

Quote

Fix Pack Improvements

RAD Studio 10.3 Rio includes some of Andreas Hausladen's “IDE Fix Pack” fixes and improvements. Most of the incorporated fixes are focused around the IDE and include the following:

• High resolution timer caused by using Virtual Treeview.
• FindHInstance optimisations.
• Debugger using CREATE_DEFAULT_ERROR_MODE when creating the process.
• TStringList IndexOf and Name optimisations.

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.

1 hour ago, Rollo62 said:

+1 

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

13 hours ago, FredS said:

 

Nothing like a little 'Lipstick' 🙂

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?

7 hours ago, David Schwartz said:

If you want to build a REST-based server in Delphi, they offer a solution by providing a pre-built server framework that can be extended by creating plug-in modules (DLLs basically), but the IDE and components still have no knowledge of the dynamics inherent in such designs. But there's no particular benefit of one server over another -- the IDE sees them all as foreign objects that require the programmer to manipulate directly.

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!

Oooh, bulk framewok importer... that sound like very useful tool I must have!