Hallöle...
Ich verstehe die Welt nicht mehr...

markieren

Delphi-Quellcode:

TUserRoleRightDict = TObjectDictionary<Integer, TUserRoleRight>;
...
UserRight := TUserRoleRight.Create;
UserRight.RightID := StrToInt(ContentList[0]);
...
FModifiedUserRole.RoleRightList.Add(UserRight);
FModifiedUserRole.RoleRightDict.Add(UserRight.RightID, UserRight);

Zitat:

...
exception message : Zugriffsverletzung bei Adresse 0167C71D in Modul '.exe'. Lesen von Adresse 00000000.
...
main thread ($2f88):
0167c71d +015 .exe SEAM.Classes.Data 6239 +4 {System.Generics.Collections}TDictionary<System.In teger,Classes.Data.TUserRoleRight>.Hash
0167cefb +02b .exe SEAM.Classes.Data 6347 +4 {System.Generics.Collections}TDictionary<System.In teger,.Classes.Data.TUserRoleRight>.Add
0368b635 +211 .exe Form.UserManager.Logic 329 +28 CreateNewRole
0368b6c0 +008 .exe Form.UserManager.Logic 334 +1 TUserManager.UserRoleAdd
0368fc26 +082 .exe Form.UserManager 1079 +7 TfoUserManager.gtvUserRoleNavigatorButtonsButtonCl ick
...

PS: Das TObjectDictionary ist instanziert. Allerdings ohne Objektfreigabe. Die Freigabe wird über eine sortierte Liste mit diesen Objekten realisiert. Im Prinzip enthällt das Dict die Objekte nur besser zum Suchen.
PS: Die Liste enthällt das korrekte Objekt.

Danke für Infos...

Ich tipp mal auf nen falschen Konstruktoraufruf durch die ganzen Overloads beim TDictionary, so dass FComparer nil ist.
Was sonst soll ne AV beim Lesen von Adresse 00000000 in der Methode Hash verursachen

RoleRightDict.Create, statt RoleRightDict := TUserRoleRightDict.Create?

Zeig uns doch mal den Code wo das Dictionary erstellt wird.

Bitteschön...

markieren

Delphi-Quellcode:

FRoleRightDict := TUserRoleRightDict.Create; // Dict ohne Freigabe (sortierte Liste RoleRightList)
FRoleRightList := TUserRoleRightList.Create; // List gibt Objekte frei
...
FRoleRightDict := TUserRoleRightDict.Create([doOwnsValues]); // gleicher Fehler
FRoleRightList := TUserRoleRightList.Create(False);

Wer meinen dusslichen Fehler findet...dem gebe ich ein aus...

Nachtrag: FComparer ist nil.

- Stoppunkt nach dem Create und schauen, ob FRoleRightDict.FComparer assigned ist.
- Schauen, ob es nicht aus Versehen irgendwo freigegeben wird bevor der Add Aufruf passiert.

P.S. Ich glaub, ich mach mal für die Forentage 2020 einen "Fehleranalyse 101" Vortrag

Zitat:

Ich glaub, ich mach mal für die Forentage 2020 einen "Fehleranalyse 101" Vortrag

...Danke für die aufbauenden Worte. Kannst du dir vorstellen, daß ich für das Debuggen von "Bibliotheken" keinen Nerv/Zeit habe?

Ich verwende Dictionaries ständig. Einen Comparer habe ich noch nie benutzt. Ich erstelle die Instanz wie immer meistens mit [doOwnsValues].

Danke...

Nachtrag:

* Nach dem Create ist der Comparer Assigned (Pointer($3BFEF6C) as {System.Generics.Defaults}IEqualityComparer<System .Integer>)
* vor dem Add ist der Comparer Assigned (nil)
-> dazwischen passiert mit dem Dict nix. Das Dict wird erzeugt und dann beschrieben.

Eine Idee habe ich noch...aber erst morgen früh.

Zitat von haentschman:

Bitteschön...
FRoleRightDict := TUserRoleRightDict.Create([doOwnsValues]); // gleicher Fehler

Wenn ich mir die Exception und den Stacktrace anschaue, dann glaube ich eher das es am KEY liegt.
Ähnlich wie bei den Values, kann auch der KEY owned werden.

Zitat:

Wenn ich mir die Exception und den Stacktrace anschaue, dann glaube ich eher das es am KEY liegt.

Dem widerspricht die fast tägliche Benutzung / Implementierung eines Dictionaries. Die diesem Falle war aber eine Objektkopie des Datenobjektes mit enthaltenem Dictionary verantwortlich. Mit der Kopie ist der FComparer intern nicht instanziert worden.

Danke...