Vincent Parrett

The freeandnil call was on a TStringList, which was owned/instantiated by an interfaced object.

Zero, I know it's not thread safe. It wasn't just freeandnil that solved the issue (if only). Just another tool in the box, which I used then removed. I still don't get why people get upset about FreeAndNil - I have much bigger and more important issues with delphi to deal with (like actual bugs in the ide/compiler/rtl/vcl) rather than worry about something so minor.

I did use that, and it got me closer, but not close enough.

I saw that, but I'm not using the built in Weak stuff - this is in XE7 Win32 before weak was available - I'm using my own weak reference library - it's not as convenient (need to use a base class) but has worked well for me for the last 12 years or so. I still take a hard reference from the weak and check that for nil rather than relying on the .IsAlive property when using it in threads.

I recently spent an entire week trying to fix a bug where in heavily threaded situations customers were seeing random av's. The av's and the stack traces were very random, which made it very difficult to pin down. Debugging threads in delphi is painful at best - any changes to timing can completely mask bugs so using breakpoints was not going to work (and the bug would occur in around 4 out of 40 identical threads). After spending days adding even more (pointless as it turned out) locks all over the show I wasnt' much closer to figuring it out. I suspected it could be a reference counting issue (since I use interfaces a lot), so started sprinkling some FreeAndNils around the code (in destructors) - suddenly those random av's turned into nil pointer exceptions that were much less random. That confirmed to me that the issue was with accessing objects already free'd. The problem turned out to be that I was using weak references where I really needed strong references - a 70hr week of frustration turned into a 4 line change 🤦‍♂️ I really don't understand all the angst and debate about FreeAndNil - use it where it makes sense, or don't - just like any other RTL function or language feature.

Agreed, however you don't have to answer all of those.. most have a prefer not to say option. I really don't know why they need to ask about my sexuality etc 🙄

Ah the drop bears, those are reserved for hot Swedish tourists -

🤣 it is true there are lots of animals that could kill/injure you , giant spiders eating cows - not so much redback spiders - quite common, but once you know about them not much of an issue - just don't put your hands in places where you can't see without gloves on. kangaroos - very common, see them all the time while out walking - just give them a wide berth and they will just stare at you or hop away - the most common dangerous encounters are when they jump out in front of your car at the last second.. had several of those, as has my wife, daughter, son and brother (in my car!). Insurance is expensive here. Snakes (a few of the most venomous in the world) - common in the bush and in some parts of the country they are everywhere - I've not had any close encounters, but I'm always wary when bush walking. Salt water crocidiles - they live up north - avoid rivers and the sea past certain lattitudes (I live down south so not an issue). Fresh water crocidiles - mostly in the north/north west - they rarely attack people but can do some serious damage, so best avoided. Irukandji jellyfish - mostly in the tropics - don't swim in the sea There are others but in all of the above fatal encountes with them are easily surpassed by vehicle accidents, heart disease, diabetes etc.

I've had zero success recruiting delphi developers in the last few years - devs here in Australia do not want to work with delphi. I have found most devs also only apply for jobs that state the toolset they will be using (or they ask when applying) - advertising a job that doesn't mention that doesn't generally help. I tried doing that once and had people walk out of interviews when I told them we use Delphi - sadly most said they had never heard of it plus the odd "oh is that still around" . Younger devs want to work with what ever is the current flavour of the month (js react, go, rust etc) and I can't really blame them for that. Unfortunatly delphi suffers from many issues which are a turn off for employers and prospective employees. Poor quality - this has been an issue for a very long time (since the Inprise era). Each release improves a little, but then bring new issues, and many issues remain unresolved for years. Lack of language evolution - the language has barely changed - where other languages like C# etc have - yes there has been some tinkering around the edges, but apart from generics not much really. Lack of investment - in the early days Delphi sold like hotcakes - but that income was syphoned off to other "enterprise" products that never went anyway (Inprise era). I don't see any evidence of that ever recovering. Imho the poor quality is what has really turned many people away. TBH I would be embarrassed training a new dev on Delphi, having to explain all the work arounds etc that I use almost without thinking (like restarting the IDE many times each day), it would be just too time consuming and frustrating. Some days the frustration levels have me looking for career change! So is it any wonder that delphi jobs are few and far between. Here in Australia I see one or two a year advertised - and then those usually worded to suggest the job involves migrating their projects to other languages like C#.

Sorry I didn't see this thread back when it was originally posted. I have never used the JCL stack trace provide - and github seems to have lost the history for the file since I re-orged the repo layout - so not sure who contributed it (was a long time ago). I have used the madExcept one in the past, but generally only rare occasions when a test fails on the CI server but not on my machine. You do appear to have performed the correct steps to enable it. The stack trace is currently only reported in the NUnit and JUnit loggers. The feature isn't implemented - the value is hard coded in the output - probably to satisfy a parser somewhere. While DUnitX does count the asserts per test, it doesn't currently have a way of reporting the total number of asserts. If you are still needing this it would be worth logging an issue on github so it doesn't get forgotten.

It looks like this was never implemented. I have never used the gui test runner - I prefer TestInsight - but it should be relatively simple to implement - a quick look suggests it could be added in TGUIVCLTestRunner.ProcessMessagesForNode - follow the pattern use for messages. Happy to accept a PR for this 😉

Ok, I was using the document class to parse - didn't realise I could use the node class directly.

^ This. I looked at using the parser in a console application but the requirement for a canvas etc brings in the vcl makes it a non starter (can't use the vcl at all under docker). I've had this issue with several well known third party libraries - the lack of layering and tight coupling with the vcl in libraries really reduces their possible uses.

This ^, you shouldn't modify TDUnitXNullLogger - just create new logger (implements ITestLogger). Most of the methods would be no-ops (like the null logger).

🤣 Well that me actually laughing out loud after a day from hell, thanks 😂