measurement.WindowOverview.ListView.Entry is null about sanderling

[asdfasdf100500]

I'm more than willling to try and fix this according to your guide.

I work as a software engineer, but I have very little experience with Python memory management and memory reading in general.

[Statter]

[Viir]

I will add guidance about how to go about such an issue soon.
It will probably start with how to reproduce the issue in Visual Studio using a process sample from the eve online client.

Anyone who wants to work on this will need such a sample. See the guide at http://forum.botengine.de/t/collecting-samples-for-memory-reading-development/50 for how to collect such a sample.

[Statter]

I can confirm, that the Entry object is "null ". It has become that right after the latest update.
WindowInventory.[Long path].[AnyViewType].Entry is null
WindowOverview.[AnyViewType].Entry is null
I think, that all windows are affected.
They are null both in Parsed and not Parsed memory measurments.

[Viir]

@asdfasdf100500 Thanks for offering to help with this. Usually, adjustments to python reading code are not needed. Most of the time when something broke, CCP simply changed some symbols for types or type members in their code.

I added the memory reading code to the repository as well as guidance on how to reproduce the memory reading and inspect its results. See the guide at https://github.com/Arcitectus/Sanderling/blob/master/guide/Adapt-memory-reading.md

[Viir]

WindowOverview.ListView.Entry is null
Seems to affect other ListViews too

@asdfasdf100500, what about WindowOverview.ListView? Is this null too?
As far as I see, everything that could end up in the Entry property has to go through SictAuswertGbsListViewport<EntryT>.Berecne. If the ListView itself is found, we should take a closer look at that method and the intermediate results there.
Is there the Scroll in there found?

[Viir]

Ok, so in the screenshot of the API explorer @Statter posted I see that the Scroll property the instance of ListViewAndControl<EntryT> is not null.
Now there is not much more left in between computation of Scroll and Entry:

• Do we have instances for ScrollClipperContentAst?
• AFAIR, the number of items in ScrollClipperContentAst?.ListeChild should equal the number of entries in the list. What do we have in there?

[dreambottle]

The ScrollClipperContentAst itself is not null, but the ScrollClipperContentAst.ListeChild returns null for the Overview window

[dreambottle]

How does Bib3.Glob.SuuceFlacMengeAstMitPfaad() translate to English?

[dreambottle]

Ok, I think I found the root cause. Please review #12.

P.S. Sanderling works notably faster with the sensor branch, where you removed linking to the memreading dll.

[Viir]

P.S. Sanderling works notably faster with the sensor branch, where you removed linking to the memreading dll.

@dreambottle Thank you for reviewing the functionality of this change. I merged this into master together with your fix.

[Viir]

A summary of what I see in the commit ad1c44f contributed by dreambottle:

First some context

The memory reading expects the ListViews items to be contained in a Scroll. The scroll UIElement contains the actual item in one of its child nodes. The scroll can also contain other stuff like a scroll handle the user can interact with. So when reading the Scroll, we want to find different things in there and the items are to be found in the portion labeled as Content in the code.

Dreambottle changed how the Content node is selected

The SuuceFlacMengeAstFrüheste method used for this selection step first does a Breadth-first search within the node passed as the first argument and returns the first node which matches the predicate which is passed as the second argument. The changed line only affects the predicate and makes it more restrictive.
So the reason for the old version failing could be the introduction of another node in the UITree which matches the predicate and comes first in the breadth-first order but is not the node which contains the nodes for the items in the list view.

[Viir]

I created release v17.02.17 containing the fix from dreambottle.
@asdfasdf100500 does that release resolve the issue?

[asdfasdf100500]

Yup, works perfectly.