CloseReason bleibt "UserClosing" und ändert sich nicht mehr?

  • VB.NET

Es gibt 11 Antworten in diesem Thema. Der letzte Beitrag () ist von ray.

    CloseReason bleibt "UserClosing" und ändert sich nicht mehr?

    Hallo,


    hab folgendes (altes) Problem.

    Form2 wird über .ShowDialog von Form1 aufgerufen. Der User hat in Form2 die Möglichkeit das Programm zu beenden (klick auf "X" des Fensters), daraufhin wird Form2_FormClosing abgefangen und CloseReason (UserClosing) entschieden was passiert. Falls es UserClosing ist, erscheint ein Dialog, ob wirklich beendet werden soll.

    Desweiteren gibt es die Möglichkeit über einen Button "Zurück" zurück zur Form1 zu kommen. Hierbei wird Form2.Hide() aufgerufen, sodass der Code nach .ShowDialog in Form1 weiterläuft (Form2 wird dort dann geschlossen und freigegeben).

    Wenn man nun Form2 öffnet und auf zurück klickt ist die CloseReason nach dem Aufruf von "Me.Hide()" "None". Soweit so gut.
    Wenn man in Form2 auf das "X" klickt, erscheint der Dialog "Wirklich beenden?", da die CloseReason "UserClosing" ist. Soweit so gut.
    Klickt man danach aber auf "Zurück", ist die CloseReason nicht "None", sondern auch "UserClosing". D.h. der Dialog erscheint ungewollt, obwohl FormClosing durch Me.Hide() ausgelöst wurde.

    Weiß jmd. warum das so ist und was man dagegen machen kann?


    Codeausschnitte:

    VB.NET-Quellcode

    1. ' ''''''''''''''''''''''''''''''''' FORM 1
    2. Public Class Form1
    3. Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnForm2.Click
    4. Dim boolExitProgramm As Boolean = False
    5. Dim form2 As Form2 = New Form2
    6. form2.ShowDialog()
    7. boolExitProgramm = form2.boolExitProgramm
    8. form2.Dispose()
    9. form2 = Nothing
    10. If boolExitProgramm = True Then
    11. Application.Exit()
    12. End If
    13. End Sub
    14. End Class
    16. ' ''''''''''''''''''''''''''''''''' FORM 2
    17. Public Class Form2
    18. Public boolExitProgramm As Boolean = False
    20. Private Sub btnZurück_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnZurück.Click
    21. Me.Hide()
    22. End Sub
    24. Private Sub Form2_FormClosing(ByVal sender As Object, ByVal e As System.Windows.Forms.FormClosingEventArgs) Handles Me.FormClosing
    25. If e.CloseReason = CloseReason.UserClosing Then
    26. Dim diaResult As DialogResult = MessageBox.Show("Wirklich Beenden?", "Beenden", MessageBoxButtons.YesNo, MessageBoxIcon.Question, MessageBoxDefaultButton.Button2)
    27. If diaResult = Windows.Forms.DialogResult.Yes Then
    28. e.Cancel = False
    29. boolExitProgramm = True
    30. Else
    31. e.Cancel = True
    32. boolExitProgramm = False
    33. End If
    34. End If
    35. End Sub
    36. End Class


    Danke und Grüße!

    bitte mach sowas nicht.

    wir müssen auch so ein programm verwenden - das klicksteweg, und dann fragt es dich, ob du es wirklich beenden willst.

    Das regt mich voll auf - ebensogut könnteman fragen, ob ich noch alle Tassen im Schrank habe, oder denkt der Programmierer, ich hätte wahllos in den Bildschirm geklickst, und nur zufällig das Schließen-X seines Programms erwischt?

    Ja gut, deine persönliche subjektive Meinung zu dem Programm jetzt mal außen vorgelassen - kannst du mir auch bei dem Problem explizit helfen?

    Was mir zu programmieren aufgetragen wird und wie du es gern hättest sind ja zwei verschiedene paar Schuhe ;). Du wirst mein Team-/Abteilungs-internes Programm höchstwarscheinlich nicht verwenden.

    naja, wäre doch auch ein nützlicher Tipp, dich anzuregen, mit deinem Team über dieses DeppenFeature nochmal zu reden. Sowas gehört ja auch zur AnwendungsEntwicklung.

    Aber du scheinst deinen blick auf deine konkrete Problemlösung zu fokussieren - bitte:

    VB.NET-Quellcode

    1. Public Class Form2
    2. Public boolExitProgramm As Boolean = False
    4. Private Sub btnZurück_Click(ByVal sender As Object, ByVal e As EventArgs) Handles btnZurück.Click
    5. RemoveHandler Me.FormClosing, AddressOf Form2_FormClosing
    6. Me.Hide()
    7. End Sub
    9. Private Sub Form2_FormClosing(ByVal sender As Object, ByVal e As FormClosingEventArgs)
    10. If e.CloseReason = CloseReason.UserClosing Then
    11. Dim diaResult As DialogResult = MessageBox.Show("Wirklich Beenden?", "Beenden", MessageBoxButtons.YesNo, MessageBoxIcon.Question, MessageBoxDefaultButton.Button2)
    12. If diaResult = Windows.Forms.DialogResult.Yes Then
    13. e.Cancel = False
    14. boolExitProgramm = True
    15. Else
    16. e.Cancel = True
    17. boolExitProgramm = False
    18. End If
    19. End If
    20. End Sub
    22. Private Sub Form2_Load(ByVal sender As Object, ByVal e As EventArgs) Handles MyBase.Load
    23. AddHandler Me.FormClosing, AddressOf Form2_FormClosing
    24. End Sub
    25. End Class

    Hier ist das Closing-Event flexibel abonniert, und kann daher vorm Hide-Befehl abgehängt werden.

    Ühaupt die Idee, von einem per .ShowDialog angezeigten Form aus das HauptForm zu schließen, ist gegen gängige Anwendungs-Design-Patterns.
    Das Hauptform zu schließen sollteman auffm Hauptform machen.
    Keinesfalls sollteman das wegklicken eines Dialoges mit zusätzlichem Code hinterlegen, der das HauptForm gleich mit-schließt.
    Das wäre unerwartetes Verhalten, und User lieben sowas nicht.

    (achja - ihr wollts janur unter euch usen - dann ists nicht soo tragisch)

    Zum Thema DeppenFeature. Auch wenns völlig irrelevant ist, mag ich dir recht geben, allerdings kennst du den Nutzerkreis des Programms nicht. Würdest du ihn kennen, wäre deine Meinung unter Umständen eine andere - in dem Programm sind etliche "Hilfestellungen" und Rückfragen dieser Art drin, einfach weil sonst zuviele ungewollte Missgeschicke passieren.
    Das Programm würde ich für mich niemals so schreiben, aber wie das nun mal so ist, wenn man für andere (sei es als Hobby oder beruflich) programmiert, wird man mit völlig unbekannten Anforderungen konfrontiert ;).

    Zwecks ShowDialog und Hauptform / komplettes Programm schliessen. Hab ich mir fast gedacht, allerdings war das die Quick'n'Dirty Variante - ich hab quasi zwei Formen, die den User ermächtigen das komplette Programm zu schließen (bei den restlichen ist das nicht so).

    Danke für deine Hilfe!

    ray schrieb:

    Würdest du ihn kennen, wäre deine Meinung unter Umständen eine andere

    Das glaubichnich. Meine Meinung schließt sich nur dem allgemeinen Stand von Anwendungs-Design an, dass man möglichst wenig unerwartetes Verhalten einbauen sollte, hat mit deinen Usern nix zu tun.
    Windows-Standard ist halt, dass das kleine X das aktuelle Form wegklickt, nicht die ganze anwendung.
    Und für einem User würdichhalt das genauso implementieren, und auch nicht nochmal nachfragen, ob er wirklich hat draufklicken wollen.

    ray schrieb:

    aber wie das nun mal so ist, wenn man für andere (sei es als Hobby oder beruflich) programmiert, wird man mit völlig unbekannten Anforderungen konfrontiert

    ja, das ist das tragische: Der User hat anspruch auf eine Anwendung ohne Überraschungen, aber mit ihren Forderungen überaschense einen immer wieder ;)

    ErfinderDesRades schrieb:

    Das glaubichnich. Meine Meinung schließt sich nur dem allgemeinen Stand von Anwendungs-Design an, dass man möglichst wenig unerwartetes Verhalten einbauen sollte, hat mit deinen Usern nix zu tun.
    Windows-Standard ist halt, dass das kleine X das aktuelle Form wegklickt, nicht die ganze anwendung.
    Und für einem User würdichhalt das genauso implementieren, und auch nicht nochmal nachfragen, ob er wirklich hat draufklicken wollen.


    Ich zieh da eher den Vergleich zu Programmen, bei denen (sobald eine "Änderung" stattfindet) eine Nachfrage auftaucht - ob wirklich beendet werden soll, wenn das "X" geklickt wird - bspw. Texteditoren. Die Kollegen brauchen, je nach Leistung und Effizienz mal gut ne halbe Stunde in dieser zweiten Form um alle notwendigen Daten einzutragen, Optionen einzustellen und so weiter. Nun hat mancher auch mal gerne noch 5 weitere Fenster offen und arbeitet an mehreren Baustellen (neben meinem Programm) gleichzeitig. Jetzt reicht ein einziger fehlgeleiteter Klick beim hastigen Schließen von mehreren Fenstern aus, um die ganze Arbeit in den Sand zu setzen - Vgl.: Du schreibst ein mehrseitiges Worddokument und schließt es ausversehen via "X"-Klick ohne Standard-Nachfrage ob du die Änderungen speichern willst. Dann gute Nacht :D.

    Sei es wie es ist, diese Nachfrage war eine Anforderung für das Programm, weswegen ich sie eingebaut habe. Das Philosophieren darüber praktiziere ich erst jetzt mit dir in diesem Thread ;).

    jo, auch als Philosoph kannman nicht aus seiner Haut ;)

    ray schrieb:

    Ich zieh da eher den Vergleich zu Programmen, bei denen (sobald eine "Änderung" stattfindet) eine Nachfrage auftaucht - ob wirklich beendet werden soll, wenn das "X" geklickt wird - bspw. Texteditoren.

    TextEditoren machen etwas anderes.
    Die Fragen nicht, ob beendet werden soll, sondern, ob Änderungen gespeichert werden sollen - falls welche da sind.
    Die "Speichern?" - Nachfrage ist wiederum Standard-Verhalten, was jeder so kennt.

    Deswegen ists ja schlechtes AnwendungsDesign, wenn da auf einmal nicht mehr gefragt wird: "Speichern?", sondern "wirklich schließen?" (und gemeint ist auch noch die ganze Anwendung, nichtnur der aktuelle Dialog).

    ErfinderDesRades schrieb:

    Die Fragen nicht, ob beendet werden soll, sondern, ob Änderungen gespeichert werden sollen - falls welche da sind.
    Die "Speichern?" - Nachfrage ist wiederum Standard-Verhalten, was jeder so kennt.

    Genau.
    Mach Dir ein Flag, ob Daten geändert wurden, die gespeichert werden sollen, und wenn dieses Flag gesetzt ist, frag beim Beenden, ob gespeichert werden soll.
    MessageBox mit YesNoCancel:
    Yes - Speichern und beenden
    No - Nicht speichern und beenden
    Cancel - nicht beenden.
    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!

    Ähhh... nein?

    Nochmal, das ist meine Vorgabe, nicht meine persönliche Vorliebe und ich hab lediglich ein wenig versucht mögliche Erklärungen zwecks dieser Vorgabe zu finden. Das mag für euch weiterhin inakzeptabel sein, bleibt aber nach wie vor irrelevant für mein Programm ;).

    ich denke, das haben wir schon verstanden, und ich hab deine Vorgabe ja bereits mit post#4 bedient.
    Trotzdem gehörts auch wesentlich zu gutem Programmierstil, dass man auch imstande und willens ist, Mängel in Vorgaben zu diskutieren.
    Man kann ja nicht nur Code verbessern, sondern auch Vorgaben.
    Und an einer verbesserten Vorgabe profitiert eine Anwendung viel mehr als an noch so dollem Code. Letztlich ist Code immer so schlecht wie die Vorgabe, die er umsetzt.

    Du kannst davon ausgehen, dass ich bei jeder Vorgabe, die meiner Ansicht widerspricht, selbiges äußere - wenns dann aber dennoch heißt "Mach das so", mach ich das auch so. Es ist eben was anderes ob man für sich selbst oder für andere aus Spass was programmiert und da freie Entscheidungsgewalt hat oder ob es im Sinne eines Arbeitsauftrags geschieht.

    Ich würds auch nicht 10 mal wiederholen, wenn nach dem ersten Mal diesbezüglich nichts mehr gekommen wäre. Aber mir mehrmals anzuhören, wie ichs machen soll, ist hinfällig. Dann ist kein Beitrag genauso viel Wert wie dieser, weil es nunmal nicht anders geht. Mein vorheriger Beitrag war im Übrigen an RodFromGermany gerichtet, nicht an dich (falls du dich da auch angesprochen gefühlt hast).
    Wie du gesagt hast, war deine Antwort in #4 genau richtig, deswegen dafür auch das Danke und deswegen ist das Thema bereits als erledigt markiert.

    Grüße