Abbrechen eines Dialogs

  • VB.NET

Es gibt 27 Antworten in diesem Thema. Der letzte Beitrag () ist von Peter329.

    Abbrechen eines Dialogs

    Hallo,

    meine Start Form lautetfrmMain.

    Von dieser Form aus starte ich modal eine zweite Form frmDisplay.

    Mit Me.Close() komme ich nach frmMain zurück.

    Ich würde aber gern den Dialog komplett beenden. Ich hab das mit einem Schalter versucht:

    VB.NET-Quellcode

    1. Public blnExit As Boolean


    Der wird in frmDisplay auf TRUE gesetzt:

    VB.NET-Quellcode

    1. frmMain.blnExit = True


    und dann in frmMain abgefragt:

    VB.NET-Quellcode

    1. Private Sub ShowDisplay()
    3. strPathName = txtPath.Text
    4. frmDisplay.ShowDialog()
    5. If blnExit = True Then Me.Close()
    7. End Sub


    Das klappt aber nicht ... nach dem Me.Close() läuft das Programm in der Prozedur die ShowDisplay() aufruft noch munter weiter!

    Was mache ich falsch?

    Brauche ich überhaupt einen Schalter ... oder gibt es eine Anweisung, die bereits in der gerufenen frmDisplay das Programm komplett und sauber beendet.

    Gruß
    Peter


    Edit by Manschula: Die Farbe Rot ist der Moderation vorbehalten --> Kolorierung entfernt

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

    Schau dir als erstes das mal an: [VB 2010] Instanziierung von Forms und Aufruf von Dialogen
    Ein Dialog sollte das Programm nicht komplett beenden, das ist imo Job der Hauptform, die auch den Dialog aufgerufen hat. Vllt hilfreich: DialogResult

    lg

    @programmer71
    von irgendwo (in den Untiefen des Programms) zu sagen "Selbstmord" ist nicht sehr schön. Ein Dialog gehört ja quasi einer Hauptform. Es ist imo Job der Hauptform das Programm zu Beenden und nicht der eines xbeliebigen Dialogs. Die Dialoge sollten also der Hauptform mitteilen was passiert (=> DialogResult, evtl auch Properties des Dialoges selbst - um an diese zu kommen muss man den oben genannten Link aber mal lesen^^) und diese entscheidet dann was passiert.

    Ich habe jetzt den Rat von FreakJNS befolgt und die frmDisplay mit dlg.ShowDialog() aufgerufen:

    VB.NET-Quellcode

    1. Public Class frmMain
    3. Public blnExit As Boolean
    5. Private Sub cmdNew_Click(sender As System.Object, e As System.EventArgs) Handles cmdNew.Click
    7. blnExit = False
    8. Call ShowDisplay()
    9. Call GetList()
    11. End Sub
    13. Private Sub ShowDisplay()
    15. strPathName = txtPath.Text
    16. Dim dlg As New frmDisplay
    17. dlg.ShowDialog()
    18. If blnExit = True Then Me.Close()
    20. End Sub
    22. Private Sub GetList()
    24. Dim strFileList() As String
    26. 'Get entries in directory
    27. strFileList = Directory.GetFileSystemEntries(txtPath.Text)


    Die gerufene From frmDisplay beende ich mit cmdExit

    VB.NET-Quellcode

    1. Private Sub cmdExit_Click(sender As System.Object, e As System.EventArgs) Handles cmdExit.Click
    3. frmMain.blnExit = True
    4. Me.Close()
    5. MsgBox("cmdExit: How do we get here?")
    7. End Sub


    Nach dem Me.Close() rennt die Programm weiter, d.h. "How do we get here?" wird angezeigt.

    Danach erfolgt der Rücksprung in die rufende Form.

    blnExit enthält TRUE. Die Anweisung Me.Close() in

    VB.NET-Quellcode

    1. If blnExit = True Then Me.Close()


    wird ausgeführt.

    Danach springt das Programm in die Routine cmdNew_Click zurück und macht mit der Anweisung

    VB.NET-Quellcode

    1. Call GetList()


    weiter. Und diese Routine scheitert dann in der Anweisung

    VB.NET-Quellcode

    1. strFileList = Directory.GetFileSystemEntries(txtPath.Text)


    weil die Variable txtPath.Text = "" ist!

    Beim Aufruf von von ShowDisplay() war diese Variable aber befüllt und sie wurde auch nirgendwo verändert.

    Ich verstehe das nicht ... wieso läuft die Routine denn nach Me.Close() eisern weiter?

    Übrigens auch wenn ich in der gerufenenen frmDisplay ein "Application.Exit()" kodiere, ändert an diesem Verhalten nichts. Die nachfolgende Msgbox wird angezeigt!

    Was mache ich denn nur falsch?

    Gruß
    Peter

    Call ist Uralt, das kannste vergessen. Ich hab hier mal ein Beispiel, das Dialogresult kannst du bei Buttons auf deinem Dialog im Property-Fenster einstellen.

    VB.NET-Quellcode

    1. Private Sub btnShowDlg_Click(sender As System.Object, e As System.EventArgs) Handles btnShowDlg.Click
    2. Using DlgMain As New frmDlg
    3. Select Case DlgMain.ShowDialog
    4. Case Windows.Forms.DialogResult.OK
    5. MessageBox.Show("Ok")
    6. Case Windows.Forms.DialogResult.Cancel
    7. MessageBox.Show("Exit")
    8. Application.Exit()
    9. End Select
    10. End Using
    11. End Sub

    Peter329 schrieb:

    Ich verstehe das nicht ... wieso läuft die Routine denn nach Me.Close() eisern weiter?
    na, weils halt in der nächsten Zeile weiter geht - so ist das beim programmieren ;)

    probierma

    VB.NET-Quellcode

    1. Private Sub cmdExit_Click(sender As System.Object, e As System.EventArgs) Handles cmdExit.Click
    2. frmMain.blnExit = True
    3. Me.Close()
    4. Exit Sub
    5. MsgBox("cmdExit: How do we get here?")
    6. End Sub
    Und Bitte! Verzichte auf Leerzeilen ohne Sinn - das macht dein Code ein Stück lesbarer.

    @ErfinderDesRades
    Wieso behandeltst du es denn nicht mit dem Dialogresult ? Eine extra Flag zu setzen ist doch absolut unnötig. Abgesehen davon ist MsgBox & Exit Sub nicht ganz supi. Bei meinem Beispiel hab ich nicht eine Zeile Code im Dialog, läuft schön per DialogResult ^^

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

    Danke ... das klappt jetzt prima.

    Nun möchte ich gern das Exit Command bedingt ausführen. Folgendes Coding habe ich versucht:

    VB.NET-Quellcode

    1. Private Sub cmdExit_Click(sender As System.Object, e As System.EventArgs) Handles cmdExit.Click
    2. 'Check unsaved changes
    3. If MsgBox("File has been changed, do you want to quit ?",
    4. vbYesNo,
    5. "Prompt Save") = vbNo Then
    6. 'Ausschalten der CANCEL Dialog Eigenschaft
    7. cmdExit.DialogResult = Windows.Forms.DialogResult.None
    8. End If
    9. End Sub


    Das klappt aber nicht ... ich lande in der rufenden Form, egal was ich eingebe. Offensichtlich wird die Eigenschaft cmdExit.DialogResult schon am Beginn der Prozedur festgelegt.

    Wie muß man denn sowas kodieren?

    Zitat: "Call ist uralt" ...

    Wie sollte ich denn sonst eine Subroutine wie "GetList" aufrufen?

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

    Gonger96 schrieb:

    Setz das DialogResult auf Cancel und prüf es dann in der Hauptform wie in meinem Beispiel.


    Wenn es noch ungesicherte Änderungen gibt, will ich ja gerade NICHT in die Hauptform zurückspringen, weil diese sonst verloren gehen!

    Am DialogResult sollte man üblicherweise codeseitig ühaupt nicht rumfummeln.
    Das DialogResult sagt aus, ob der User eine Eingabe gemacht hat oder nicht- gugge DialogResultSample

    Welche Eingabe gemacht wurde, und wie darauf reagieren (ob Prg schließen oder was) - das steht auf einem anneren Blatt.

    Guck dir mal das Bild, dass ich gepostet hab, an. Du weißt einem Button ein DialogResult zu und mehr musst du im Dialog garnet machen. Alles andere behandelst du in der Hauptform. Ich machs gerne in einem Using-Block da wird das Object direkt danach verworfen. Eignet sich für modale Dialoge wie deiner.

    Mhh, das verstehe ich jetzt nicht ganz.

    Wenn der Anwender "Do you want to quit" nicht bestätigt, dann soll er weiterarbeiten können. D.h. er soll in der Form frmDisplay bleiben! Ob jetzt speichert oder erst später, das ist seine Sache. Die rufende Form frmMain jedenfalls will er zu diesem Zeitpunkt nicht präsentiert bekommen.

    Ich hoffe, ich habe mein Anliegen verständlich machen können.

    Gruß
    Peter

    Ein modaler Dialog ist sinngemäß so: Programm ruft Dialog um Nutzer was zu fragen -> Nutzer erhält Frage -> solange er nicht antwortet kann er auch nichts anderes machen -> er antwortet und klickt z.B. Ok -> Programm bekommt Antwort "Ok" reagiert darauf -> Nutzer kann weiter arbeiten. Ein nicht-modaler-Dialog macht es möglich, dass der Nutzer während des Dialogs noch zugriff auf die Parentform hat.

    Peter329 schrieb:

    Wenn der Anwender "Do you want to quit" nicht bestätigt, dann soll er weiterarbeiten können. D.h. er soll in der Form frmDisplay bleiben! Ob jetzt speichert oder erst später, das ist seine Sache. Die rufende Form frmMain jedenfalls will er zu diesem Zeitpunkt nicht präsentiert bekommen.
    Dassis eine ziemlich komische Anwendungslogik.
    Offensichtlich macht cmdExit bei dir noch iwas anneres, und ist also nicht wirklich ein Cancel-Button.
    Oder der ganze Dialog macht mehr, als ein normaler modaler Dialog.
    Ein normaler modaler Dialog sollte nur Eingaben entgegen-nehmen, aber noch nix verarbeiten (wie etwa Files ändern oder sowas).
    Also ich blick nicht recht durch, was du da treibst - kompliziertere Logiken musstehalt selbst proggen - vlt. ists in dem Fall sogar angemessen, am DialogResult rumzufummeln.

    Dein Button heißt ja auch cmdExit, also Schließen-Button, und "Schließen" ist ein uneindeutiger Vorgang, weil man kann mit Änderungen speichern schließen oder ohne.
    Überleg nochmal, ob ein Schließen-Button ühaupt optimale Benutzerführung darstellt, und ob nicht besser ein Button-Pärchen "Übernehmen" - "Abbrechen" eine klarere Funktionalität aussagen würde.

    ErfinderDesRades schrieb:

    Dassis eine ziemlich komische Anwendungslogik.


    Also ich denke, das ist eine ziemlich naheliegende und intuitive Anwendungslogik.

    Im frmMain erhält der Anwender eine Übersicht über alle verfügbaren Files, die bearbeitet werden können.

    Er kann entweder einen existierenden File durch Doppelklick auswählen. Oder er kann mit dem Button "Open New" einen neuen File eröffnen. Oder er kann mit dem Button "Exit" die Anwendung verlassen.

    Danach wird in der frmDisplay der ausgewählte oder neue File modal angezeigt, (denn eine weitere Auswahl ist jetzt nicht erlaubt). Dieser File kann mit verschiedenen Buttons zeilenweise bearbeitet werden. Mit "Save", "Save As" können die Änderungen am File gespeichert werden. Mit "Return" kann man zur Auswahl in frmMain zurückkehren und ggf. einen weiteren File bearbeiten. Mit "Exit" kann man die Anwendung verlassen. Natürlich soll vor dem Return / Exit geprüft werden, ob es ggf. ungesicherte Änderungen gibt und in diesem Fall, kann er Return / Exit abbrechen.

    Also, ich verstehe nicht viel von Visual Basic. Aber der Design der Anwendung scheint mir nicht ganz so abwegig zu sein. Das ist jedenfalls das, was meine Anwender von der Anwendung erwarten.

    Irgendwelche Ideen, wie man das jetzt realisieren kann?

    Gruß
    Peter
    Bilder

    • frmMain.jpg

      102,47 kB, 676×633, 94 mal angesehen

    • frmDisplay.jpg

      120,02 kB, 850×628, 95 mal angesehen

    Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von „Peter329“ ()

Facebook
Telefonspende