Stefan Glienke

This is like asking "I made a printout of that document last year why didn't it update when some people changed the pdf" 😉 A git clone does not update itself - think of it as snapshot - you as the clone owner are responsible to keep it up to date. I think there is no point in making a clone(*) anyway unless: - you are afraid of the repo owner just deleting it (and even then the nature of git would allow everyone who has a local clone just to push it back to a new home) - you want to maintain your own modifications (either for keeping them for yourself or contributing back) (*) sorry, when I wrote clone I actually meant fork - I was assuming that you always keep a local clone up to date or at least fetch it regularly (most git ui tools do that automatically anyway) to see whats new on the origin

I still don't see a way to repro this behavior on the Delphi side because both RSP entries that are referenced in the patch are C++ ones. So chance is high Andreas won't be able to repro and fix either.

Then submit a pull request with the necessary changes to get rid of the hints. P.S. Btw proper use of git will not overwrite your local changes fwiw

How can a name collision between TTMSLoggerLogLevel.Exception and Sytem.SysUtils.Exceptions be an IDEFixPack issue? It has even been reported already: https://www.tmssoftware.com/site/forum/forum_posts.asp?TID=8402&title=enumeration-names

Looks pretty much like -O0 assembly

Well then the issue is not only about that one but also about other toolbars because if you look carefully the rightmost button in the debug toolbar also has a different icon. What happens if you go into Customize and click Reset for those toolbars?

I am pretty sure it's a different layout that gets loaded and that it in fact is not the "View/Ansicht" toolbar you are pointing at in the bottom screenshot. Simply right click and check if its checked/visible

Use Rust if you want that :)

Not true - this ain't .NET or Java that raise an NPE as soon as you reference any member - it can very well call non virtual methods and then eventually raise some AV which you then need to decipher (everyone knows what an access violation at 0x0071f2a7: read of address 0x000000f7 means, right?)

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.

Learning about one of the most powerful and free controls the VCL has to offer - yeah what a waste of time 😜

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.

Virtual TreeView

Ok, if we are talking other languages: best is to not be even able to compile the code or get warnings when the static code analysis cannot make sure that these conditions are met - for example using non nullable reference types.

I disagree but I am not going into yet another discussion about this.

I see this many times I put a breakpoint into a line with an inline variable declaration - it looks like some debug symbol issue so the breakpoint is not set into the proper instructions but into the prologue code the inline declaration brings with it. This can be very annoying and confusing indeed.

They should just make typed const true consts by dropping that writeableconst - or for the sake of backwards compatibility introduce a new switch $TYPEDCONST that when enabled turns even typed consts into true consts that even if you try $J+ won't be writable.

If you in fact read carefully what I wrote in my first post in this thread you would have noticed that I was merely referring to using attributes for passing test data to unit tests (which probably your made up TestAttribute made me believe you were trying to) and which the snippet showed that I posted - you never mentioned that in fact you are trying something different with your approach. And in this context you just showed it even does not look like a good idea because apart from not working it would even create 2 indirections - you would need to declare all the const records somewhere and then pass those to your attributes. If all the data being passed to attributes gets so complex that you feel the need to make compound types from them then I would rather consider writing an Init method where I do all this - compiled code, no attribute/rtti overhead, easily testable, done. Or if you don't like writing code - then make a custom component editor for your TGridSet class that you can then edit in the designer - add verification logic and so on.

Of course it does not - because it's not regularly invoked but executed via RTTI taking its arguments from at compiletime specified memory - see System.Rtti.ConstructAttributes I would agree if it would reference production code method names that might be subject to refactoring without knowing that some test code references to them but in this case the referenced method is part of the test code and you don't usually rename those and even when they are very close to each other so its more unlikely to miss the reference. Anyway feel free to ignore the obvious and already proven to work fine solution and look for an impossible one :)

Judging from the performance of the mobile compilers over the years I would say: no

I just noticed that the default shortcut for "View->Debug Windows->CPU Windows->Entire CPU" did not work since I installed MMX. After first missing the key bindings directly in the "Key bindings" node (I only looked in the 2 sub nodes) I found its assigned for "Copy Entity" Now sure I could just reassign to something else and then when the next shortcut conflict happens I do that again and so on. Or the plugin itself could actually check if it overrides or conflicts with any other shortcuts (well between 3rd party plugins it would be nice but mostly I hate when plugins override default shortcuts from the IDE - GExperts also does that, grrrr!) The best solution in this particular case would even be to be contextual (I guess that might be complicated but I thought I just mention it) as during debugging it would make more sense to show the CPU view but when not debugging that does not do anything and when in the editor I might want to copy the entity.

Passing a token to the task that can be checked and raise a special "task cancelled" exception when that is the case which gets cought in the task executing layer. Of course write your code executed in a task so that it can be cancelled via exception

15 beta - and shortcut can also have changed years ago. I would expect it to respect those of an already existing installation/config rather than changing them. So the change would only happen for a new install.

For me it was. As far as I can see GExperts just lists actions with a shortcut - not all shortcuts that you can register via OTA. For example most prominently it does not list Ctrl+#. If you are using Documentation Insight - that one also assigns Ctrl+Alt+C but is not listed by GExperts.

Reading the documentation is underrated these days, eh? http://docwiki.embarcadero.com/RADStudio/Rio/en/Declared_Constants#Typed_Constants To solve this particular case of providing structured data to unit tests via attributes I am referring to an approach where you specify where to get the data from in the test attribute and write the code that then does not have to be const in methods that are accessible via RTTI. Here an example how to use this with the Spring.Testing extensions for DUnit: https://bitbucket.org/snippets/sglienke/pe7xAK/dunit-with-external-test-data The approach itself is borrowed from NUnit - see https://github.com/nunit/docs/wiki/TestCaseData