User-Dialog als DLL erstellen

  • VB.NET
  • .NET (FX) 4.5–4.8

Es gibt 13 Antworten in diesem Thema. Der letzte Beitrag () ist von RodFromGermany.

    User-Dialog als DLL erstellen

    Hallo,

    kann man ein User-Dialog (WinForm) als DLL oder ähnliches erstellen, um es, wie ein UserControl, in anderen Projekten nutzen, oder es weiter geben zu können?

    Hintergrund, ich habe mir für ein Programm einen eigenen kleinen DateTimePicker-Dialog erstellt, um neben dem Datum die Uhrzeit benutzerfreundlicher auswählen zu können.
    Dann dachte ich mir daraus kann man ja ein UserControl als DLL machen (was auch geht), dies ist aber sehr groß und benötigt viele Platz auf einer Form, vor allem wenn man es nicht oft benötigt.
    Daher denke ist es besser dies als Dialog zu lassen, würde es aber gern "Verpacken".

    Daher die Frage wie gibt man so ein Dialog am besten weiter?

    Erstell dir eine ClassLibrary.
    Da packst du deinen Dialog und ggf. die Daten Klasse rein.
    So realisier ich Konfiguration Dialoge für meine Settings, da hast du immer den Dialog direkt mit den Daten in einem.

    @SoEinVBler Du musst die DLLs System.Windows.Forms und ggf. System.Drawing Deinem Projekt als Verweis hinzufügen.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Hallo,

    danke für alle Antworten, hab es dadurch jetzt hin bekommen.

    Allerdings hat das mit den Verweisen mir etwas zu schaffen gemacht.
    Ich fasse es mal zusammen.

    Ohne die Verweise auf System.Windows.Forms und System.Drawing wurde beim einfügen der ursprünglichen WindowsForm nur der Code importiert.
    Nach dem Setzen der Verweise, ist dann die Form importiert worden.

    Allerdings kamen dann noch Fehlermeldungen wenn ich mir das Design der Form anschauen wollte.
    Ich musst erst im Code der Form noch ein Import von System.Windows.Forms und System.Drawing einfügen.
    Und im (ich weiß nicht wie man das nennt) "DesignCode", in VisualStudio wird es mit Form1.designer.vb angezeigt, musste ich ebenfalls noch Import System.Windows.Forms einfügen.

    Im Ursprünglichem Programm musst ich diese Imports nicht machen, warum ist dass nun notwendig?
    Vor allem wenn man im Projekt ja schon ein Verweis auf beides hat.

    @SoEinVBler Mit welchem Framework bzw. welcher Net-Version arbeitest Du?
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Hallo,

    Hier die Info zu Visual Studio:
    Microsoft Visual Studio Community 2015
    Version 14.0.25431.01 Update 3
    Microsoft .NET Framework
    Version 4.8.04084


    Im Projekt hab ich als Zielframework 4.5.2 eingestellt.

    Muss aber gestehen, mit den FrameWorks kämpfe ich immer noch etwas.
    Wenn ich es richtig Verstanden habe ist bei mir das Framework 4.8... instaliert(kommt ja mit Win10 Update), in VS kann ich aber maximal 4.6 auswählen.

    Hab mit damit noch nicht auseinander setzen müssen, da ich ja nur für mich programiere, und das auch auf maximal meinen 2 Rechnern laufen lasse.
    Und da gab es bisher keine Probleme.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „SoEinVBler“ ()

    @SoEinVBler OK.
    Mit den Verweisen wirfst Du möglicherweise zwei Dinge in eine Schublade:
    Zunächst must Du Deinem Projekt die verwendeten DLLs als Verweis hinzufügen:
    Projekt => Eigenschaften => Verweise
    Als nächstes kannst Du im Quelltext ganz oben mit Imports System.Windows.Forms den verwendeten Namespace eintragen.
    Dann wird Dir das von der IDE beim Eingeben des Quelltextes ein passender Vorschlag gemacht.
    Wenn Du es nicht machst, musst Du den Namespace vor jeder Klasse selbst eintragen (nicht empfohlen).
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    Hallo,

    das ich in dem Projekt, in dem ich die Dll verwenden möchte, diese per Verweis einbinden muss, hatte ich so auch aufgefasst und umgesetzt.
    Den Import des NameSpaces der ClassLibrary hatt ich noch nicht, macht aber Sinn, vor allem wenn man mehrerer Klassen in so einer Library hat.

    Die Probleme mit dem Import von System.Windows.Forms und System.Drawing hatte ich ja beim erstellen ClassLibrary.
    Aber das hab ich jetzt glaub ich auch verstanden, mit dem Verweis, der ja auch in der ClassLibrary vorhanden war, mach ich die Dll (die Datei) dem Projekt bekannt.
    Den Namespace, für die "verkürzte" Verwendung, muss ich dann doch mit Import bekannt machen.

    Auf jeden Fall funktioniert es nun ich Danke noch mal.

    SoEinVBler schrieb:

    Den Namespace, für die "verkürzte" Verwendung, muss ich dann doch mit Import bekannt machen.
    Trenne den Verweis auf die DLL und den Import des Namespaces.
    Das sind zwei verschiedene Dinge, wobei der Imprt des Namespaces nur dann funktioniert, wenn im Projekt auf die DLL verwiesen wurde.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    SoEinVBler schrieb:

    Im Ursprünglichem Programm musst ich diese Imports nicht machen, warum ist dass nun notwendig?
    Vor allem wenn man im Projekt ja schon ein Verweis auf beides hat.
    Das liegt daran, dass das ursprüngliche Projekt nicht nur einen Verweis auf System.Windows.Forms und System.Drawing, sondern zusätzlich noch in den Projekteinstellungen einen "GeneralImport" der beiden.

    Was ein "GeneralImport" ist, erfährst du unter anderem auch, wenn du Visual Studio – Empfohlene Einstellungen in deim System umsetzt.
    Das Rauswerfen des VB6-Namespaces aus den GeneralImports ist nämlich eh was unabdingbares.

    SoEinVBler schrieb:

    aber wenn es hilft...
    Einige Helfer, die Dir posten, setzen so was implizit voraus.
    Zwei davon haben Dir geschrieben.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

Facebook
Telefonspende