Leaderboard

Refrain from methods with half a dozen parameters, that's just not readable anymore. https://sourcemaking.com/refactoring/smells/long-parameter-list Use a parameter object, and make the values nullable/optional. Then you don't even have overloads for your method anymore. And validation can happen in the scope of your argument object. Like this: type TMethodArgument = record action: TTaskAction; task: TTask; schedule: Nullable<TDateTime>; isQueueOnly: Boolean; hasImmediateExecution: Boolean; class function Default(): TMethodArgument; static; function getIsValid(): Boolean; end; procedure TMyClass.someMethod(const arg: TMethodArgument); begin if (not arg.isValid()) then raise EArgumentException.Create(..); // your stuff here... end;

Cleaning the global library path from unwanted entries creeping in when installing a library with its own setup is a continuing task here. In my installations the global library path contains only what the Delphi installer writes to it. Every additional library path is added to the search path of the project that makes use of it. Option sets for each library not only simplifies this, but also give a visual clue in the project manager which libraries are used for the project. Also these paths are somehow included in the repository of this project. This way I can fire up a new build agent for Continua, install Delphi, FinalBuilder and whatever tools are needed - that's it. All my projects can be compiled on this machine. Gone are the days where hunting for missing libraries detected late in the build process - often when you are already in a hurry.

It's not an effective way to learn. A really good book is what you need. In my opinion.

No. The caller has to tell the callee what to do. The callee needs to get the information from somewhere. I wonder, do you have any good books on software design? I really don't think this sort of question has proved fruitful.

How do you manage upgrading libraries. Once you upgrade for one project, you have to upgrade for every project, that's the nature of global libraries. The "overhead" of installing packages is really quite small, and you can do it incrementally. DPM does not use the library path, but that doesn't mean you still cant. FWIW, one of my reasons for working on dpm is probably somewhat selfish, but 90% of the problems FinalBuilder customers have with compiling delphi projects are related to the library path. I'm hoping that dpm will provide a standard way to work with libraries, so the whole issue of compiles on one machine, not on the other becomes a thing of the past (I can spend my time working on other things!). There are other benefit to not using the library path is the compiler doesn't have to trawl through every installed library even when the project doesn't use them, which makes for slower compile times. It's early days, there's still a lot to do on the project, including IDE integration, which will make working with it a lot simpler. Stay tuned.

I prefer individually named methods instead of overloads. Optional parameters can work in some cases, but when things get really complex with a lot of variations, I use variations on the theme that @Der schöne Günther introduced. A record, an object, or an anonymous method.

Greetings! Gnostice is pleased to announce the release of Gnostice Document Studio Delphi v19.2. In v19.2, we have added support for RAD Studio 10.3 Rio Release 3, introduced new DocumentConverter component for FMX, redesigned VCL DocumentConverter component, added support for Android 64-bit and OSX 64-bit targets, introduced several new functions on the Framework class to ease getting file dialog filter strings, supported formats, etc. For the full list of improvements, please log on to the History page. To download trial versions and EXE demos, please go to the Downloads page. To purchase royalty-free licenses of Gnostice Document Studio Delphi, please go to the Buy Now page. Please mail us on support@gnostice.com if you have any questions on the products. Happy coding! -- The Gnostice Team www.gnostice.com

There are two API levels in manifest (actually, there is another one, but not important) - minSdkVersion and targetSdkVesrion minSdkVersion marks minimum API required by application and it will not run on Android devices with API lower than specified targetSdkVersion marks highest supported API level by application - that means Android will not use any compatibility mode when running on devices with specified or lower API. If you run application on device with higher API level, OS will use compatibility mode for newly introduced API features. Tokyo 10.2.3 (and previous versions) by default had both API levels set to 14. Rio 10.3 changed that and minimum API level is now 19 and target is 26. That means devices with Android version lover that 19 will no longer be able to run applications built with Rio. Conclusion: Delphi application compiled with Rio can by default run on any device with API 19 or higher.