Leaderboard

https://larsfosdal.blog/2019/08/06/generic-command-line-parser-for-delphi-10-3-x/ I wrote an open source command line parser for Delphi. https://gist.github.com/LarsFosdal/f8a3e2a7caa5e541e4c04f10dfdfcfff Feedback appreciated.

I usually test for pre and postconditions like this: procedure TBlobDB.CreateNewDatabase(aDBStream, aIndexStream: TStream; aTakeStreamOwnership: boolean); const Procname = 'TBlobDB.CreateNewDatabase'; begin if not Assigned(aDBStream) then raise EParameterCannotBeNil.Create(Procname,'aDBStream'); if not Assigned(aIndexStream) then raise EParameterCannotBeNil.Create(Procname,'aIndexStream'); This is for errors that are supposed to be found and fixed during the testing phase or (for library code) in unit tests. For user input the input is validated before it is used by the program, if this is at all feasable. The end user should never see an exception coming from parameter validation at a lower level, in my opinion, since the UI context may not be evident at that point and it may be unclear to the user what he did wrong.

10.3.2 defaults for this are fairly unreadable (see attachment)... does anybody know if can I change this anywhere? Thanks Richard

Run Android Tools and select following packages to install: 1. [x] Android SDK Platform-Tools 2. [x] Android SDK Build-tools 28.0.2 3. Android 8.0.0 (API 26) [x] SDK Platform

Hi, https://docs.unity3d.com/560/Documentation/Manual/android-sdksetup.html or install Android studio ... then edit path's regards, mm

Any approach like this in Delphi would be impossible or suck (because it would need to be stringly typed) because Delphi does not have lambda expressions and generic extension methods.

To get a sophisticated answer you need to actually describe your situation properly and not just say "invalid values" - invalid in what context? Restricting UI from entering any invalid values can go from controls that don't even allow it, show a marker that their value is wrong, not allowing clicking ok/next to showing an "following fields have invalid values..." dialog. Declaring guard clauses in code for functions and methods that restrict passing any invalid input is a different thing and in that case I would always go with exceptions of a certain kind (EInvalidArgument or similar) either handwritten or by using some guard clause helper. If the programming language allows I would push this further by restricting the parameter types to only allow what is valid and for instance use decicated domain types instead of for example type string for an IP address but a dedicated TIPAddress type.

Yeah, I've suffered through using that sucker a few times. I think it's more work than I want to put in. Any other ideas?

I rember something about old Delphi versions acting up when you've done some of the most recent windows updates. If I recall correctly, you need to delete a key "LM" under HKEY_CURRENT_USER\Software\Borland\Delphi\6.0 and then start Delphi to re-create that value with the right data.

It does. The reason it's not supported is because Delphi Interfaces are COM based which restricts this. A generic type parameter on a method is just that: a parameter - but resolved at compiletime to provide type safety. You probably have never used any language where interfaces easily support methods with generic type parameters - otherwise you would not have this opinion. FWIW this is one of the reasons I so strongly wish for interface helpers because then it would be possible to add such methods via helper - the COM based interface itself is not affected but you can easily augment them with such methods. In 2014 I wrote some code that shows how such interface helper methods could be invoked similar to record helpers: https://pastebin.com/acp2i645