It's unclear why the access violation occurs, but assuming the FTreeView is being assigned a nil, the assignment check verifies the FTreeView is actually assigned before executing the EndUpdate. If the access violation occurs, there's most likely a different issue and this needs to be looked into. Can you prepare a sample or step by step instructions on how to reproduce this issue?
If the error occurs and I'm debugging in Delphi, I can see that the contents of Self (in my watch window) is complete rubbish. That's logical because the object is cleared.
The problem is that we are still in a routine of the already destroyed object.
So even checking if FTreeView is assigned will create an error because that property is also gone.
The problem is that I myself can't even reproduce the error simply.
I have to try and try. But no "standard path" to achieve this.
All depends probably how/when Delphi or Windows decides to clean up or overwrite the memory.
So creating a (simple) example program is not that easy.
I just have a Treeview with 8 items or so.
I then keep reordering them from sub levels to top level and back.
We have tried to reproduce this issue here but unfortunately haven't been able to reproduce this so far. Could you provide a sample and step by step instructions on how to reproduce this issue?
Like I mentioned in my 2nd text, I can't even reproduce it easy myself.
I probably depends on Windows (version) when memory is actually freed and the state your system is in (how many other applications are running, which percentage of memory is used or so).
But actually even without running the code, just looking at the code, it's obvious for me that problems can (and will) occur.
The code is running in a method of an object.
Within that method the object itself is freed (which is strange, I would think the Treeview should free it's nodes).
After freeing, there is still code in the (freed object)method to be executed.
And there's even a reference to a property of the freed object (FTreeview).
Not tested, but I think if we would change the RemoveNode to the following, the error would be more obvious.
This should avoid accessing private variables that might be un-initialized during destroy sequence of the node. If you apply this code, please provide feedback if this fixes the issue