Leaderboard

If you did not install from the ISO in the first place or have already changed to online mode before, open a command prompt in the Delphi bin folder and execute getitcmd c=useoffline You can as well change the SeviceKind setting to Offline in the registry in HKEY_CURRENT_USER\SOFTWARE\Embarcadero\BDS\23.0\CatalogRepository (for Delphi 12). There you can specify the path to the gof file from the ISO under ServicePath. Up to here, all this is to tell the Feature Manager where to look for the installation files. Then start the IDE and select Tools - Manage Features. There you can select Help and install it.

We have just released minor updates of our products. There are some bug fixes and minor improvements. Pascal Analyser 9.12.5 Static code analyzer All features are explained in the online documentation at https://peganza.com/PALHelp/index.html Pascal Expert 9.12.5 Plug-in for RAD Studio, subset of Pascal Analyzer Browse the online documentation here https://peganza.com/PEXHelp/index.html Pascal Browser 3.5.23 Creates documentation for your source code Browse the online documentation here https://peganza.com/PABHelp/index.html Go to https://peganza.com to learn more.

Well, the blogs were affected too...

Hello everyone, What disappoints me is that the individuals responsible for creating and maintaining these services are not juniors. They are experienced professionals who often give lectures on developing excellent software. I've mentioned this before: the Embarcadero team needs to take some time specifically to address these issues. It's tiresome to witness so many flaws coming from professionals who should set an example. As a friend pointed out, mistakes happen, that's normal, but not with such frequency. It's truly disheartening.

The problem is not the monitoring. The problem is that very often it becomes a problem with these services. Is it the fault of the sysadmin or the programmer, but this service drop needs to stop

I agree. It leaves a really bad impression - especially when it happens over and over.

For me it's the lack of communication. Errors happen, but at a certain stage they should start to communicate about the error and give some advice about expected timeframe for fixing the problem, possible workarounds and so on. I really don't care (that much) how long this takes - but it would be nice to get some regular updates about the progress made. We are now in a situation where we have to review our development environment and make it as independent as possible from the availability of Embarcadero servers. In result we have to stop using GetIt, and other services may follow.

Maybe if they just built the web servers with Delphi and use the Delphi philosophy, they'd work

The problem is not so much the bug/fault on the site (it happens to everyone) but the time taken to resolve it. Not serious.

They are painfully aware of it. It is not good for their operational reputation.

Beware of unqualified statements involving always and never. Unless the advice is to never put pineapple on pizza. That one is just a fundamental law of nature. As you've discovered it depends on the type of the variable. Local variables are declared on the stack and such doesn't involve the heap (i.e. the memory manager). Allocating a variable on the stack is basically free of cost. However, managed types need initialization and that initialization can be costly. TSearchRec contains a string and is therefore a managed type (i.e. slow). Integer is not a managed type (i.e. fast). Additionally, managed types are wrapped in an implicit try..finally block to ensure that they're also finalized. The help probably has more info on this. If you want to limit the scope just put a begin...end around the whole thing: begin var FileRec : TSearchRec; while not StopSearch do begin ... GetData (FileRec); UseData; ... end; end; Apart from that, in this particular case, you are touching the file system so the performance of inside vs outside will be dwarfed by that. ...and so the lesson here is: You don't get more useful insight by asking first.

Use post-build commands in your project options. Add the command to copy the required file to the destination folder. You have a bunch of macros to access many things. You can see the macros when you click the "..." to add post-build commands. For example $(OUTPUTDIR) in your command (such as copy) will be replaced by the actual output directory.

Seems to be offtopic.

I did some more tests: On Windows 10 1909 on a physical computer and a local drive I found that it makes no difference whether I use FindFirstFileEx or FindFirstFile. On Windows 10 1909 on a Samba share (same as in the first tests) there is still an advantage of using FindFirstFileEx, but it isn't as big as in my tests on Windows 8.1. Since the contents of the drive have changed in the meantime and the Windows 10 installation is on a virtual machine while the Windows 8.1 installation is on a physical computer I can't meaningfully compare them to the original tests.

Discovery = DFS Processing = BFS on Discovery -> Parallel worker threads processing queue? The efficiency depends on a part of Windows file share architecture that I have never dived deeply into. Coming from a single remote computer, will multiple concurrent file accesses be truly parallel, multiplexed or serialized?