VisualStudio 2017 - VB.NET Programmierung - Programm fügt bei neuem Private Sub immer nur .... handles MyBase ... ein.

  • VB.NET
  • .NET 4.5

Es gibt 12 Antworten in diesem Thema. Der letzte Beitrag () ist von Dirgi.

    VisualStudio 2017 - VB.NET Programmierung - Programm fügt bei neuem Private Sub immer nur .... handles MyBase ... ein.

    Neu

    Hallo, nachdem ich mir hier schon viele tolle Tips und Tricks geholt habe dachte ich, ich könnte hier mein Problem auch mal "flaggen".
    Vielleicht hat ja hier Jemand eine Lösung für mich. Habe bisher dazu noch nichts aussagekräftiges im Netz gefunden.

    Ich habe folgendes Problem. (Ich beschreibe es mal).
    (Ich Programmieren unter VS 2017 in VB)

    Ich lege eine Form an und dort lege ich einen Button an (kann auch ein anderes Element sein).
    Doppelklicke ich nun den Button an, wird die dazugehörige Public Class Form angelegt nebst der Private Sub Anweisung zum "Button click".

    Die Private Sub sollte in Prinzip so lauten:

    VB.NET-Quellcode

    1. Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click

    soweit so gut.


    Gebe ich dem Button aber einen umfangreicheren Namen, weil ich ihn zB von meinem Form Namen ableite, als Beispiel etwas so:
    Form_MainWindow_Button1_Proceed

    Erstellt mir VS nun nach Doppelklick folgende Private Sub:

    VB.NET-Quellcode

    1. Private Sub Form_MainWindow_Button1_Proceed_Click(sender As Object, e As EventArgs) Handles MyBase_Button1_Proceed.Click


    Egentlich müsste es aber am Ende heißen: Handles Form_MainWindow_Button1_Proceed.click und nicht Handles MyBase_Button1_Proceed.Click
    mit der Folge, das VB mir das immer als Fehler anzeigt und erst, wenn ich es selbst korrigiere wie zuletzt gezeigt, wird es akzeptiert.
    Das ganze ist jetzt zwar kein "Beinbruch" nervt mich aber etwas, weil ich dauern nachkorrigieren muß.
    Hat hier Jemand eine Idee, wie und wo ich das Lösen kann? - Gibt es da vielleicht irgendwo eine Einstellung in den Settings? - Oder "beißt" sich da VS vielleicht mit
    dem Form Namen? ?(

    Im übrigen: Die Form auf der sich der Button befindet hat den Namen Form_MainWindow
    (das kann man sicher aus den Angaben ableiten, wollte es der Vollständigkeit halber hier einfach nochmal erwähnen)
    und der Botton hat den Modifier "Friend" (also Standard) - Wenn ich hier einen anderen einstelle, passt es noch weniger.

    Freue mich über eine Antwort,
    Gruß Dirk :)

    *Bitte forenregeln beachten - die Farbe ROT ist der Moderation vorbehalten* ~NoFear23m

    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von „Nofear23m“ ()

    Neu

    Willkommen im Forum.
    Tja, da wird wohl Visual Studio proaktiv Textersetzung durchführen, wenn Du Dein Form eben Form_MainWindow nennst. Aber Deine Benennung ist aber auch ... suboptimal. Was bringt es Dir aufgrund des Namens zu wissen, wo der Button ist? Er kann ja nur auf dem Formular sein, bei dem Du gerade bist. Einen Zugriff von woanders zu gestalten weist (meist!) auf einen Designfehler hin. Die meisten belassen es eher bei BtnSaveFile oder btLoadDataFromDatabase oder sowas.

    btw: Rot ist den Moderatoren vorbehalten.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Häufig von mir verwendete Abkürzungen: CEs = control elements (Labels, Buttons, DGVs, ...) und tDS (typisiertes DataSet)
    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht in den Spekulatiusmodus gehen.

    Neu

    @VaporiZed Jou.
    @Dirgi Willkommen im Forum. :thumbup: Deine Namensgebungen werde ich nicht nachvollziehen. Jeanshosen, Cuttermesser und Co klingt einfach blöd.
    Zunächst genügt es, das Hauptfenster MainWindow zu nennen.
    Wenn Du dann den Button noch BtnProceed nennst, ist der Code klar und verständlich lesbar, auch für dritte und sogar noch in einem halben Jahr. ;)
    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).
    VB-Fragen über PN / Konversation werden ignoriert!

    Neu

    Dirgi schrieb:

    Egentlich müsste es aber am Ende heißen: Handles Form_MainWindow_Button1_Proceed.click und nicht Handles MyBase_Button1_Proceed.Click
    Das sieht für mich danach aus, als ob Form_MainWindow von einer anderen Klasse abgeleitet ist.
    --
    If Not Program.isWorking Then Code.Debug Else Code.DoNotTouch
    --

    Neu

    Ja. Von Form. Wenn man ein Control so benennt, dass am Anfang der Name des Container-Forms steht (default Form1 -> Form1_Button), dann kommt dieses Verhalten von VS.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Häufig von mir verwendete Abkürzungen: CEs = control elements (Labels, Buttons, DGVs, ...) und tDS (typisiertes DataSet)
    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht in den Spekulatiusmodus gehen.

    Neu

    Hallo VaporiZed, danke für Deine Antwort - Aber es es hat schon Gründe, warum ich die Elemente so benenne.

    Tja, da wird wohl Visual Studio proaktiv Textersetzung durchführen, wenn Du Dein Form eben Form_MainWindow nennst. Aber Deine Benennung ist aber auch ... suboptimal. Was bringt es Dir aufgrund des Namens zu wissen, wo der Button ist? Er kann ja nur auf dem Formular sein, bei dem Du gerade bist. Einen Zugriff von woanders zu gestalten weist (meist!) auf einen Designfehler hin. Die meisten belassen es eher bei BtnSaveFile oder btLoadDataFromDatabase oder sowas.


    Natürlich könte ich sie auch anders anders benennen - Ich will aber sehen, woher die Elemente stammen und wo sie dazugehören. Da ich sie auch dazu benutze um die Bezeichnung (Sprache) der Elemente zu ändern.
    So sehe ich gleich in der Dazugehörigen ini, wohin das Element gehört. Sollte jetzt aber mal egal sein.

    In deinem zweiten Post
    Ja. Von Form. Wenn man ein Control so benennt, dass am Anfang der Name des Container-Forms steht (default Form1 -> Form1_Button), dann kommt dieses Verhalten von VS.

    hast Du schon eher eine Erklärung dafür, dass das wohl von VS kommt und es damit nicht richtig zurechtkommt. Wobei ich mir das nicht wirklich erklären kann. Denn eigentlich müsste VS ja nur Prüfen, ober der vergebene Name
    regelkonform ist und dann bei Handles einfach noch ein .click anhängen. Den Namen des Subs schreibt es ja auch richtig.




    Hallo petaod.

    petaod schrieb:

    Dirgi schrieb:

    Egentlich
    müsste es aber am Ende heißen: Handles
    Form_MainWindow_Button1_Proceed.click und nicht Handles
    MyBase_Button1_Proceed.Click
    Das sieht für mich danach aus, als
    ob Form_MainWindow von einer anderen Klasse abgeleitet ist.


    also...der Ursprung ist eine jundfräuliche From, die von mir halt in diesem Falle den Namen Form_MainWindow.vb bekommen hat.
    Dort hinein ein Button nagelegt, ihm den Namen Form_MainWindow_Button_Proceed gegeben ihn doppelt angeklick und dann erstellt mir ja VS normalerweise die dazugehörogen Class selbst.
    In diesem Falle:

    VB.NET-Quellcode

    1. Public Class Form_MainWindow

    und darin dann wie bereits benannt automatisch das Private Sub für den
    Button - Nur eben benennt er ihn bei Handles nicht richtig.

    Würde
    mich mal interessieren, ob das bei Euch auch so aussieht, wenn Ihr
    unter vb.net eine neue Form anlegt und dann der gleiche Effekt auftritt.

    Habe nun experimentell unter VS2017 ein neues Projekt angelegt mit einer leeren Form. Diese in: Form_DiesIstEineTestForm benannt, darauf einen button platziert und diesen in
    Form_DiesIstEineTestForm_UndDasDerButtonDazu benannt. Und so sieht wieder das Ergebnis nach Doppelklick auf den Button in der Class aus.

    VB.NET-Quellcode

    1. Public Class Form_DiesIstEineTestForm
    2. Private Sub Form_DiesIstEineTestForm_UndDasDerButtonDazu_Click(sender
    3. As Object, e As EventArgs) Handles MyBase_UndDasDerButtonDazu.Click
    4. End Sub
    5. End Class


    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von „Dirgi“ ()

    Neu

    @Dirgi @VaporiZed Unter VS2017 kann ich dieses merkwürdige Verhalten reproduzieren, Unter VS2013 passiert das zum Glück leider nicht.
    Das ist ein weiterer von mehreren Punkten, wo sich das Studio VS2017 von seinen Vorgängern unterscheidet.
    Vielleicht ein Grund, dies mal in einem Sammelthread zusammenzufassen.
    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).
    VB-Fragen über PN / Konversation werden ignoriert!

    Neu

    Hallo RodFromGermany,
    ja - Deshalb hatte ich in dem Post vor Dir ebenso nochmal etwas "jungfräuliches" aufgesetzt - Nicht, dass ich irgendwo vielleicht einen falschen Schalter umgelegt hatte - Aber wie Du bereits erwähnt hast, ist dieses Verhalten unter VS2017 reproduzierbar - Ist wirklich seltsam.

    Hmm, VS2017 ist im großen und Ganzen ok. Benutze die Community Version - Das reicht mir eigentlich.
    Hatte nach 20 Jahren VB Abstinenz mal wieder den Need mir was zu schreiben. Im Prinzip fängst Du da dann wieder von vorne an und VB erschlägt dich. Programmiere mir zwar gelegententlich bei Excel in VBA (geschäftlich) was - Ist aber kein Vergleich.
    Hatte letztes Jahr mal mit der freien Visual Basic Express 2010 angefangen was zu programmieren - Wurde aber nicht fertig. Nachdem ich dann weiter machen wollte, mir aber zwischenzeitlich einen neuen Rechner aufgesetzt hatte,
    meinte MS: VB Express 2010 wird nicht mehr unterstützt und ich müsste VS2017 nehmen. Also habe ich es genommen und da weitergemacht....

    Wenn also keiner eine Lösung hat, außer das es wie schon vermutet an VS selbst liegt (über Namensgebung kann man sich bekanntlich streiten) kann man eigentlich auch diesen Thread hier schließen.

    Neu

    @Dirgi Schließen kannst Du diesen Thread selbst, doppelklicke auf das abgerundete Quadrat oben neben dem Titel.
    Die VS2017-Effekte-Sammlung hab ich mal fix angelegt, wenn Du noch was feststellst, stell das da mit rein: Sammelthread: Unterschiede von VS2017 zu älteren Studios
    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).
    VB-Fragen über PN / Konversation werden ignoriert!

    Neu

    Dirgi schrieb:

    hier das Sub richtig anzulegen.
    Ich halte das für einen Fehler / Effekt im Studio, zumal es beim Studio 2013 problemlos funktioniert.
    Da sind doch schon einige Dinge verschlimmbessert worden. :/
    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).
    VB-Fragen über PN / Konversation werden ignoriert!

    Neu

    Es gäbe ne Art Woraround: Im Code-Editor die Events anlegen:

    Das Anlegen des Events über den Designer geht hingegen auch nicht.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Häufig von mir verwendete Abkürzungen: CEs = control elements (Labels, Buttons, DGVs, ...) und tDS (typisiertes DataSet)
    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht in den Spekulatiusmodus gehen.

    Neu

    So, ich schließe den thread hier.
    Neue Erkenntnisse kamen ja seit gestern nicht mehr - Also ist es wohl ein "bug" bei VS2017 - Der allerdings nur etwas nervig und nicht gefährlich ist.
    Ich bedanke mich bei den Schreibern hier für das rege Feedback.

    In diesem Sinne, Gruß Dirk