Leaderboard

A new powerful highlighter called Omni (for omnipotent) has been added to SynEdit. Importantly, this highlighter allows the saving/loading of highlighter settings to/from ini files. The project now includes 189 new ini-based highlighters in addition to the 75 ones that were already included. Sample using the PowerShell ini-based highlighter. Notice that code-folding is automatically supported. Structure highlighting is also supported: A component editor has also been added that can be used at both design and run-time. See this discussion for details. This is based on a significant code contribution by Jan Fiala, the author of PSPad. Kudos to Jan!

Sorry, I'm a little late to seeing this... I see it the other way - it can INCREASE the likelihood of an AV (or worse!). The callback's Self pointer will be pointing at memory which the now-dead TMyClass object was occupying. It's undefined behavior for the callback to access that memory for ANY reason, period. But let's forget that for a moment. You nil the FMyVar member when freeing the TMyClass object, with the expectation that you can still access FMyVar later (which you can't). If the memory that FMyVar was occupying gets reused and overwritten before the callback is invoked, that memory might not be zeroed out anymore from the earlier nil. And if it is not, then Assigned(FMyVar) will return True instead of False (if it doesn't just crash outright), and then you will try to call FMyVar.Add(...) and crash... or worse corrupt random memory trying to write to memory that it doesn't own.

procedure TMyClass.StartAsyncTask; var LCancellationToken: ... begin // capture this local variable instead of field in anoanymous methods LCancellationToken := FCancelaltionToken; ... TThread.Synchronize(nil, procedure begin if LCancellationToken.Cancelled then Exit; // Callback-Code Writeln('Task finished gracefully.'); end); @Rollo62 Use the above approach to avoid capturing Self. You also need to check once again whether task was canceled when you synchronize, before you touch anything from TMyClass. also this will only work if the code that runs within the task does not touch anything from the class. If you can't avoid that you need to store task in field and wait for its completion before you destroy object.

Doesn't that strategy cost you a lot more than allowing the actual bug to surface so that it is easier to fix? I much prefer bugs that hit me with a hammer frequently than ones that only do so rarely and in production... As to the original question, others have already said that there isn't necessarily a right answer here. When I am working in code I have full control over, I use FreeAndNil ONLY WHEN I NEED TO. In my opinion, there is no legitimate use for FreeAndNil outside of using it to nil a variable that is not going out of scope after it is freed. If the variable is going out of scope and not being used again after the free call, then nilling it is pointless and confusing, because the intent is unclear. There certainly are many legitimate reasons to nil a reference, such as for lazy-loaded objects that may be reinitialized after being freed. The most often used excuse to call freeandnil is to supposedly surface bugs sooner, but this is a wash at best. It obfuscates your code to use FreeAndNil for this purpose. It is not a debugging tool. And you can still successfully run class code on a nilled reference! The only time it will AV is if that code tries to access instance memory. So you end up with a false sense of security, using a function for a purpose that it isn't designed, and anyone else looking at the code has to wonder why you are nilling something that is going out of scope.

Kudos to @Kas Ob. 🎖️

Many thanks to all who helped - learning about the sysintern functions (handle.exe was the life saver) etc much appreciated. Special thanks to @Kas Ob. @Remy Lebeau @Der schöne Günther @Lajos Juhász

POSITIVE RESULT Having got the error code 1450 and then, very helpfully, being pointed in the direction of the "handle.exe" utility on sysintern this got us to a much better position: we could run our software and use "handle" to confirm that something was generating this continuous stream of unwanted (and presumably unused) handles which was eventually reaching some kind of windows out of resources threshold. This enabled us to (temporarily) remove parts of our code that talk to different bits of hardware and then repeat the test to check for unwanted handle production. We found that it was calls to a commercial driver for a specialist PCIe card that is used by our system that was the cause of the problem. This comes from a large respected scientific corporation, who's products we have worked with for a good many years (previously without any problems). Even better news: As part of this commercial package comes a separate test utility that allows you to check that card and driver have been installed correctly. This, too, gives the same stream of unwanted handles. So we are now able to go back to designer/manufacturer of the card/driver and show them how to spot the problem, which exists just using their own software. Fingers crossed that they will come back with a fix quickly!

Issue submitted: https://embt.atlassian.net/servicedesk/customer/portal/1/RSS-2959

This doesn't guard against anything. if DoOnCallback() is called after the TMyClass object has been freed then all bets are off. The callback's Self pointer will still be pointing at the memory of the freed object, but that memory MAY OR MAY NOT have been overwritten by the time the callback is executed. You are assuming it has NOT been overwritten yet, but you can't make that assumption. You really should cancel the async operation before/when freeing the TMyClass object, so the callback is not called at all. But, if that is not an option, then a safer option is to keep track of the dead object pointer somewhere and have the callback check if its Self pointer is being tracked as dead before accessing any members.

If the callback runs in the background thread then FreeAndNil will not make the difference. In other words, your guard is not guarding anything. The FMyVar could be released after callback passes the Assigned check. You would need a different mechanism to protect your variable and make sure it is still alive while callback runs. The whole idea that your object which is still used while there may be pending async code running is a serious design flaw. I am not sure how easy would be to fix that code (I expect it is more complex in real life scenario), but you have a problem here. There are different mechanisms that can protect your instance, but which one is the most suitable will depend on other code and context that you haven't mentioned here. You can find some ideas at https://github.com/dalijap/nx-horizon look at how TCountdownEvent is used. another one is in https://github.com/dalijap/code-delphi-async/tree/master/Part6/35.2 GUI Cleanup but that one will work only if the TMyClass instance belongs to main thread. Of course, those are not the only solutions, just something to get you started. I haven't mentioned the most obvious one (waiting for the background thread to finish, before you release TMyClass instance, but I guess that this is not an option here or you would probably use it already.

Excellent! Even though I don't want to ride the startup roller coaster, I do like seeing people launching new technology.

FreeAndNil is something that you will need to use rarely (it might depend on the kind of code you are writing). In places where your code needs it logically it will be obvious that you need it and everywhere else you can use Free. The point that FreeAndNil can help you avoid errors and mistakes is full of holes. First, simple access after Free is usually easy to catch either by looking at the code (local variables) or by using memory manager in debug mode or other specialized tools. Next, FreeAndNil nils only single reference to the object instance. If you have multiple ones you will still have to deal with dangling pointers and you will need to learn how to use previously mentioned tools. Most of the problems with memory management in Delphi are caused by having multiple references to single manually managed object instance as such code is more complex. This is exactly the place where FreeAndNil cannot help you, but where using it will give you false sense of security. Another reason against using it everywhere, is that it obscures the code intent. Logically, FreeAndNil means that variable will be reused and this is important information. If you use it everywhere, you will have mush harder time reading the code and understanding its intent. And code which is harder to understand is also harder to maintain in the long run. Of course, that can be solved with comments, but then you will have to use them everywhere or you will never know whether some comment is missing somewhere. Manual memory management requires some discipline. thinking about the code you are writing enforces the discipline and makes you a better programmer. Taking the "easy" path where you will slap FreeAndNill everywhere just so you can avoid accidental mistakes and thinking is going to cost you at some point. Many existing codebases where it is used everywhere cannot be easily migrated to not using it as it can be hard to determine where it is needed and where it is not (except for local variables) and they need to continue using it indefinitely in all places, as the only thing worse than using FreeAndNil everywhere is using it randomly. Consistence in code is the king. In my codebase I have less than 50 places where I am using FreeAndNil (I cannot tell the exact amount as I have many smaller projects and it is not easy searching through them as some contain fixed VCL code which uses FreeAndAil a lot, so I cannot easily count usage in my files only) One of the advantages of being a new Delphi developer is that you don't have a lot of existing code where FreeAndNil was used in places where it is not needed and now is the right time for you to decide whether you want to pollute your code with FreeAndNil and stick with it forever or not.

Use it ONLY when you NEED it. When freeing an object that is pointed at by a given pointer variable, and that variable may be used again later, then nil'ing that variable makes sense, as future code will be sensitive to what the variable is (or is not) pointing at. But, if the pointer variable is not going to be used after freeing the object, then there is simply no point is nil'ing the variable.

Wow. A Microsoft scanner being lenient on an app written by a Microsoft compiler, and harder on an app written by a competitor's compiler. Who would have thought... 😜 And we all know how well AI writes good code...

Well, it's an interesting concept because I created one in my formatter engine which is multi language and support mixed source documents among other cool features. - And it is high performance without using rust 🙃

While not aligned with the goals of this project, that's an interesting concept. Can't say I'm aware of any well-known formatting tools that operate in such a way, though.

What you want in a formatter is a simple DSL where you can express your desired formatting style and the formatter uses this as the basis.. I'm glad you asked...

A good question! At this point in time, we strive to not modify any tokens, for safety. We have tentative plans to implement keyword lowercasing in the future. For identifiers, we feel strongly that the identifier should match its declaration, however, this tool doesn't have any semantic information to be able to enforce this. Our other tools sonar-delphi in conjunction with delphilint are much better suited to that task.

I follow that except I also use camelCase for local variables. An opinionated formatter that doesn't allow me to configure to my taste is unfortunately not going to cut it. I also do weird things like align assigments in constructors constructor TMyClass.Create(x : integer; y : integer; const theName : string); begin Fx := x; Fy := y; FName := theName; end; and for constants const cMyConst = 'test'; cAnotherConst = 'foobar'; No formatter I have tried can cope with that.

Looks great - as always: spring4d source for the real test and it seems to stumble at a few places where it then goes into "line breaks go to 11" mode - here for example: or

As well as python's black.

It is a fair enough question. In the context of a code formatter, it means that it has a strong opinion on what the code should look like. Predominantly, this manifests in having few or no configuration options and a highly consistent style. Other formatters like prettier, biome, and google-java-format call themselves opinionated.

That comment didn't age well I guess

And incidentally, for whoever has not tried it, Delphilint from the same group, really rocks.

as you should know, each "enviroment" is distinct in many aspect!!! then, needs a particular approach for it! VCL and FireMonkey are distinct too! then, needs an particular approach too! before, the style was a "binary" file, now is a 'text".. you can open "*.style" file in your notepad and see for yourself! you'll see this line: for sure, internally, the "flag" will be used to special processing. if exists so much possibility, why put all in the same place? Is TImage in VCL the same as TImage in FMX? And why not? Are there any technical or design reasons?