Hallo liebe Community,

Ich stehe wohl wieder einmal auf dem schlauch, ich hab mir ein neues Projekt zur Brust genommen und habe ein Problem das für mich äußerst unlogisch erscheint, wahrscheinlich übersehe ich da was hoffentlich könnt ihr mir helfen also:

Ich habe eine HauptForm und eine Hauptdll und eine Subdll

Die HauptForm lädt dynamisch die Hauptdll diese wiederum dynamisch die Subdll, soweit funktioniert alles super.

Jetzt muss ich aber aus der Subdll Daten (String) in die HauptForm bekommen, um dies zu bewerkstelligen habe ich eine Form geschrieben:



der Form1 die eigenschaften von meiner Form vererbt.



mein Gedanke dabei war dass, ich die Hauptform als Parameter durch die dlls reiche bis hin zu meiner Subdll, dort ereicht sie die Funktion wo ich die Daten rüberschicken muss, da führt die Funktion der Subdll, den folgenden Befehl aus,

VB.NET-Quellcode

1. m_form.ChangeBe("O") 'm_form ist in dieser Klasse mein Attribut indem ich die Hauptform gespeichert hab.

Nach diesem Befehl wird das Event OnBeChanged ausgelöst (in meiner Hauptform) und schwups hab ich den String da wo ich ihn haben wollte.

So der Wurm steckt nun darin dass, eine Fehlermeldung bei der übergabe meiner Parameter vorkommt undzwar genau an der stelle wo die Parameter von der Hauptform in die Hauptdll übergeben werden.




Die Fehlermeldung lautet: Das Objekt mit dem Typ "BlitzCenter.Form1" kann nicht in den Typ "LoadAssambly.CenterForm" konvertiert werden.

BlitzCenter ist das Projekt mit der Hauptform.

LoadAssably ist das Projekt mit der Hauptdll.

Schonmal danke das ihr euch das überhaupt durchgelesen habt

Oh, oh - jetzt kommen 4 versch. Gedanken - bitte nicht sich nur mit einem davon auseinandersetzen:

1. ich denke: falsches Anwendungs-Design. Das Form sollte eine Instanz deiner Klasse enthalten, nicht umgekehrt. Wenn die Klasse am Form manipulieren will, dann soll sie ein Event feuern, welches im Form behandelt wird.
   gugge VeryBasics
   vlt. würdedas auch gleich deine InvalidCast-Exception reparieren.
   
   
2. Ah - InvalidCast-Exception! Wird in meim neuesten tut erwähnt (was leider noch nicht on ist): Da klingelt bei mir immer gleich, nach Option Strict On! zu fragen.
   Weil normal müsste bereits der Compiler rummeckern, ohne jeden Testlauf.
   
   
3. Ich vermute, inne Haupt-Dll hast du eine gleichnamige Klasse wie inne SubDll, aber nur weilse gleich benamt sind, ists nicht dieselbe Klasse.
   
   
4. Dann erwähnst du noch den LoadAssembly-Zirkus - das ist doch, wenn man PlugIns versucht, oder?
   
   Na, fiel Fergnügen damit - PlugIn bedeutet: eine Dll. wird verwendet, über die garnix bekannt ist. (Und von Klassen daraus kann man selbstverständlich auch nix erben)
   

Danke für die schnelle antwort

Also erstmal ja das ist nach einem Pluginsystem aufgebaut, und zweitens ja das hab ich auch gemerkt, deswegen hab ich ja in allen drei dll datein die selbe klasse reinkopiert (Center Form), zumindest dachte ich das es die selbe ist, du meinst ja iwi (4.) das ist nicht die selbe? wie meinst du das?

Mit option strict hab ich jetzt gefühlte 100 fehler behoben, aber da es ja eine dll ist wird der fehler es nicht sein, wenn er es überhaupt ist.

Deinen ersten punkt verstehe ich noch nicht so richtig, könntest du den nochmal erklären bitte?



Edit:

Was passiert eigentlich wenn ich eine klasse x der klasse y vererbe und neue sachen hinzufüge, wenn ich jetzt die klasse y in eine variable von klasse x speichere. gehen dann die neune sachen verloren?



Edit2:

Ich glaube ich hab was gefundne undzwar, ich erstelle in meiner hauptform eine klasse und den selben code kopiere ich in meine dll, die vehlermeldung die angezeigt wird ist : xyz.Klasse kann nicht in abc.Klasse konvertiert werden.

Aber die beiden sind doch identisch vom code her??? was mache ich falsch???

1. Blitzbirnep schrieb:

   Deinen ersten punkt verstehe ich noch nicht so richtig, könntest du den nochmal erklären bitte?

   Der Punkt ist ausführlich im gegebenen Link erklärt - bitte frage präziser, denn ich will das verlinkte hier jetzt nicht komplett wiederholen.
   
   

2. Blitzbirnep schrieb:

   Was passiert eigentlich wenn ich eine klasse x der klasse y vererbe und neue sachen hinzufüge, wenn ich jetzt die klasse y in eine variable von klasse x speichere. gehen dann die neune sachen verloren?
   

   auch unpräzise: Erbt nun Y von X, oder X von Y, und fügst du an X oder an Y neue Sachen zu?
   Auch hier ist die Frage zu umfassend, als dass ich sie hier in der notwendigen Ausführlichkeit behandeln könnte: dieses Buch Lesen Am im genannten Buch vermittelten Vererbungs-KnowHow kommst du so oder so nicht vorbei, wenn du proggen willst.
   
   

3. Blitzbirnep schrieb:

   ich erstelle in meiner hauptform eine klasse und den selben code kopiere ich in meine dll, die vehlermeldung die angezeigt wird ist : xyz.Klasse kann nicht in abc.Klasse konvertiert werden.
   
   Aber die beiden sind doch identisch vom code her?

   Das sagte ich bereits in post#2-pkt#3: Wenn du in 2 Dlls 2 Klassen hast, sind diese Klassen mitnichten identisch, auch wenn derselbe Code hineinkopiert ist. Eineiige Zwillinge sind ja auch nicht eine Person, sondern zwei.
   Damit führst du übrigens dein PlugIn-System ad absurdum, denn wenn du den Code nun eh in der Haupt-Dll hast, dann kannste das PlugIn ja auch weglassen.
   (wie gesagt: ich halte aus prinzipiellen Gründen nicht viel von PlugIn-Systemen)

   ErfinderDesRades schrieb:

   PlugIn bedeutet: eine Dll. wird verwendet, über die garnix bekannt ist. (Und von Klassen daraus kann man selbstverständlich auch nix erben - sie sind ja garnet bekannt)

   
   
   
4. Vorschlag für eine schrittweise Entwicklungs-Strategie:
   • Vergiß erstmal das PlugIn-Theater, und bring erstmal eine normale App ühaupt ans laufen
     
   • teile meinetwegen die App auf in mehrere Projekte, die in einer Solution zusammengebunden sind
     
   • Wenndes dir dann noch unbedingt antun willst, versuch, die ausgelagerten Projekte ganz herauszutrennen, und dann dynamisch als PlugIn zu laden.
     fiel Fergnügen damit
     
   • PS: Immer schön Backup machen
     

1. Wie will ich denn ein Event "feuern"?

Ja das hab ich jetzt auch gemacht eine Klasse geschrieben die aussieht wie im obeigen post "center Form" und die dann als instanz in meine form übergeben, dort wird er einmal mit new instanziert und nachdem durch die dlls, als parameter geschleust.

2. also Die Klasse SchönerApfel erbt von der KlasseApfel, alle eigenschaften, methoden, etc. erhält zusätzlich die methode "schönzusein",

So jetzt speichere ich den SchönenApfel (wurde vorher instanziert) in dei Variable "Dim x As Apfel = SchönerApfel", meine frage war jetzt hat x jetzt noch die methode "schönzusein"?

3. Ja das hab ich jetzt auch bemerkt, dein beispiel ist gut gewählt , dass wusste ich aber vorher noch nicht woran liegt das denn?

Wie gesagt ich hab das so gelöst das ich eine dritte dll, den zwei dlls verwiesen hab, und in dieser dritten dll steht nun die Klasse "CnterForm" die ich dann aus namensgründen in "Vermittler" umgeändert hab und die vererbung von Windows.Forms.Form entfernt hab.

4. Ja du hast recht, das war mir bewust, mein ziel ist es jedoch nicht dass andere anwender, plugins schreibn könne, mein Ziel ist es. Ok ich erkläre mein Projekt:

Als erstes hab ich ein einfaches spiel programmiert. Welches man an einem computer zu zweit spielen kann. Das hat meinen Freunden so seher gefallen das sie einen Multiplayer wollten, dieser sollte aber nicht lokal sein, d.h. zwei computer.

So, dann hab ich mich an die TCP programmierung gesetzt, ein paar tuts gelesen, und als übung einen chat geschrieben, dieser lief einwandfrei in den computerräumen an meiner schule.

Mit dem nötigen wissen hab ich jetzt ein Programm geschrieben, was dieses spiel (ebenfalls in form einer dll, diese dll ist meine subdll die ich vorher beschrieben hab) lädt und wiedergibt.

Damit ich jetzt nicht für jedes spiel das ich erstellen werde eine neu verbindungsprogramm erstellen muss hab ich mir gedacht ich mach das in der art von einem Pluginsystem, sodass ich spiele immer nach der gleichen strucktur programmiere und die dan durch dieses programm verbunden werden können. Deshalb steht z.B. der Code zum erstellen der GUI ebenfalls in der spiele dll drin.

So das ist mein projekt, wie gesagt ich hab das problem jetzt gelöst, die spieler können sich jetzt untereinander verbinden und der server empfängt die daten vom klienten und umgekehrt, das letzte was ich jetzt machen muss ist die auswertung von den daten, wenn du lust hast kann ich ja mal mein projekt hochladen und du kannst es dir anschauen, ich will aber keine umstände machen ist ja schon nett das du mir hier hilfst

1. Du schreibst in die Dll sowas wie:

So in etwa kann man sich das vorstellen.
In deinem Hauptprojekt wird dann irgendwas stehen wie:


2.
Man nehme Formen:


Davon leite man Rechtecke und Kreise ab:


Wir können also sagen:


Eines haben alle gemeinsam:
PositionX und PositionY
Das heißt also wir können die Position jedes Elementes problemlos herausfinden:


Schwieriger wird es, wenn man z.B. den Radius herausfinden möchte. Denn nicht jedes Shape hat einen Radius (nur die Shapes, die Circles sind).
Darum muss man zuerst herausfinden, von welchem Typ das Shape ist und anhand dessen was machen:

Tja, warum geht das nicht? Weil der Compiler ja noch nicht weiß ob i jetzt nur ein Shape ist oder doch ein Rectangle.
Darum muss gecastet werden:

Und warum muss bei SubForShape(i.PositionX, i.PositionY) nicht gecastet werden? Weil jedes i 1. bereits ein Shape ist und 2. mindestens ein Shape ist. Ich weiß, das hört sich jetzt doof an, aber es ist so: Jedes von Shape erbende Objekt hat eine PositionX und PositionY Eigenschaft.

Wichtig: Dieses Beispiel ist nur als Verdeutlichung gedacht! Es hat nicht wirlich einen parktischen Nutzen.

3.
Das liegt ganz einfach daran, dass niemand (außer Du) weiß, dass in der Dll effektiv der selbe Code steht wie im Hauptprojekt.
Wie die Fehlermeldung schon sagt: abc.Bla kann nicht in xyz.Bla umgewandelt werden.
Du siehst: Sie sind nicht gleich.

3.2. und 4.
Bei solchen Spielen kommen sogenannte Interfaces ins Spiel.
Das Ganze läuft so ab, dass Du im Hauptprojekt


Dieses Sytem ist allerdings für Dein Vorhaben nicht so gut geeignet. Ich gehe jetzt erst mal Abendessen und nachher melde ich mich wieder.
Dann erkläre ich wie es einfacher geht.


Edit:
So.
Ich erkläre mal wie es einfacher geht. Drehe die Ordnung um. Du hast Dein Spiel und diesem Spiel gibst Du die Dll, die das Senden/Empfangen der Daten verarbeitet.

Baue Deine Dll nach diesem Schema um:


Dann importierst Du die Dll in Dein Hauptprojekt (und auch in andere Spiele) und verwendest diese um die Daten zu senden und zu empfangen.
Importieren so:


Das hat auch erhebliche Vorteile was das Debugging betrifft. Denn externe Dlls kann man zwar debuggen (wenn es sich um eine im VS erstellte Dll handelt), aber es ist umständlicher Änderungen vorzunehmen. Und ich denke mal ein Spiel wird komplizierter und benötigt das Debugging dringender als die Dll.

@Niko

Vielen dank für deine ausführliche hilfe!! das war wirklich super!

Ich hab jetzt mein projekt nachdem auch etwas umgestalltet, die haupt dll die meine spiele lädit ist im grunde überflüssig deshalb hab ich die rausgeschmissen jetzt ist das ganze um einiges einfacher geworden, es gibt die hauptform (connector) und meine spiele die nach der selben struktur (also selbe funktions, methoden namen haben, sodass sie in meine hauptform passen) am anfang wähle ich halt aus welche dll geladen werden soll und dann wird das gemacht. !

Nochmal ein dickes Dankeschön! ihr seit einfach die besten!