Wie erfasst man den Ersatz einer (Property)Instanz?

VaporiZed · 21. Juni 2020, 09:33

Hallo zusammen,

im Thread EventHandler empfängt Eventfeuerung nicht zuverlässig habe ich es angedeutet: Ich will den Umgang mit der INotifyPropertyChanged-Schnittstelle vereinfachen. Dazu habe ich inzwischen folgendes:

Die Basisklasse, welche man später abgeleitet nutzt:

Spoiler anzeigen

VB.NET-Quellcode

Public MustInherit Class SimpleNotifyingClass : Implements ComponentModel.INotifyPropertyChanged
Public Event PropertyChanged As ComponentModel.PropertyChangedEventHandler Implements ComponentModel.INotifyPropertyChanged.PropertyChanged
Protected Sub New()
WireEvents()
End Sub
Private Async Sub WireEvents()
Await Threading.Tasks.Task.Run(Sub() WaitForInitializing())
For Each NotifyingProperty In Me.GetType.GetProperties.Where(Function(x) x.PropertyType.GetInterface(NameOf(ComponentModel.INotifyPropertyChanged)) IsNot Nothing)
AddHandler DirectCast(NotifyingProperty.GetValue(Me), ComponentModel.INotifyPropertyChanged).PropertyChanged, AddressOf PropertyChangedEventReporter
Next
For Each MortalProperty In Me.GetType.GetProperties.Where(Function(x) x.PropertyType.GetInterface(NameOf(IMortal)) IsNot Nothing)
AddHandler DirectCast(MortalProperty.GetValue(Me), IMortal).IsDying, AddressOf RegisterPropertyDeath
Next
End Sub
Private Sub WaitForInitializing()
Dim FirstNotifyingProperty = Me.GetType.GetProperties.FirstOrDefault(Function(x) x.PropertyType.GetInterface(NameOf(ComponentModel.INotifyPropertyChanged)) IsNot Nothing)
If FirstNotifyingProperty Is Nothing Then Return
Do Until FirstNotifyingProperty.GetValue(Me) IsNot Nothing : Loop
End Sub
Private Sub PropertyChangedEventReporter(sender As Object, e As ComponentModel.PropertyChangedEventArgs)
RaiseEvent PropertyChanged(Me, New ComponentModel.PropertyChangedEventArgs(String.Empty))
End Sub
Private Sub RegisterPropertyDeath(sender As Object, e As EventArgs)
PropertyChangedEventReporter(Me, New ComponentModel.PropertyChangedEventArgs(String.Empty))
End Sub
End Class

Die GenericProperty-Klasse

Spoiler anzeigen

VB.NET-Quellcode

Public Class GenericProperty(Of T) : Implements ComponentModel.INotifyPropertyChanged, IMortal
Public Event PropertyChanged As ComponentModel.PropertyChangedEventHandler Implements ComponentModel.INotifyPropertyChanged.PropertyChanged
Public Event IsDying As EventHandler Implements IMortal.IsDying
Private _Value As T
Public Property Value As T
Get
Return _Value
End Get
Set
If _Value.Equals(Value) Then Return
_Value = Value
NotifyPropertyChanged()
End Set
End Property
Private Sub NotifyPropertyChanged(<Runtime.CompilerServices.CallerMemberName> Optional Name As String = Nothing)
RaiseEvent PropertyChanged(Me, New ComponentModel.PropertyChangedEventArgs(Name))
End Sub
Public Shared Widening Operator CType(Value As T) As GenericProperty(Of T)
Return New GenericProperty(Of T) With {._Value = Value}
End Operator
Public Shared Widening Operator CType(Base As GenericProperty(Of T)) As T
Return Base.Value
End Operator
Public Overrides Function ToString() As String
If _Value Is Nothing Then Return Nothing
Return _Value.ToString
End Function
Protected Overrides Sub Finalize()
RaiseEvent IsDying(Me, Nothing)
End Sub
End Class

Das Minihilfsinterface

Spoiler anzeigen

Eine abgeleitete Klasse, die man im Hauptprogramm nutzen würde

VB.NET-Quellcode

Public Class Test : Inherits SimpleNotifyingClass
Property ID As New GenericProperty(Of Integer)
End Class

die Verwendung

VB.NET-Quellcode

Dim TestInstance As Test = Nothing
Private Sub FrmMain_Load(sender As Object, e As EventArgs) Handles MyBase.Load
TestInstance = New Test
BindingSource1.DataSource = TestInstance
End Sub
Private Sub Button2_Click(sender As Object, e As EventArgs) Handles Button2.Click
TestInstance.ID = 1
GC.Collect()
End Sub

GC.Collect() ruft die GenericProperty-Finalize-Sub auf, die dann dafür sorgt, dass die GenericProperty der SimpleNotifyingClass bescheid gibt, dass sie ersetzt wurde, also dass das INotifyPropertyChanged.PropertyChanged-Event gefeuert werden muss und z.B. eine BindingSource davon erfährt. Das ist nicht besonders schön, aber erstmal die einzige Möglichkeit, wie ich dafür sorgen kann, dass die SimpleNotifyingClass-Instanz davon erfährt, dass eine bestehende Property ersetzt wurde.

das Problem
Die durch den überladenen Shared-Implicit-Cast-Operator CType erstellte neue Instanz muss jetzt irgendwie der SimpleNotifyingClass bescheid geben, dass sie existiert. Aber eben erst, wenn die bestehende Property ersetzt wurde. Nicht dass jemand schreibt:

VB.NET-Quellcode

Dim Foo As New GenericProperty(Of Integer) = 1

und dass dann gar nicht an die SimpleNotifyingClass-Instanz weitergibt. Wie kann ich also den Ersatz der bestehenden SimpleNotifyingClass-Instanzproperty erfassen?
Ich habe es natürlich schon mit einer ObservableCollection(Of INotifyPropertyChanged) probiert, aber das klappt (natürlich) nicht, da diese die Ersetzung nicht erkennt, wenn man ein Item der Collection direkt ersetzt.

VaporiZed · 21. Juni 2020, 10:39

Ich bin einen kleinen Schritt weiter, auch wenn er mit unschönen Mitteln erreicht wurde.
Das ist gleich geblieben: Wenn eine bestehende Property geändert wurde, indem man deren Value ändert, feuert sie selber das PropertyChanged-Event (im weiteren PCE), welches von der SimpleNotifyingClass (im weiteren SNC) abgefangen wird. Und diese feuert wiederum selber ein PCE, um die BindingSources zu informieren.

Nun die Änderung: Das IMortal-Interface und somit auch das IsDying-Event sind raus. Stattdessen erfasst die SNC zu Beginn die HashCodes der Properties und prüft in festen Intervallen dieselbigen. Wird eine Property durch eine andere ersetzt, indem der überladene CType-Operator verwendet wird, hat die neue GenericClassProperty-Instanz definitiv einen anderen HashCode als die alte. Diese Änderung wird von der SNC-Prüfprozedur erkannt, sodass die SNC ihr eigenes PCE wieder feuern kann. Gleichzeitig merkt sich die SNC den neuen HashCode.

Nun die weiterführende Fragen:

Wie kann man das besser machen? Das nebenläufige, periodische Abfragen von HashCodes sollte keine nennenswerten Performanceeinbußen mit sich bringen. Aber irgendwie wurmt mich das trotzdem etwas. Geht das auch besser anders?
Das GUI wird korrekt informiert, nur die Änderungen in z.B. einer TextBox rebellieren noch, da das entsprechende CE nicht mehr verlassen werden kann und auch das Beenden der App nicht mehr geht - außer über den Debugger. Offensichtlich scheitert der Versuch, den Propertyvalue über die BindingSource zu ändern.
Offtopic: Ich vermute, dass auch ein FileSystemwatcher wie meine jetzige Lösung arbeitet, also periodisch den Zustand eines Verzeichnisses o.ä. abfragt. Macht er es intelligenter und könnte ich von seinem Verhalten etwas in mein Problem zur Lösung einfließen lassen?

Gonger96 · 21. Juni 2020, 14:50

Nebenläufig irgendwas überprüfen finde ich sehr unschön. Da sind explizite Get/Set Methoden schöner. Ich befürchte mal so wie du es vorhast, wird's nicht funktionieren. Um die Instanz der Propertyklasse zu kriegen musst du in den Setter der jeweiligen Instanz. So macht es Microsoft ja sowohl bei INotifyPropertyChanged, als auch bei DependencyProperties.

VaporiZed · 21. Juni 2020, 21:30

Ich bin auch nicht sonderlich über die Lösung erfreut. Aber sie funktioniert. Deinen Vorschlag mit den Gettern/Settern verstehe ich insofern nicht, weil ich nicht weiß, wie das weitergehen soll. Wenn durch den Aufruf

VB.NET-Quellcode

TestInstance.ID.Value = 1

der PropertySetter aufgerufen wird, ist alles gut. Wenn durch den Aufruf

VB.NET-Quellcode

TestInstance.ID = 1

der CType-Operator eine neue GenericInstance(Of Integer) erstellt wird und damit die TestInstance.ID-Instanz überschrieben wird, habe ich ein Problem. Denn diese Ersetzung kann ich nicht abfangen. Daher sehe ich erstmal nur die periodische HashCodePrüfung als Weg, die Ersetzung zu detektieren. Wenn Du einen besseren Weg kennst, bin ich dafür offen. Das Problem ist, dass die neu erstelle GenericProperty-Instanz sich selbst nicht bei der SNC-Instanz anmelden kann. Auch kann die SNC-Instanz die neue GenericProperty-Instanz nicht erfassen. Würde ich einen GenericProperty-Konstruktor machen, der als Parameter die SNC-Instanz nimmt, damit die Verknüpfung zwischen den Instanzen hergestellt werden kann, klappt das mit dem CType-Operatoraufruf nicht mehr, da dieser Shared sein muss. Vor diesen Problemen stehe ich.

VaporiZed · 22. Juni 2020, 10:53

Um mein eigentliches Problem zu lösen, hat mich @exc-jdbi noch auf eine andere Variante hingewiesen, die mich am Ende zu dieser Seite geführt hat. In C# kann man da sehr gut den Property-BoilerPlateCode zusammenschmelzen lassen. Dafür die Basisklasse.

Basisklasse

Durch die VB.Net-Syntax komm ich dabei allerdings meinem Ziel nicht viel näher, da dann sowas rauskommt:

VB.NET-Quellcode

Public Class Test1 : Inherits NotifyBase
Property ID As Integer
Get
Return [Get](Of Integer)()
End Get
Set
[Set](Value)
End Set
End Property
End Class

Effektiv also keine deutliche Kürzung. Das Private Field verschwindet aus der abgeleiteten Klasse, genauso wie das PropertyChanged-Eventfeuern. Aber ich wollte ja mehr (oder weniger? Wie man möchte).

Ich leg das Ganze jetzt erstmal auf Eis (≙ ich gebe auf und werde keine Energie mehr in das Vorhaben reinstecken*) und greife zu einem Trick, den ich ja schon verwende: Ich überprüfe einfach periodisch die PropertyValues der nun normalen Properties an sich. Damit ist mein Ziel durch eine dreckige Abkürzung erreicht, Stichwort KISS.

Ziel mit Cheat

VB.NET-Quellcode

Public MustInherit Class SimpleNotifyingClass : Implements ComponentModel.INotifyPropertyChanged
Public Event PropertyChanged As ComponentModel.PropertyChangedEventHandler Implements ComponentModel.INotifyPropertyChanged.PropertyChanged
Private ReadOnly PropertyList As New Dictionary(Of Integer, Object)
Protected Sub New()
RememberAllProperties()
InspectProperties()
End Sub
Private Sub RememberAllProperties()
Array.ForEach(Me.GetType.GetProperties, Sub(x) PropertyList.Add(x.GetHashCode, x.GetValue(Me)))
End Sub
Private Async Sub InspectProperties()
Do
Await Threading.Tasks.Task.Delay(100)
ReportChangedProperties()
Loop
End Sub
Private Sub ReportChangedProperties()
Dim KeyList = PropertyList.Select(Function(x) x.Key).ToList
For Each Key In KeyList
Dim SavedValue = PropertyList(Key)
Dim [Property] = Me.GetType.GetProperties.First(Function(x) x.GetHashCode = Key)
Dim CurrentValue = [Property].GetValue(Me)
If Not ThereAreChanges(SavedValue, CurrentValue) Then Continue For
PropertyList.Item(Key) = CurrentValue
ReportPropertyChanged([Property].Name)
Next
End Sub
Private Function ThereAreChanges(SavedValue As Object, CurrentValue As Object) As Boolean
Return SavedValue Is Nothing AndAlso CurrentValue Is Nothing OrElse SavedValue IsNot Nothing AndAlso SavedValue.Equals(CurrentValue)
End Function
Private Sub ReportPropertyChanged(PropertyName As String)
RaiseEvent PropertyChanged(Me, New ComponentModel.PropertyChangedEventArgs(PropertyName))
End Sub
End Class

Jetzt kann ich ganz normal schreiben

VB.NET-Quellcode

Public Class FrmMain
Dim TestInstance As Test = Nothing
Private Sub FrmMain_Load(sender As Object, e As EventArgs) Handles MyBase.Load
TestInstance = New Test
BindingSource1.DataSource = TestInstance
End Sub
Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
TestInstance.ID = 123
TestInstance.SomeNumber = 666
TestInstance.Name = "VaporiZed"
TestInstance.DateOfBirth = Date.Today.AddDays(10).AddYears(-99)
End Sub
End Class
Public Class Test : Inherits SimpleNotifyingClass
Property ID As Integer
Property SomeNumber As Integer
Property Name As String
Property DateOfBirth As Date
End Class

und wenn sich eine Property ändert, wird die BS spätestens nach knapp 100 ms informiert und updatet das GUI.

* Das Problem ist auch gewesen, dass die Anbindung an ein Control zwar funktionierte, aber das Wertändern nicht mehr (oder nur mit Konvertierzeilen im Validating-EventHandler). Das war mir dann zu blöde.

ErfinderDesRades · 22. Juni 2020, 20:54

Hi!

Ich staune ja seit kurzem einige deiner Threads an, die iwas mit INotifyPropertyChanged zu tun haben, und ich versteh nicht was du willst.
Mein derzeitiger Vermutungs-Stand ist: Du möchtest von dem lausigen Zwang wegkommen, beim Implementieren von INotifyPropertyChanged für jede Property 9(!) Zeilen vb.net-Code aufzuwenden - wie:

VB.NET-Quellcode

'--------------
' T4-generated file - don't mess it up
'--------------
Imports System, System.ComponentModel, System.Linq, System.Collections.Generic, System.Collections.ObjectModel
Namespace BestellungenEdm
Public Class BestellPosten : Inherits NotifyPropertyChanged
Private _Id As Integer
Public Property Id As Integer
Get
Return _Id
End Get
Set(ByVal value As Integer)
ChangePropIfDifferent(value, _Id)
End Set
End Property
Private _Count As Integer
Public Property Count As Integer
Get
Return _Count
End Get
Set(ByVal value As Integer)
ChangePropIfDifferent(value, _Count)
End Set
End Property
'...

Das ist jetzt das absolute Minimum an Code-Aufwand, was in vb.net möglich ist: 9 Zeilen: nämlich eine Zeile Backingfield deklarieren, 2 Zeilen die Property, 3 Zeilen der Getter darin, 3 Zeilen der Setter.
Das ist tatsächlich super-lausig, weils tausendfach sich wiederholender Boiler-Plate-Code ist - aber wie gesagt: Ich habe bislang nix kompakteres gefunden.

Zunächst aber zwei Fragen:

Habich die Problematik endlich verstanden?
Wenn ja: habich was zu lesen übersehen, oder steht das bislang tatsächlich nirgends?

Wie dem auch sei, und falls das tatsächlich das Thema ist: Daran habich mir auch schon einige Zähne ausgebissen, und nix wirklich überzeugendes gefunden.
Mir sind derzeit mehrere Umgänge damit bekannt

Fody
Man kann sich iwie eine Fody-Extension oder AddOn runterladen und iwie einbinden, welcher den Boiler-Plate-Code injiziert, noch nachdem die Klasse in IL übersetzt ist. Oder so ähnlich - ich habs nie gemacht wegen der zusätzlichen Abhängigkeit, und weil wenn ich solchen Code verteile, das die Empfänger zwingen würde, sich auch Fody raufzuschaffen - sonst würde mein Code bei denen nicht laufen
CodeGenerierung
siehe obiges Beispiel: Ich hab mir ein irrwitziges T4-Template geschrieben für *.edmx-Dateien. Nun kann ich Datenklassen in .edmx-Designern designen, und das T4 generiert mir Designer-Code wie oben gezeigt.
CodeGenerierung, die INotifyPropertyChanged unterstützt, findet ja auch bei Verwendung typisierter Datasets statt - mein *.edmx-T4-Template brauche ich für Wpf-Entwicklung - wo Dataset-Databinding ja nicht richtig funktioniert.
noch mehr CodeGenerierung
man könnte auch einen Codegenerator schreiben, der CodeFiles untersucht, und wenn sie ein bestimmtes Attribut aufweisen, dasser dann alle Auto-Properties darin umschreibt
Regions
um diese "neun-Zeilen-statt-einer"-Schaurigkeiten nicht angucken zu müssen kann man auch mit Regions arbeiten.
Partiale Klassen
Von Regions halte ich eiglich nix - ich würde derlei Code in Partiale Klassen wegsperren
Kann man sich überlegen, ob man die Backing-Fields nicht in der richtigen Logik-Datei belässt - damit man dort auch sieht, welche Properties die Klasse bereitstellt.
Self-Change-Polling
Das ist jetzt wie ich benennen würde, was ich von deinem Ansatz zu verstehen meine: Die Datenklasse stellt Property-Änderungen nicht mehr direkt im Setter fest und reagiert, sondern unterhält für jede Auto-Property (irgendwo) ein zweites BackingField, um es dann pollend mit dem "richtigen" BackingField zu vergleichen, und so Property-Änderungen feststellen und drauf reagieren.

spannender Ansatz, weil dabei der Code-Ablauf beim Databinding sich stark ändert. Standard-Databinding funktioniert bislang blockierend - also eine Property-Änderung löst direkt EventCode aus, und da kann u.U. sehr viel passieren. Weiter gehts aber erst, wenn das alles passiert ist.
Mit deim Ansatz gehts sofort weiter, und das Event-Auslösen erfolgt zeitverzögert.
Das muss nicht unbedingt ein Nachteil sein - vielleicht hat das in bestimmten Szenarien sogar Vorteile.
Vermutlich (hoffentlich) wird man den Unterschied aber kaum merken.

Nachteile wären jedenfalls erhöhter Speicherbedarf und Prozessorlast, sowie schlechtere Performance - aber das sollte man erstmal abwarten, wie dolle das zu Buche schlägt.

VaporiZed · 22. Juni 2020, 21:19

ErfinderDesRades schrieb:

Mein derzeitiger Vermutungs-Stand ist

…korrekt.
Und das habe ich geschafft, mit PropertyValuePolling. Nicht schön, aber funktioniert.

ErfinderDesRades schrieb:

Habich die Problematik endlich verstanden?

Ja.
Zu Deinen Lösungsansätzen:

externe Codegenerierung: Ist nicht meins.
Regions: Ich ~~verabscheue~~ vermeide Regions (auch wenn ich es in meinem Tut als Möglichkeit erwähne)
Partiale Klassen: War auch mein Vorschlag in meinem Tut bei 4.1 - Nachteile

##########

ErfinderDesRades schrieb:

habich was zu lesen übersehen, oder steht das bislang tatsächlich nirgends?

Weiß nicht, was Du meinst. In Post#1 in den ersten beiden Spoilern ist je die erste Zeile mit Implements ComponentModel.INotifyPropertyChanged versehen. Oder ich versteh Dich falsch.

ErfinderDesRades · 22. Juni 2020, 22:37

VaporiZed schrieb:

externe Codegenerierung: Ist nicht meins.

Echt nicht?
Bzw was verstehst du unter externe CodeGenerierung?

Wenn du ein WinForms designest verwendest du ja auch CodeGenerierung - wäre die "extern"?
Beim typDataset ists das gleiche wie WinForms
Bei Verwendung von *.Edmx ists fast das gleiche: Ein Designer generiert Code - das T4-Template dafür ist Voreinstellung
Aber man kann bei *.edmx das T4 auch auswählen (meine Wpf-Variante) - wäre das dann "extern"?
Oder ein selbstgebasteltes Tool drüber laufen lassen. Das wäre in gewissem Sinne auch keine CodeGenerierung, sondern ist eiglich wie alles selbst ausschreiben.
Weil andere kriegen ja nur das Ergebnis, und haben auch keinen Designer, mit dem sie mein Ergebnis versehentlich kaputt machen könnten.
oder meinst du mit "extern" nur den Fody?

Also 1. ist wohl deins. Bei 2. glaub ich aber doch, bin aber nicht sicher - evtl. verwendest du typDts garnet.
Also welche der 6 CodeGenerierungs-Varianten sind "extern", und also "nicht deins"?

VaporiZed · 22. Juni 2020, 23:07

Ok, schlecht formuliert. Ich habe nicht vor, irgendwelche Plugins wie Fody oder PostSharper zu nutzen, sondern das Ziel mit Hausmitteln zu erreichen. Mit T4 habe ich mich nur anfänglich beschäftigt. tDS benutz ich nicht mehr bzw. baue gerade um. Denn dortige Veränderungen werden ja sofort im GUI gezeigt. Da brauche ich ja meinem Bastelkram nicht, würde ich das weiternutzen. Aber einige tDS-Aspekte sagen mir nicht mehr zu, daher wende ich mich davon ab.

nafets · 24. Juni 2020, 07:29

Dein "Problem" mit Polling zu lösen halte ich für absolut keine gute Idee. Die Performanceimplikationen von den ständigen wiederholten Gleichheitsabfragen können schnell immens werden und ganz abgesehen von den direkten Auswirkungen hiervon hast du zusätzlich noch die Verzögerung, weil du nur alle 100ms + Prüfzeit die UI/... aktualisierst. Das alles Mal abgesehen davon, dass das sowieso ne richtig unsaubere Lösung ist.

Wenn dich die Property-Bodies im Code so extrem stören, mach dir doch, ähnlich wie EDR angedeutet hat, ne Codegenerierung, die dir den Code in ner partiellen Klasse dazugeneriert (geht mit VS-eigenen Tools) und wenn's nur ums Schreiben geht, mach dir nen Snippet in VS, was den Code für dich schreibt.
Und wenn du nichts gegen externe Dependencies hast, ist Fody ne super Lösung - das PropertyChanged-Addin von denen macht das auf ne saubere Art und Weise automatisch, ohne dass was konfiguriert werden muss.

Nofear23m · 24. Juni 2020, 08:09

Ich verstehe den Gedankengang und ich kan verstehen das man wenig Code haben will, insbesonders bei den Properties.

Allerdings muss ich sagen.... ich würde auch wenn es denn eine vernünftige Möglichkeit gibt hier ein Propertie ohne Backingfield definieren zu können NIE zu dieser Lösung greifen.
Warum? Ja, zum einen muss ich den code ja garnicht schreiben. Das macht mir eh VS. prop + TAB + TAB. Fertich. Und zum anderen kann ich jederzeit einen Haltepunkt z.b. im Seter setzen um zu sehen was passiert, das ist etwas was ich nicht missen möchte.

Ein weiterer Grund ist aber auch das man bei korrektem MVVM dann auch sehr häufig Klassen hat welche ein Model-Objekt Wrappen in welchen die Lösung dann sowieso wieder nicht zu gebrauchen ist.

Beispiel:

VB.NET-Quellcode

Public Class Auto
Public Property Marke As String
Public Property Modell As String
Public Property KW As Double
End Class
Public Class AutoViewModel
Inherits ViewModelBase
Private ReadOnly _carModel As Auto
Public Sub New(_car As Auto)
_carModel = _car
End Sub
Public Property Marke() As String
Get
Return _carModel.Marke
End Get
Set(ByVal value As String)
_carModel.Marke = value
RaisePropertyChanged()
End Set
End Property
Public Property Modell() As String
Get
Return _carModel.Modell
End Get
Set(ByVal value As String)
_carModel.Modell = value
RaisePropertyChanged()
End Set
End Property
Public Property PS() As String
Get
Return _carModel.KW * 1.36
End Get
Set(ByVal value As String)
_carModel.KW = value / 1.36
RaisePropertyChanged()
End Set
End Property
End Class

Und zu guter letzt habe ich mir in VS sowieso meine Vorlagen eingerichtet. Statt prop tippe ich wpfprop + TAB + TAB und bekomme ein Propertie inkl. den RaisePropertyChanged() generiert.

Das ist meine Meinung und soll nun natürlich nicht so gesehen das ich das wem einreden möchte, ich denke mir nur das es wenig sinn macht.
Grüße
Sascha

Wie erfasst man den Ersatz einer (Property)Instanz?

Wie erfasst man den Ersatz einer (Property)Instanz?

VB.NET-Quellcode

VB.NET-Quellcode

VB.NET-Quellcode

VB.NET-Quellcode

VB.NET-Quellcode

VB.NET-Quellcode

VB.NET-Quellcode

VB.NET-Quellcode

VB.NET-Quellcode

VB.NET-Quellcode

VB.NET-Quellcode

VB.NET-Quellcode

VB.NET-Quellcode

ErfinderDesRades schrieb:

ErfinderDesRades schrieb:

ErfinderDesRades schrieb:

VaporiZed schrieb:

VB.NET-Quellcode

Ähnliche Themen

5 Benutzer haben hier geschrieben