Hallo,
ich würde gerne in einer .dll eine Listview deklarieren, in der .dll überfüllen und so dann ans Hauptprogramm übergeben... nur kann man in einer .dll irgendwie keine Listview deklarieren... Gibts da einen Weg ?

Hey,

du musst einen Verweis auf System.Windows.Forms setzen und denn dann importieren

Projekt -> Rechtsklick -> Verweis hinzufügen -> .NET -> hinzufügen

mfg

Ich würde doch erst mal eine strikte Trennung von GUI und Daten empfehlen.
Dies lässt ein welch auch immer geartetes GUI-Element in einer DLL nur zu, wenn diese DLL ein UserControl implementiert.
Also Finger weg von rein- und rausreichen.

Einfach per Function zurückgeben lassen.

Sollte ungefähr so aussehen:

@BiedermannS: Was soll dieser Code in einer DLL?
Wenn es so einfach ist, kann as genau so gut im Hauptprogramm stehen. Und ausprobieren, ob es geht: Ja, es geht, aber das ist kein Grund dafür, es anzuwenden.

Es war ja nicht die Frage ob es Sinn macht, sondern wie es geht.

Wenn man über den Sinn dahinter diskutieren will gehen die Meinungen sicher auseinander, da es an sich nicht viel unterschied macht (Außer etwas in der Geschwindikeit).

Wenn es nur um das befüllen der ListView geht, dann macht es wohl mehr Sinn wenn man
a) die ListView direkt in der Form befüllt.

oder
b) die Routine zum befüllen in die DLL packt und eine Referenz zur ListView übergibt.

z.B.:


Aber das war ja nicht die Frage. An sich kann er auch die ganze Form in einer DLL speichern (Stichwort: Eigener Konstruktor :)), aber das war wiederum auch nicht das, wonach gefragt wurde.

Ich arbeite fast täglich mit meiner selbsterstellten COM-Bibliothek und darin sind viele Methoden/Funktionen welche man als sinnlos abtun kann. Aber durch die Einschränkungen, die durch COM gegeben sind, ist es manchmal nicht anders möglich...

BiedermannS schrieb:

Es war ja nicht die Frage ob es Sinn macht, sondern wie es geht.

richtig.
Und auch da ists vlt. die hilfreichere Antwort, darauf hinzuweisen, dasses nicht sinnvoll ist, obwohl danach garnet gefragt wurde.

Wie es geht ist natürlich auch die richtige Antwort, aber die hilft dem TE eigentlich nur dabei, "ein totes Pferd zu reiten".

Summary: Die richtige Antwort auf die falsche Frage schadet dem Fragenden in gewisser Weise eher, als dass sie hilft.

Aber wie gesagt, ich benötige auch öfter Codes an deren Sinnhaftigkeit man zweifeln kann und die jeder der in reinem .NET unterwegs ist mit dem Statement "sinnlos" abstempeln würde, aber manchmal ist es halt nicht möglich immer das beste zu nehmen, sondern man muss auf das zurückgreiffen was möglich ist.

Und da ich nicht weiß, ob der/die TE in so einer Situation ist (zu wenig Infos), kann ich diesbezüglich nur auf seine/ihre Frage antworten oder den tieferen Sinn seines/Ihres Vorhabens erfragen. Doch da der/die TE bereits 122 Posts im Forum hat, habe ich (ob nun fälschlicher Weise oder nicht) angenommen dass ein gewisses Grundwissen bereits vorhanden ist und somit der/die TE halbwegs weiß was er/sie tut.

Natürlich ist die Anzahl der Posts kein Maßstab für Programmierkenntnisse, doch an irgendetwas muss ich mich orientieren (da ich noch nicht alle Leute hier so gut kenne bzw. noch nicht so lange aktiv dabei bin, bleiben mir hier nur die Anzahl der Posts)

Wobei bei genauerer Betrachtung hier auffällt, dass der Weg mit der ListView in der DLL wohl eher der schlechtere Weg ist (hab wahrscheinlich schnell überflogen), ausser die gesamte Form wird in der DLL gespeichert, was wiederum einen komplett anderen Lösungsweg erforden würde...