Leaderboard

I use them sometimes as a convenient way not to pass too many parameters. As far as I remember this comes with a performance penalty though. I declare those shared variables at the top of the main procedure, above the nested procedures, and those that are not shared below the nested procedures.

This should be updated with link to new quality portal https://qp.embarcadero.com/

You have likely lost sight of my original comment, which was simply that it would not surprise me if the guy who wrote this component is hoping to have it acquired. I am not and will not argue that they would or should. It is plainly obvious that they have done things just like this in the past, is what I am saying. And since he's already sold stuff to Emba that is now part of Delphi, and he's not making much of an effort to make this a long term viable product by itself (you pointed out the lifetime license)... It's all speculation, of course. Again, they have done this many times. Some of the basic functionality we now have in the IDE came from Castalia. The entire FMX framework was originally acquired from the guy who wrote SmartCrashLog. They recently acquired Parnassus tools filling gaps in their IDE functionality. They pulled in Skia code they didn't write. It's not far-fetched to posit they could acquire more functionality they don't want to make for themselves especially to fill such a wide, gaping, black hole like this. Should they do it that way, in this instance? I don't know. I didn't say they should.

The other problem I have in testing the trial version is that I can't use it in projects that have bug fixes to RTL/VCL/FMX source files, because the source is not available to recompile against the ones I am using. I don't blame him for not including source in the trial version, but the order page does not say whether or not you get source. In fact he doesn't even show what the license is. I've emailed him for clarification on these issues, and also asked about the bugs with the current trial version (no line numbers or function names), but haven't heard back. I looked into how SmartCrashLog installs and works, which you have to puzzle out yourself since there is literally no documentation (just silent youtube videos showing someone making a prokect). It looks like every time you build a Release version of your project, it stashes a copy of the EXE into a data folder and adds it to a local SVN repository. This is how he's able to manage getting crash logs from any released version and match it up. That's an interesting idea, but I also need this to work on my own debug builds that I am deploying to other machines on my network, and he explicitly blocks using this in a debug build, probably to avoid filling up the SVN repo. It would be good if I could at least maintain the most recent debug build in there so I can use this in my own iterative debugging. This seems like a promising project but in the end I would be satisfied with a simple call stack with line numbers that is copied to the clipboard when an exception is encountered.

While I at times use local routines I avoid accessing outer scope local variables like the plaque because it usually generates quite a huge and often unnecessary stack frame.

Indeed, but they still reside in the interface section and thus may need some units being used in the interface section instead of the implementation section.

It generates a code that you can call but cannot change. If you change it will be rewritten the first time when the new code is generated. Note. I find the generated code unreadable and can kill the Delphi IDE with stack overflow.

Sometimes a logging can help. Log the start and finish of every action you take when the menu is executed (starting loading this / finished, starting that / finished). The part that does not have the finished event in the log is caused the hang.

Hi, I've solved my problem by changing a line in my TDataWedgeBroadcastListener.Create: TAndroidHelper.Context.registerReceiver(FReceiver, LIntentFilter,2); instead of TAndroidHelper.Context.registerReceiver(FReceiver, LIntentFilter); the value "2" corresponds to the Andoid flag RECEIVER_EXPORTED. Thanks for the help

IMHO, having local procedures/functions using outer-scope local variables is often a hint for having a separate class for this functionality. I wish we were able to declare something like a local class type inside a method, just as we can declare a simple record type. In the moment I work around that limitation by nested classes unless I want it hidden from the interface, which forces me to make it a regular private class.

Spring4d has an optimized version for XXH32 that is being used for the hashtables (dictionary and co) - see https://bitbucket.org/sglienke/spring4d/src/2dbce92195d699d51fc99dd226c4698748ec8ef9/Source/Base/Spring.Hash.pas#lines-46 Since all other versions in that family have a larger width and the hashcode in hashtables is typically 32bit (larger would only be worth once you have more than 2^30 items in it) I did not bother to implement the others as well (also XXH3 is a bit more complicated, XXH32 is quite simple actually) Also since the architecture of Spring4d 2.0 is pluggable you can replace it with your own hash function if anyone wants to come up with a faster one (I tried for example one from mormot2) - see https://bitbucket.org/sglienke/spring4d/src/2dbce92195d699d51fc99dd226c4698748ec8ef9/Source/Base/Spring.Comparers.pas#lines-87 Keep in mind though that the usecase in Spring4d is for hashtables - which means these hash functions typically don't hash gigabytes of data as in other use cases. Nevertheless, the faster the better. As for a Delphi wrapper for the original C++ implementation -see https://github.com/YWtheGod/XXHASH4Delphi

Practical - as in practical for the users of their products, i.e. us.

Not a fan of nested procedures/functions - but if I do use them I prefer to pass parameters - I prefer the narrowest scope possible on all variables/fields etc.

I sometimes use these where a method has been broken into sub-routines to create more readable code, but more often than not, I tend to pass arguments to these sub-routines as parameters.

You might like to read this: https://developer.android.com/develop/background-work/background-tasks/broadcasts#context-registered-receivers ..and remember that I asked about what your code is doing. Presumably, part of it is registering a receiver at runtime, and it is not including RECEIVER_EXPORTED or RECEIVER_NOT_EXPORTED in the flags when calling registerReceiver.

Not sure why you would expect anyone to know without any detail whatsoever as to what your code is doing. You could use a logcat viewer to view what messages are coming from the device when the app attempts to start. See this link: https://github.com/DelphiWorlds/HowTo/tree/main/Solutions/LogViewers#android