Stefan Glienke

Yep, that's the new virtual method that got added in 10.4.1 which is causing AVs and stuff in plugins compiled with 10.4.0 when you have some form in it inheriting from TDesktopForm or TDockableForm because then the VTables don't match.

(not enough information to give an informed suggestion) - anyhow that was not the question of this topic - as a mod/admin you should not contribute to totally derailing threads 😉

That would very much depend on the criteria by whom they are looked up, if that criteria changes and how often elements are added/removed don't you think?

Reported: https://quality.embarcadero.com/browse/RSP-30890

The offset in the code is correct but the binary layout of the classes are not - here is the dump of the memory layout from the defect: --- TPdfObject --- offset: 4 size: 1 FObjectType: TPdfObjectType offset: 5 size: 4 FObjectNumber: Integer offset: 9 size: 4 FGenerationNumber: Integer offset: 13 size: 1 FSaveAtTheEnd: Boolean --- TPdfStream --- offset: 14 size: 2 ---PADDING--- offset: 16 size: 4 FAttributes: TPdfDictionary offset: 20 size: 4 FSecondaryAttributes: TPdfDictionary offset: 24 size: 1 FDoNotEncrypt: Boolean offset: 25 size: 4 FFilter: AnsiString offset: 29 size: 4 FWriter: TPdfWrite --- TPdfObjectStream --- offset: 31 size: 4 fObjectCount: Integer offset: 35 size: 4 fAddingStream: TPdfWrite offset: 39 size: 4 fObject: :TPdfObjectStream.:2 offset: 43 size: 1 ---PADDING--- size: 48 So the [ebx+$1d] is correct ($1d = 29) - but the starting offset in TPdfObjectStream is wrong. With align Word it looks like this: --- TPdfObject --- offset: 4 size: 1 FObjectType: TPdfObjectType offset: 5 size: 1 ---PADDING--- offset: 6 size: 4 FObjectNumber: Integer offset: 10 size: 4 FGenerationNumber: Integer offset: 14 size: 1 FSaveAtTheEnd: Boolean --- TPdfStream --- offset: 15 size: 1 ---PADDING--- offset: 16 size: 4 FAttributes: TPdfDictionary offset: 20 size: 4 FSecondaryAttributes: TPdfDictionary offset: 24 size: 1 FDoNotEncrypt: Boolean offset: 25 size: 1 ---PADDING--- offset: 26 size: 4 FFilter: AnsiString offset: 30 size: 4 FWriter: TPdfWrite --- TPdfObjectStream --- offset: 34 size: 4 fObjectCount: Integer offset: 38 size: 4 fAddingStream: TPdfWrite offset: 42 size: 4 fObject: :TPdfObjectStream.:2 offset: 46 size: 2 ---PADDING--- size: 52

I would use the Exit version and put the appending new record into its own method.

procedure TestAddRowData(); begin lValues := [ ['one', 1, '1one'], ['two', 2, '2two'], ['three', 3, '3three'] ]; // or SetLength(lValues, 3, 3); lValues[0,0] := 'one'; lValues[0,1] := 1; lValues[0,2] := '1one'; lValues[1,0] := 'two'; lValues[1,1] := 2; lValues[1,2] := '2two'; lValues[2,0] := 'three'; lValues[2,1] := 3; lValues[2,2] := '3three'; end;

How to use open array parameters to handle array subranges: https://delphisorcery.blogspot.com/2020/09/open-array-parameters-and-subranges.html

Ugh, nasty sh*t - can repro in earlier versions than 10.4 as well. The compiler trips over the type inference - need to write MergeSort<T>(...) I would guess it spirals down into some endless loop trying to infer whatever comes back from that tricked Slice call. Updated the blog post - thanks

https://bitbucket.org/shadow_cs/delphi-leakcheck/src/master/ scroll down to "DUnitX integration"

It's just in the comments but anyhow - from line 66 onwards the version is wrong (both 2007 versions were 11, 2009 was 12, 13 was skipped and so on, 10.4 is 27 - hence the 270 suffix on the packages) See: https://delphi.fandom.com/wiki/Delphi_Release_Dates

Then you just did not get the issue yet. I am always compiling GExperts myself and I have seen this glitch with 10.4.1. No steps to repro yet though

Here is the explanation: http://jedqc.blogspot.com/2006/02/d2006-what-on-earth-are-these-explicit.html

When David wrote "Andy" he was referring to "Andreas Hausladen"

if GetTypeKind(T) = tkClass then PObject(@item)^.Free; RTL still uses DisposeOf (which you also need to if you want to support ARC before 10.4) - look into TObjectList<T>.Notify

Defect is somewhere else and you messed up the string reference counting, if the error occurs on not the first call to Peek then obviously Result contains a prior string reference which the UStrAsg call that is generated for the assignment clears. Did you fix procedure Add(Items:TRingbufferArray); already? Because that must not use Move for managed types

I just released a new version of TestInsight - more details on my blog post.

StartSuite/EndSuite might be used by the GUI listerner to build its hierarchy, I don't know but its not at all required - some sort of names containing their entire path information would be needed to - but I said before - not planned. Regardless we are discussing the wrong issue here - you most likely have multiple instances of the same testcase classes here and thus multiple tests return the same name - I suspect that you have more than 350 tests you showed in the screenshot before. Its as simple as that if I name a file just by its file name I most likely find similar named units in several folders - when I add some information that is unique for each of them - like the directory I can identify them. As I said before if the decorator would not just pass GetName onto its decoratee then the name would be unique. TI is build to be test framework agnostic - and I try to keep it that way and not implement any quirk or unique feature into it - there was enough trouble already with some places where DUnit and DUnitX behaved different in terms of how they named and identified their tests already. Having that said - I am very sure that even without implementing hierarchical display you can be able to use TI for your tests and be able to find out which of the similar named but using different setup tests failed. Edit: I quickly looked into it and I have to say the design with the decorators and the way they are implemented in TestExtensions.pas is a bit crappy but anyhow: We need the BeginTest/EndTest methods here as those are the ones being run for the decorator instances - we use IsDecorator to check is its one and then add/remove from a current path variable. I remember you asking me about running tests in parallel, so make that a thread var - not sure if running tests in parallel makes sure that only tests from different suites are run in parallel because otherwise DUnit itself might be in trouble... anyway - append that as well in GetFullQualifiedName - anyhow you might want to change the TTestDecorator.GetName to use its name and not just generate a generic name that does not tell much. Example: type TMyDecorator = class(TTestDecorator) function GetName: string; override; end; { TMyDecorator } function TMyDecorator.GetName: string; begin Result := FTestName; end; initialization RegisterTest(TMyDecorator.Create(TMyDecorator.Create(TMyTestCase.Suite, 'foo'), 'qux')); RegisterTest(TMyDecorator.Create(TMyTestCase.Suite, 'bar')); end. And these changes in TestInsight.DUnit: +threadvar + currentPath: string; function GetFullQualifiedName(const test: ITest): string; begin * Result := currentPath + (test as TObject).ClassName + '.' + test.Name; end; procedure TTestInsightListener.EndTest(test: ITest); begin + if IsDecorator(test) then + currentPath := Copy(fCurrentPath, 1, Length(fCurrentPath) - Length(test.Name) - 1); end; procedure TTestInsightListener.StartTest(test: ITest); var testResult: TTestInsightResult; begin + if IsDecorator(test) then + currentPath := fCurrentPath + test.Name + '.'; And I get this result

They might not run at all because of new procedure entry points that were not there before - see the comment from a user on my blog article trying TI 1.1.9.0 on 10.4.0.

- Warnings are because TI enables the FailsIfNoChecksExecuted option all the time (see TestInsight.DUnit.RunRegisteredTest) - and then turns failures with the message 'No checks executed in TestCase' into a warning. This happens when you don't execute any CheckXXX in your test. Yes sometimes such tests exist - put a FChecksCalled := True into the code or create a class helper for TTestCase with a Pass method (which I did) or inherit from your own improved TTestCase class (which is also what I did in the past). - I have to say all this back and forth showing screenshots and stuff is very tedious and time wasting for us both to find out a solution. Especially since without the exact code I cannot see which results belong to which setup code - hence my question to create some tiny two or three testcases example that demonstrates the issue that I can look into - my guess so far (and I hate guessing with little information) is that due to the approach with decorators there is some information lost that would be needed for a unique name. IIRC in DUnit a decorator inherits from ITest and thus is able to change what is returned from the GetName method - I would guess this is what is needed here to produce a unique name.

Changing icons is not good style - I could have two buttons but then again people would not read hints. Thanks for your offer but I have the Arxialis icon set and take one from their icons if I need another. Thing is internally it is exactly identical function - "run selected tests" - which basically means "run the test app and skip any test that is not selected" - well if there is no test to select that means "run the test app and skip all" - which results in all tests being discovered. If something can be explained by "click this button to discover tests" I would rather spend my time elsewhere more important - possibly by writing some quick guide that explains everything on one or two pages and leaves no room for confusion - then I could at least reply with RTFM when someone asks me 😛

Ok, then probably some incompatibility - please report if it ever occurs again with 1.1.9.0 If the fact that with some bad code in a plugin you can completely bring down the IDE is a "problem of the IDE" then I would say it is very likely. I think this has discussed before - especially as some plugins do quite some nasty things which can offer amazing functionality but are very very brittle - and in fact causes quite some work on the IDE devs as they cannot simply refactor or even rename stuff internally as they would like to.

Please show how these tests show in TI grouped by type.

That was in 1.1.8.0 right? I just noticed it this morning on my 10.4.1 at home that still had an earlier TI build installed and I got some AV every time I opened a new VCL application. Installing 1.1.9.0 removed it but I cannot recall any particular change that i conciously did for that defect - was it reported on the issue tracker?

I see - if you can pass me some simple demo of how you structure your tests and where it leads to problems identifying which test result belongs to which tests it would help me understanding and possibly finding a solution - you can see the client sources that are shipped what information TI gathers from each test and if it possible is missing some information apart from the position in the hierarchy.