Leaderboard

I created the repository here: https://github.com/bLightZP/marsGameServices

I wrote a small server backend using mars that manages a leaderboard (highscore) list for a game I wrote. If there's any interest, I will publish the source. In the same spirit and to gain some insight, I would be interested in seeing other real-world projects written using mars.

There is a interoperable bridge to GIT https://github.com/git-tfs/git-tfs

Just asked this in the Webinar, and got encouraging answer (which confirms Fred's hypothesis): Q. Did I just hear that complex forms / data modules should now load a lot faster? Has been one of my biggest bugbears in Berlin and Tokyo... A: Yes - performance problems loading very complex forms (often caused by LiveBindings even if it was not used on that form) are solved

Wow they are still (happened on the old forums as well) leaking email addresses in the usernames as they seem to be generated from the email used on the old community page ...

It's also a requirement under the European General Data Protection Regulation .

I was biting my tongue about this, but I must agree, it grinds my gears that at least the login page does not use https. (And if you have it for the login page you might as well have it for the entire site.) Passing login credentials in the clear is IMHO simply not acceptable, especially given the ease of procuring even free SSL certificates (https://letsencrypt.org/) these days. I mean, even little me runs my own mail server that has (LetsEncrypt) SSL both for the mail server and the web interface. It's not that hard.

When you are viewing the contents of a form, Delphi substitutes Unicode characters with the corresponding codes in #nnnn format. (This is valid for Delphi 10.2.3 and earlier, I do not know how it will be in 10.3). Therefore, manual editing of text strings of form elements is very difficult. After installing the Kryvich's Forms Humanizer package in your IDE, you can use a simple keyboard shortcut Ctrl-Alt-H to "humanize" all the text strings in your form's editor. This means that codes like #nnnn will be replaced with the corresponding Unicode characters. You can download and test the plugin for free here: https://sites.google.com/site/kryvich/kryvichs-form-humanizer. Enjoy!

It will not get them more customers just because it's 64bit and runs out of memory later because all the instabilities and the compiler getting into a bad state because of compile errors or what not crashing the IDE will still be there as will the poor code tooling. Going the easy/cheap way every time is what puts Delphi and the IDE into the current situation of constantly having to react to external factors and tinker around edges. Sometimes I really have a hard time believing that or you just avoid certain features or have subconsciously developed a certain habit to do things differently. Or you just use it to prepare demos.

Hi, I've created two new components based on TImageList and TImage in FMX. The new components load images from a directory during design and in run-time. Please have a look here: https://github.com/jkour/neImageTools Thanks

I can confirm this, the project was so big that was impossible to open with LiveBindings packages installed, so I removed it, and it worked. I would like to know why a project that did not use Livebindings (Delphi 7) is affected in this way.

We had the same problem with very slow opening of forms. At the end we tracked it down to a problem with LiveBindings. Disabling LiveBindings (removing the related component packages in the IDE) accelerated the opening of forms dramatically. That's of course a solution only for projects where you don't rely on LiveBindings.

Hi - I wonder if anybody else can confirm they've found that Berlin and Tokyo are much slower than Seattle when it comes to opening forms and data modules with relatively large numbers of components on them? It can take 2-4 times longer to open the same data module in Tokyo than it does in Seattle. This is when running in identical VMWare VMs with near identical configurations in terms of add-ins, components etc. (Except for Castalia - see below). It's so significant and has such an impact on productivity that I've opted to stay on Seattle for VCL work and only use the newer IDEs for mobile. My suspicion is that it's to do with the Castalia additions, which you could disable in Seattle but you're stuck with (I believe) from Berlin onwards. But that's only a hunch based on a few comments I saw in newsgroups etc. Thanks Richard