nicht angemeldet
Der Martin
Der Martin
Richard Rüfenacht
Der Martin
Richard Rüfenacht
Der Martin
Der Martin
Richard Rüfenacht
Hallo!
eine kleine Frage: ich kann/will nichts dazu finden wie ich die Abfrage(wollen sie das Programm wirklich beenden?-ja-nein) auch für das kleine x in der rechten oberen Ecke hinzufügen kann.
Aus dem Menu heraus ist ja kein Problem das abzufangen, finde aber bei den Form-Eigenschaften auch nichts dazu ... (Visual Studio 2005)
Hi,
eine kleine Frage: ich kann/will nichts dazu finden wie ich die Abfrage(wollen sie das Programm wirklich beenden?-ja-nein) auch für das kleine x in der rechten oberen Ecke hinzufügen kann.
ich weiß nicht, wo dein Problem liegt, weil ich deinen Programmier-Ansatz nicht kenne. Aber der "übliche" Weg ist es, in der Fensterprozedur des Programm-Hauptfensters die Windows-Botschaft WM_DESTROY abzufangen. Gibt man einen Wert ungleich 0 zurück, wird der Befehl "Programm beenden" ignoriert.
Natürlich kann man das Programm dennoch beenden, indem man den Prozess "mit Gewalt" abschießt. Das geht immer und lässt sich programmtechnisch nicht verhindern.
Aus dem Menu heraus ist ja kein Problem das abzufangen, finde aber bei den Form-Eigenschaften auch nichts dazu ... (Visual Studio 2005)
Auweia. Das deutet eher auf Klickibunti-Programmierung hin. Wie es _damit_ aussieht, kann ich nicht sagen.
So long,
Martin
Hi,
eine kleine Frage: ich kann/will nichts dazu finden wie ich die Abfrage(wollen sie das Programm wirklich beenden?-ja-nein) auch für das kleine x in der rechten oberen Ecke hinzufügen kann.
ich weiß nicht, wo dein Problem liegt, weil ich deinen Programmier-Ansatz nicht kenne. Aber der "übliche" Weg ist es, in der Fensterprozedur des Programm-Hauptfensters die Windows-Botschaft WM_DESTROY abzufangen. Gibt man einen Wert ungleich 0 zurück, wird der Befehl "Programm beenden" ignoriert.
danke das werde ich gleich probieren
Natürlich kann man das Programm dennoch beenden, indem man den Prozess "mit Gewalt" abschießt. Das geht immer und lässt sich programmtechnisch nicht verhindern.
das habe ich auch nicht vor!
Aus dem Menu heraus ist ja kein Problem das abzufangen, finde aber bei den Form-Eigenschaften auch nichts dazu ... (Visual Studio 2005)
Auweia. Das deutet eher auf Klickibunti-Programmierung hin. Wie es _damit_ aussieht, kann ich nicht sagen.
klickibunti weil ich ne IDE verwende? - am buntesten an der Oberfläche ist immernoch bloß das Icon das VS standardmäßig einsetzt
So long,
Martin
n'Abend Roebert,
ist das so richtig, mit "oe"? strange ...
[WM_DESTROY abfangen]
danke das werde ich gleich probieren
Ich bin gespannt, ob dir das weiterhilft.
klickibunti weil ich ne IDE verwende?
Nein, die Verwendung einer IDE ist ja nichts Verwerfliches oder Lächerliches. Ich meinte Klickibunti deshalb, weil MS Wuschel-Studio einen dazu ermuntert, das Programm in weiten Teilen "aus Bausteinen zusammenzuklicken". Damit erhält man zwar rasch funktionstüchtige und vorzeigbare Ergebnisse, aber mit "Programmierung" nach meinem Verständnis hat das nicht mehr viel zu tun.
Gut, ich weiß wohl, dass man mit MSVS auf auf Programmcode-Ebene "richtig" programmieren kann, doch das tritt immer mehr in den Hintergrund, und ich finde das schade. Denn jede Hilfestellung ist, wenn man sie in Anspruch nimmt, gleichzeitig eine Einschränkung der Möglichkeiten. Man ist mit keinem anderen Approach so flexibel und hat so viele Möglichkeiten, wie bei der direkten Programmierung auf API-Ebene.
Und deswegen rede ich manchmal etwas respektlos von den Klickibunti-Tools, mit denen man sich seine Applikation (oder Webseite, anderes Beispiel) graphisch und "intuitiv" zusammenbasteln kann. Das ist eher "Rapid Application Construction" als Programmierung - abgesehen davon, dass ich die meisten IDEs und Bibliotheken, die dazu verwendet werden, überhaupt nicht intuitiv finde. Ich arbeite bevorzugt auf Quellcode-Ebene und bin da meistens fast genauso schnell.
- am buntesten an der Oberfläche ist immernoch bloß das Icon das VS standardmäßig einsetzt
;-)
Schönen Abend noch,
Martin
Hallo!
Find ich ziemlich cool, dass dieses Thema angeschnitten wurde. Ich habe mir mal C#.NET angeschaut und bin dabei auch darauf gestoßen, dass man das Aussehen seiner Windows-Applikation zusammenklicken kann, und das Programm den Rest (den Code für das Aussehen) erledigt.
Kann mir dazu mal jemand sagen, wie er das findet? Ich bin mir nicht so richtig sicher, wie ich das finden soll :-/
Einerseits ist es cool, weil es IMO sehr viel Arbeit (=Zeit) einspart (im Vergleich zu Java [wenn man das vergleichen kann]). Andererseits arbeite ich auch lieber nur mit Quelltext.
Warscheinlich ist es geschmackssache, aber trotzdem würde mich interessieren, wie ihr das findet? Seht ihr eher Vor- oder Nachteile darin?
ciao, ww
n'Abend!
Find ich ziemlich cool, dass dieses Thema angeschnitten wurde.
Cool? Ach was. ;-)
Kann mir dazu mal jemand sagen, wie er das findet? Ich bin mir nicht so richtig sicher, wie ich das finden soll :-/
Einerseits ist es cool, weil es IMO sehr viel Arbeit (=Zeit) einspart (im Vergleich zu Java [wenn man das vergleichen kann]). Andererseits arbeite ich auch lieber nur mit Quelltext.
Es hängt, wie so oft, von mehreren Gesichtspunkten ab. Ähnlich wie mit den HTML-Editoren im WYSIWYG-Stil ist auch bei den graphisch orientierten IDEs der "Visual"-Serie keine einfache, klare Antwort möglich.
Ich habe in der Firma mal eine Weile mit MS Visual C++ arbeiten müssen, und bin schier daran verzweifelt. Nach ein paar Wochen hatte ich die Faxen dicke und habe meinen Chef gebeten, einen C-Compiler nach meinem Geschmack anschaffen und installieren zu dürfen. Nach kurzer Überredung habe ich dann Borland C++ 5.01 bestellt, installiert - und nach wenigen Tagen hatte ich ein Grundgerüst meiner Applikation fertig, ohne dass ich dauernd duch die IDE behindert wurde. Der MS-Compiler hat mir dagegen alle naselang irgendwas in den Quellcode geklatscht, was ich da überhaupt nicht haben wollte. Ich erinnere mich noch konkret, dass andauernd ein unerwünschtes #include "stdafx.h" auftauchte.
Warscheinlich ist es geschmackssache, aber trotzdem würde mich interessieren, wie ihr das findet? Seht ihr eher Vor- oder Nachteile darin?
Zumindest die IDE von MSVC hat alles, was nicht exakt dem Programmierkonzept von MS mit Verwendung der MFC-Bibliothek entsprach, irgendwie boykottiert.
Und ganz allgemein gesprochen: Ich arbeite am liebsten direkt auf Quellcode-Ebene, da bin ich am flexibelsten; ich begrüße es, wenn mir die IDE Hilfestellungen gibt, aber sie darf mir nichts aufzwängen. Dann wird die Hilfe nämlich zur Behinderung.
So long,
Martin
Hallo!
Find ich ziemlich cool, dass dieses Thema angeschnitten wurde.
Cool? Ach was. ;-)
Jap. Hab mir dazu schon Gedanken gemacht ;-)
Ich erinnere mich noch konkret, dass andauernd ein unerwünschtes #include "stdafx.h" auftauchte.
Soetwas habe ich im C# Quelltext nicht entdeckt.
Zumindest die IDE von MSVC hat alles, was nicht exakt dem Programmierkonzept von MS mit Verwendung der MFC-Bibliothek entsprach, irgendwie boykottiert.
Soweit bin ich noch nicht. Werde ich aber mal im Auge behalten, ob das mir bei C#.NET auch passiert.
Und ganz allgemein gesprochen: Ich arbeite am liebsten direkt auf Quellcode-Ebene, da bin ich am flexibelsten; ich begrüße es, wenn mir die IDE Hilfestellungen gibt, aber sie darf mir nichts aufzwängen. Dann wird die Hilfe nämlich zur Behinderung.
Ich arbeite auch lieber auf Quellcode-Ebene. Allerdings ist das "Basteln" einer GUI (unter Java) zeit- und nervraubend. Wie man ein GUI unter C#.NET entwirft, ohne es zusammenzuklicken, weiß ich noch nicht. Aber ich stelle es mir ähnlich kompliziert vor.
Auf jeden Fall danke für deine Antwort :) Sollten weitere Fragen kommen, melde ich mich.
ciao, ww
Hi, hallo,
wenn du dir C# aka CSharp angeschaut hast, dann hast du .Net gesehen. C# ist einfach nur eine "Syntax" um in und mit .net arbeiten zu können.
Visual Studio und der grafische WinForms Designer ist einfach "Rapid Application Development", i.e. schnell was zusammenklickern und es funktioniert. Z.b. Einfache Time Tracking Anwendungen (siehe SelfForum Archiv) sind damit in ca. 4 Stunden zu machen.
Zum Thema "wie jemand was findet" ... da fällt mir immer wieder der Witz ein:
Ober: Wie fanden Sie das Steak? (auf CH++ heisst es dann einfach: isch guet gsi?)
Gast: Ganz einfach, ich hob das Salatblatt an und da lag es.
Hat schon einen ellenlangen Bart das Teil :)
Wenn du eine kleine Weile (so wie ich, ca. 4,5 Jahre) damit (ich meine .net) gebastelt hast, wirst du feststellen, dass das schöne Zusammenklicken von ein paar GUI-Komponenten wie Grids oder Listboxes nicht automatisch zu einer "guten" Windowsanwendung führt. Stattdessen sollte man lieber auf Frameworks und Patterns setzen, wie MVC. Und dann arbeitet man wieder viel mit dem reinen Quellcode ohne Designerunterstützung. Lediglich die Unterelemente, die du dann im MVC (als Beispiel) Pattern wiederverwenden kannst (i.e. User Controls) kannst du dann wieder hübsch zusammenklicken. Das Erstellen des Layouts für ein Fenster gestaltet sich durch den grafischen Designer einfacher, da du sofort das Quasi-Ergebnis siehst.
Neue(ste) Generation geht noch einen Schritt weiter: Man schreibt als UI Designer nur noch Markup (XAML) um das grafische Interface zu entwickeln und als richtiger Softwareentwickler nur noch reinen Quellcode um die Funktionen hinter Buttonklicks zu gewährleisten (e.g. Datenabruf und -bindung).
Visual Studio 2003/2005/2008 nimmt dem Entwickler momentan einfach viel Routinearbeit oder besser gesagt "Tipparbeit" ab. Zum Beispiel: Doppelklick auf einen Event im Eigenschaftenfenster eines Formulars/Fensters oder eines Buttons/List/Grid/... erzeugt die Eventhandlermethode und die Registrierung der Methode auf das Event und spart damit etwa 2 Min Tipparbeit. Was dann in der Eventhandlermethode passieren soll musst du aber wieder selbst implementieren.
Nur allein .Net, C# und Visual Studio machen noch keine vernünftige Anwendung. In 70% der Fehlschläge liegt es an der fehlenden Rolle des UI Designers, einer Person, die weiss, wie ein (grafisches) User Interface auszusehen hat.
Ich hoffe, ich habe dir ein paar Aspekte näherbringen können. :)
Selber bin ich ja primär im Backend-Bereich und weniger im Frontend-Bereich tätig. Aber vermeiden lässt sich letzteres nicht wirklich. :)
Ciao, Frank
Hallo!
Visual Studio und der grafische WinForms Designer ist einfach "Rapid Application Development", i.e. schnell was zusammenklickern und es funktioniert. Z.b. Einfache Time Tracking Anwendungen (siehe SelfForum Archiv) sind damit in ca. 4 Stunden zu machen.
Ich schau mich heute Mittag mal dazu im SELF-Archiv dazu um.
Wenn du eine kleine Weile (so wie ich, ca. 4,5 Jahre) damit (ich meine .net) gebastelt hast, wirst du feststellen, dass das schöne Zusammenklicken von ein paar GUI-Komponenten wie Grids oder Listboxes nicht automatisch zu einer "guten" Windowsanwendung führt.
Genau das wollte ich wissen. Vereinfacht/verbessert soetwas das Schreiben von Anwendungen...? Aber scheinbar hat es eher Nachteile.
Stattdessen sollte man lieber auf Frameworks und Patterns setzen, wie MVC.
Das ist interessant. Danach schaue ich heute auch nochmal. Mal schauen, was ich bei Wikipedia und Google dazu finde. Vielen Dank für den Tip.
Visual Studio 2003/2005/2008 nimmt dem Entwickler momentan einfach viel Routinearbeit oder besser gesagt "Tipparbeit" ab. Zum Beispiel: Doppelklick auf einen Event im Eigenschaftenfenster eines Formulars/Fensters oder eines Buttons/List/Grid/... erzeugt die Eventhandlermethode und die Registrierung der Methode auf das Event und spart damit etwa 2 Min Tipparbeit. Was dann in der Eventhandlermethode passieren soll musst du aber wieder selbst implementieren.
Am Anfang ist das aber kein Vorteil. Es ist schwerer das ganze zu lernen, wenn die IDE soviel Arbeit abnimmt.
Ich hoffe, ich habe dir ein paar Aspekte näherbringen können. :)
Vorallem der mit Frameworks und Patterns ist sehr interessant und ich werde heute mal bei Google und in meinen Büchern suchen, was ich dazu finde.
Selber bin ich ja primär im Backend-Bereich und weniger im Frontend-Bereich tätig. Aber vermeiden lässt sich letzteres nicht wirklich. :)
Ich bin gespannt, in welchen Bereich ich irgendwann kommen werde :)
Aber jetzt gehe ich erstmal ins Bett. Warscheinlich sehe ich sonst bald so aus: -.- ;) Vielen Dank für die Antwort. Höchstwarscheinlich muss ich nochmal zum Thema Frameworks/Patterns nachfragen, aber das kommt später :)
ciao, ww
Hi,
zum Stichwort "Patterns":
Am Anfang ist das aber kein Vorteil. Es ist schwerer das ganze zu lernen, wenn die IDE soviel Arbeit abnimmt.
Doch, imho schon. Du kannst dir am automatisch generierten Code ein Beispiel holen, was Events und Eventhandler sind. Wenn du das Konzept dessen verstanden ... hatschi ... hast, dann bist du froh, dass dir die Tipparbeit abgenommen wird.
Vereinfacht/verbessert soetwas das Schreiben von Anwendungen...?
Macht es imho etwas schneller ... "Rapid" Application Development. Wenn du dir mal all die tollen Quickstart Beispiele von Microsoft anschaust, wirst du schnell feststellen, es gibt recht kurzfristig einen grossen Sprung in Sachen Komplexität, will heissen: einfache Anwendungen wie heimische Medienbibliothek oder Vereinsmitgliederverwaltung (die einen sehr begrenzten Satz an Use Cases haben) sind mit den Bordmitteln und dem grafischen Formulardesigner wahnsinnig schnell hinzubekommen, eben "Rapid".
Ich bin gespannt, in welchen Bereich ich irgendwann kommen werde :)
Kommt auch auf deine Begabung an, wenn du mehr der Designer bist und Verständnis für "Usability" hast, dann sicher Frontend, ergo spezialisiere dich auf Technologien die primär mit der Usability zu tun haben (z.b. WPF, Silverlight). Wenn dich hingegen das Zusammenspiel inhomogener Systeme begeistert, wie man Systeme miteinander integrieren kann, dann solltest du dich (meine Empfehlung) auf den Backend-Bereich spezialisieren: SOA, Messaging, WCF und so weiter.
Okay, nun aber endgültig "guets nächtli" ...
Frank
Hallo,
Ich bin eigentlich eher im Bereich Webentwicklung angesiedelt. Von daher kenn ich auch nur eins: Ultraedit (ohne jetzt Werbung machen zu wollen)
also auf Editor-Ebene selber Code zu schreiben, ziehe ich da jedem noch so guten WYSIWYG-Web-Editor vor - ich glaube, Gründe dafür brauche ich keine zu nennen, aber vorallem wenn der Code/HTML-Dummy dann noch in ein CMS gehoben werden soll, geht das wesentlich flüssiger wenn man den Code selber geschrieben hat.
Wenn ich jetzt aber zwischendurch mal eine Anwendung(FensterProgrämmli) schreibe, finde ich es gut, das mir die IDE dort einiges abnehmen kann. z.B. die Menuerstellung ist doch so recht bequem, wenn ich mir den erstellten Code anschaue, sehe ich das das mit per Hand coden auf jeden Fall länger dauert
Hi,
für die Entwicklung von Websites (ja, das tue ich auch ab und an privaterweise) verwende ich aktuell nur noch Microsoft Expression Web. Bevor fragen aufkommen, es ist der Quasi-Nachfolger von Microsoft Frontpage. Leider hat es noch ein paar kleine Macken :(
Ciao, Frank
Hi,
dein Hauptformular hat einen Event (OnClosing), den du abfangen kannst, indem du eine Eventhandlermethode deklarierst. Am einfachste
private sub Form1_OnClosing(object as sender ,e as ClosingEventArgs)
handles Form1.OnClosing
throw new NotImplementedException("Not yet done")
end sub
e hat dann eine Eigenschaft "Cancel", die man auf true setzen kann.
Dazu implementierst du innerhalb der Mehtode einfach ein
dr as DialogResult = Messagebox.Show("Wirklich beenden?", ....)
um eine dialog-Messagebox anzuzeigen.
je nach DialogResult (DialogResult.Cancel oder DialogResult.Ok) kannst du dann e.Cancel auf true oder false setzen und damit das shcliessen des Fensters rückgängig machen.
Wenn es das Hauptfesnter der Anwendung ist, dann würde auch ein Application.Exit() diesen Event auslösen.
Wie du siehst, es ist wirklich ziemlich trivial, solcheine Nag-Funktion einzubauen.
Grüessli, Frank
P.S. Man möge meine Rechtschreib- und Grammatikfehler verzeihen, es isch ifach z'vil Appezellä gsi.
Hallo Frank!
P.S. Man möge meine Rechtschreib- und Grammatikfehler verzeihen, es isch ifach z'vil Appezellä gsi.
Du machst ja beachliche Fortschritt in CH++. Ob die Schwaben noch verstehen, worum es da geht? ;-)
Meld dich doch mal per Mail bei mir. Ich werde wohl demnächst in Pfäffikä (SZ versteht sich) durchfahren.
Hast dir ja richtig Mühe gegeben mit der Erklärung, ich hätte das alles erst mühsam nachschlagen müssen.
Beste Grüsse
Richard
Hi,
CH++ ist gut. Das muss ich mir merken.
Ich meld mich die Tage mal bei deiner email adresse und geb dir mal meine Natel-Nummer (mis Natel-Nümmerli ;)) durch, dass wir uns mal einen Termin verabreden können.
Ciao, Frank
Hallo Roebert!
eine kleine Frage: ich kann/will nichts dazu finden wie ich die Abfrage(wollen sie das Programm wirklich beenden?-ja-nein) auch für das kleine x in der rechten oberen Ecke hinzufügen kann.
Du solltest dich fragen, ob es sinnvoll ist, die gewohnte Funktionsweise eines Fensters zu ändern, mit welcher Bastelei auch immer.
Wenn du verhindern willst, dass die Anwendung mit Klick auf das x geschlossen werden kann, lass es doch einfach weg. Dann kommt der User auch nicht in Versuchung, die Anwendung auf diesem Wege zu beenden.
Beste Grüsse
Richard
Hallo Richard,
eine kleine Frage: ich kann/will nichts dazu finden wie ich die Abfrage(wollen sie das Programm wirklich beenden?-ja-nein) auch für das kleine x in der rechten oberen Ecke hinzufügen kann.
Du solltest dich fragen, ob es sinnvoll ist, die gewohnte Funktionsweise eines Fensters zu ändern, mit welcher Bastelei auch immer.
deine Einwände in Ehren, aber das, Roebert machen will, ist eine absolut übliche Funktion. Jedes Feld- Wald- und Wiesenprogramm hat diese Rückfrage vor dem Beenden integriert.
Wenn du verhindern willst, dass die Anwendung mit Klick auf das x geschlossen werden kann, lass es doch einfach weg.
Das ist nicht so einfach. Denn das Schließfeld ist integraler Bestandteil eines Fensters im Windows-GUI; es erfordert sehr viel Aufwand, ein Fenster ohne dieses Schließfeld zu konstruieren. Bestenfalls kann man es inaktiv setzen, so dass es nur noch grau erscheint. Und selbst das ist nicht trivial.
SO long,
Martin
Hallo Martin!
Das ist nicht so einfach. Denn das Schließfeld ist integraler Bestandteil eines Fensters im Windows-GUI; es erfordert sehr viel Aufwand, ein Fenster ohne dieses Schließfeld zu konstruieren. Bestenfalls kann man es inaktiv setzen, so dass es nur noch grau erscheint. Und selbst das ist nicht trivial.
Es erfordert drei Klicks in dieser Klicki-Bunti-Software. Findest du das schon zu kompliziert?
Beste Grüsse
Richard
Hallo,
Bestenfalls kann man es inaktiv setzen, so dass es nur noch grau erscheint. Und selbst das ist nicht trivial.
Es erfordert drei Klicks in dieser Klicki-Bunti-Software. Findest du das schon zu kompliziert?
das kann ich dir sagen, wenn du mir verrätst, wie die Klicki-Bunti-Software das dann auf API-Ebene umsetzt.
Ciao,
Martin
Hallo Martin!
das kann ich dir sagen, wenn du mir verrätst, wie die Klicki-Bunti-Software das dann auf API-Ebene umsetzt.
Vorab: Frank hat ja freundlicherweise erklärt, wie der OP das beim normalen Fenster lösen kann. (Vorausgesetzt, er verfügt über ausreichende Kenntnisse mit FormClosing usw.)
Aber zu meinem Vorschlag ein Fenster ohne ControlBox (dieses x) zu verwenden. Windows verfügt nämlich über sehr viele verschiedene Fenster, nicht nur über das übliche. Und mit ControlBox = false; enthält die Titelzeile des Fensters kein Systemmenu, also auch kein Icon zum Schliessen des Fensters. So einfach ist das.
Beste Grüsse
Richard
Hallo Richard,
Du solltest dich fragen, ob es sinnvoll ist, die gewohnte Funktionsweise eines Fensters zu ändern, mit welcher Bastelei auch immer.
das Schließen eines Fensters abzufangen finde ich schon nützlich - nämlich u. a. dann, wenn der User noch nicht gespeichert hat und das Fenster schließen möchte.
Viele Grüße
Jörg
Hallo Jörg!
das Schließen eines Fensters abzufangen finde ich schon nützlich - nämlich u. a. dann, wenn der User noch nicht gespeichert hat und das Fenster schließen möchte.
Soweit einverstanden. Dann aber bitte mit dem sinnvollen Hinweis, dass nicht gespeichert wurde, und wirklich nur wenn dies tatsächlich zutrifft.
Normalerweise wird eine Anwendung ja nicht mit einem Klick auf das Schliessen-Icon beendet. Dieses sollte wirklich seiner Funktion entsprechend zum unmittelbaren Schliessen des Fensters benutzbar bleiben. Darauf klickt man ja nicht einfach so aus Lust und Laune. Und wenn darauf geklickt wird, hat der User auch die Konsequenzen zu akzeptieren. Das Auto hat zu bremsen, wenn ich aufs Bremspedal trete und nicht erst zu fragen, ob ich wirklich bremsen wolle. ;-)
Beste Grüsse
Richard
Hallo,
Erstmal vielen Dank für die Hilfe hier!
Aber bitte denkt doch auch mal daran, daß Programme nicht nur von Programmierern, sondern auch von normalen Usern, oder auch DAUs benutzt werden.
Und da gibt es kein 'normalerweise'!
Hi,
Aber bitte denkt doch auch mal daran, daß Programme nicht nur von Programmierern, sondern auch von normalen Usern, oder auch DAUs benutzt werden.
Und da gibt es kein 'normalerweise'!
wie wahr, wie wahr! Ich glaube, man lernt auch erst im Laufe der Zeit, dass man bei Anwendungen, die man für andere User schreibt, alles, aber wirklich alles, berücksichtigen muss. Und selbst, wenn man meint, dass man alles berücksichtigt hat, klickt der User irgendwohin, wo er gar nicht hinklicken sollte …
Und gerade das mit dem Schließen des Fensters ist ja eine Sache, mit der man unbedingt rechnen muss. Das gleiche Ereignis tritt ja auch bei Alt + F4; bei Alt + Leertaste, s; beim Anklicken des Befehls im Systemmenü; usw. auf. Und wenn man dann noch Childfenster hat, kommt noch Alt + -, s; usw. dazu.
Ich glaube auch, wenn man versucht, alles abzusichern, hat das nichts mit Bevormundung des Users zu tun. Warum soll ich das Ereignis nicht abfangen, wenn ich dem User dafür Datensicherheit biete?
Viele Grüße
Jörg
Hallo Richard,
Soweit einverstanden. Dann aber bitte mit dem sinnvollen Hinweis, dass nicht gespeichert wurde, und wirklich nur wenn dies tatsächlich zutrifft.
dass man Meldungen so schreibt, dass der User etwas damit anfangen kann, sollte eigentlich selbstverständlich sein …
Normalerweise wird eine Anwendung ja nicht mit einem Klick auf das Schliessen-Icon beendet. Dieses sollte wirklich seiner Funktion entsprechend zum unmittelbaren Schliessen des Fensters benutzbar bleiben. Darauf klickt man ja nicht einfach so aus Lust und Laune. Und wenn darauf geklickt wird, hat der User auch die Konsequenzen zu akzeptieren.
Naja, darunter verstehe ich aber Bevormundung des Users. Wenn sich jemand angewöhnt hat, Fenster mit Alt + F4 (was ja das gleiche Ereignis ist) zu schließen, soll er sich wegen meiner Anwendung umgewöhnen? Selbst wenn der User das einsehen würde - würde er nicht schon aus Gewohnheit diese Tastenkombination betätigen?
Viele Grüße
Jörg
Hallo Jörg,
dass man Meldungen so schreibt, dass der User etwas damit anfangen kann, sollte eigentlich selbstverständlich sein …
sicher, und sinnvollerweise sollte man von diesem Hinweis aus dann gleich das Speichern auslösen, wenn der Benutzer sich denn doch dafür entschieden hat, und danach das Programm beenden (das wollte er ja sowieso).
Normalerweise wird eine Anwendung ja nicht mit einem Klick auf das Schliessen-Icon beendet.
Äh, nicht? Doch, für mich ist das nach Alt-F4 die normalste Art, ein Windows-Fenster zu schließen - auch dann, wenn es das Hauptfenster einer Anwendung ist.
Naja, darunter verstehe ich aber Bevormundung des Users. Wenn sich jemand angewöhnt hat, Fenster mit Alt + F4 (was ja das gleiche Ereignis ist) zu schließen, soll er sich wegen meiner Anwendung umgewöhnen?
Nein, soll er natürlich nicht. Ob ich das Fenster durch Klicken auf das [X] oder durch Doppelklick auf das Fenstericon oben links, durch Alt-F4 oder durch Auswahl der entsprechenden Funktion im Systemmenü schließe, ist für die internen Abläufe völlig egal. Die Ereignisbehandlung von Windows sorgt dafür, dass mein Programm in jedem dieser Fälle genau das gleiche Ereignis wahrnimmt: Es erhält eine WM_DESTROY-Botschaft von Windows und sollte durch kontrolliertes Beenden der Anwendung darauf reagieren (oder in begründeten Ausnahmefällen das Schließen verweigern).
So long,
Martin
Hallo Martin,
dass man Meldungen so schreibt, dass der User etwas damit anfangen kann, sollte eigentlich selbstverständlich sein …
sicher, und sinnvollerweise sollte man von diesem Hinweis aus dann gleich das Speichern auslösen, wenn der Benutzer sich denn doch dafür entschieden hat, und danach das Programm beenden (das wollte er ja sowieso).
das kann man ja noch weiterführen: Wenn der User versehentlich auf das Kreuz geklickt und noch nicht gespeichert hat, freut er sich vielleicht noch über eine Abbrechen-Schaltfläche. ;-)
Ich habe jetzt einen solchen Fall. Die Software ist seit Monaten fertig und es wird auch schon lange damit gearbeitet. Die Anwenderin hat aber überhaupt kein Verständnis von/für Windows und wird dann auch mal schnell hektisch. Bisher dachte ich eigentlich, ich würde die Masse dessen, was in der Praxis so auftreten kann, abfangen - aber hier werde ich eines Besseren belehrt …
Normalerweise wird eine Anwendung ja nicht mit einem Klick auf das Schliessen-Icon beendet.
Äh, nicht? Doch, für mich ist das nach Alt-F4 die normalste Art, ein Windows-Fenster zu schließen - auch dann, wenn es das Hauptfenster einer Anwendung ist.
Sag' ich ja. ;-)
Allerdings nutze ich nicht das Kreuz, sondern Alt + F4. Ehe ich mit der Maus den Weg über den Bildschirm zurückgelegt und das Kreuz getroffen habe, bin ich mit der Tastatur wesentlich schneller. Für Child-Fenster nehme ich Strg + F4.
Aber ich habe schon viele Anwender gesehen (auch, als ich noch unterrichtet habe), die meist die Maus und damit das Kreuz nutzen.
Naja, darunter verstehe ich aber Bevormundung des Users. Wenn sich jemand angewöhnt hat, Fenster mit Alt + F4 (was ja das gleiche Ereignis ist) zu schließen, soll er sich wegen meiner Anwendung umgewöhnen?
Nein, soll er natürlich nicht. Ob ich das Fenster durch Klicken auf das [X] oder durch Doppelklick auf das Fenstericon oben links, durch Alt-F4 oder durch Auswahl der entsprechenden Funktion im Systemmenü schließe, ist für die internen Abläufe völlig egal. Die Ereignisbehandlung von Windows sorgt dafür, dass mein Programm in jedem dieser Fälle genau das gleiche Ereignis wahrnimmt: Es erhält eine WM_DESTROY-Botschaft von Windows und sollte durch kontrolliertes Beenden der Anwendung darauf reagieren (oder in begründeten Ausnahmefällen das Schließen verweigern).
Viele Grüße
Jörg
Hallo Jörg,
und sinnvollerweise sollte man von diesem Hinweis aus dann gleich das Speichern auslösen, wenn der Benutzer sich denn doch dafür entschieden hat, und danach das Programm beenden (das wollte er ja sowieso).
das kann man ja noch weiterführen: Wenn der User versehentlich auf das Kreuz geklickt und noch nicht gespeichert hat, freut er sich vielleicht noch über eine Abbrechen-Schaltfläche. ;-)
die habe ich selbstverständlich vorausgesetzt, so dass ich nicht auf die Idee kam, diesen Punkt extra zu erwähnen.
Doch, für mich ist das nach Alt-F4 die normalste Art, ein Windows-Fenster zu schließen - auch dann, wenn es das Hauptfenster einer Anwendung ist.
Sag' ich ja. ;-)
Allerdings nutze ich nicht das Kreuz, sondern Alt + F4.
Dito. Das meinte ich mit "nach Alt-F4 die normalste Art". ;-)
Aber ich habe schon viele Anwender gesehen (auch, als ich noch unterrichtet habe), die meist die Maus und damit das Kreuz nutzen.
Ich kenne sogar einige, die immer noch den aus Windows-3.x-Zeiten gewohnten Doppelklick aufs Systemmenü machen.
Schönes Wochenende,
Martin
nunja - wen es jedenfalls interessiert - hier die Lösung wie es bei mir klappt:
Private Sub Form1_FormClosing(ByVal sender As System.Object, ByVal e As System.Windows.Forms.FormClosingEventArgs) Handles MyBase.FormClosing
Dim Nachfrage As New MsgBoxResult
Nachfrage = MsgBox("Möchten Sie das Programm wirklich beenden?", MsgBoxStyle.OkCancel, "Achtung")
If (Nachfrage = MsgBoxResult.Ok) Then
e.Cancel = False
Else
e.Cancel = True
End If
End Sub
die schlägt jetzt zu wenn die Anwendung über Alt+F4, das Menu oder auch das x oben in der Ecke geschlossen wird
Hallo,
naja, war ja nun nicht wirklich schwer, oder?
Danke, dass du den Code (auch wenn es nur VB.net ist *scnr*) gepostet hast, dann hat der Thread doch noch etwas fachliche Qualität bekommen. ;)
Das Einzig(st)e, was ich zu deinem Code anmerken möchte, ist:
Cheers
Frank
Das Einzig(st)e, was ich zu deinem Code anmerken möchte, ist:
- Benutze Resource Libraries (Satellite Assemblies) für Texte in Messageboxen, Fenstertiteln und so weiter
Danke für den Tip - das wird in der nächsten Ausbaustufe sicher mit dabei sein - die Nützlichkeit davon habe ich schon an anderer Stelle bemerkt als es um eine StatusAnzeige ging (AmpelBildchen)
Hallo Jörg!
Naja, darunter verstehe ich aber Bevormundung des Users.
Das gilt umgekehrt aber auch. Wer erwartet, mit Alt + F4 oder Klick auf das Schliessen-Icon die Anwendung sofort zu verlassen, fühlt sich durch eine Rückfrage bevormundet und belästigt. Wir sind gerade dabei, aus Hunderten von Anwendungen diese Sicherheitsabfragen wieder zu entfernen, weil die User sich genervt fühlen. Vielleicht bin ich davon etwas beeinflusst.
Wenn sich jemand angewöhnt hat, Fenster mit Alt + F4 (was ja das gleiche Ereignis ist) zu schließen, soll er sich wegen meiner Anwendung umgewöhnen? Selbst wenn der User das einsehen würde - würde er nicht schon aus Gewohnheit diese Tastenkombination betätigen?
Nun, wenn Beamte an der armen Tastatur ihren Frust über den Verlust der geliebten Schreibmaschine auslassen, ist sowieso alles etwas komplizierter. ;-)
Das Abfangen des Schliess-Ereignisses ist in .NET ja auch sehr einfach, weil für das Fenster der EventHandler FormClosing verfügbar ist, dabei ist es denn auch egal, was die Ursache des Schliessens ist. Gerade diese Möglichkeit könnte aber statt einer Rückfrage eine Speicherung automatisch veranlassen, das gilt sogar dann, wenn Windows beendet wird. Ohnehin ist der beste Schutz vor Datenverlust gegeben, wenn bei Eingabe sofort gespeichert wird.
Ich denke, dass die Vorgehensweise in jedem einzelnen Fall nach abwägen von Vor- und Nachteilen entschieden werden muss. Ich bin einfach immer wieder erstaunt, dass es offenbar Leute gibt, die ganz genau zu wissen vorgeben, was meine User wirklich wollen. Damit bist jezt allerdings nicht du gemeint. ;-)
Mit besten Grüssen
Richard
Hallo Richard,
Das gilt umgekehrt aber auch. Wer erwartet, mit Alt + F4 oder Klick auf das Schliessen-Icon die Anwendung sofort zu verlassen, fühlt sich durch eine Rückfrage bevormundet und belästigt. Wir sind gerade dabei, aus Hunderten von Anwendungen diese Sicherheitsabfragen wieder zu entfernen, weil die User sich genervt fühlen. Vielleicht bin ich davon etwas beeinflusst.
sicher ist es auch unterschiedlich, für wen man etwas schreibt, dazu später aber noch etwas.
Das Abfangen des Schliess-Ereignisses ist in .NET ja auch sehr einfach, weil für das Fenster der EventHandler FormClosing verfügbar ist, dabei ist es denn auch egal, was die Ursache des Schliessens ist. Gerade diese Möglichkeit könnte aber statt einer Rückfrage eine Speicherung automatisch veranlassen, […]
Nun gut, ich schreibe nicht in .NET, aber das ist ja eigentlich auch egal. Aber bei der Vielzahl meiner Anwendungen kann ich es mir nicht vorstellen, etwas beim Schließen des Fensters (also beim Beenden der Anwendung) automatisch speichern zu lassen. Oft geht es um irgendwelche Kalkulationen im Kleinen (sei es ein Bestellprogramm) oder im Großen (Finanzen, bei denen die Eingaben in T€ erfolgen). Da werden manchmal Eingaben getätigt, um nur das Ergebnis zu sehen.
Nimm einfach mal folgenden Fall: Im Programm wird ein Szenario erstellt. Das wird gespeichert, weil alles korrekt ist. Anschließend werden zu Testzwecken andere Zahlen eingegeben, die nicht gespeichert werden sollen (man ist ja zu faul, um dafür ein Test-Szenario zu erstellen). Wenn dann das Szenario beim Beenden der Anwendung automatisch gespeichert wird, kann das böse Folgen haben. Beim Durchspielen einer Pizzabestellung mag das keine große Rolle spielen - aber wenn es um ein paar Milliönchen geht …
Und wohlgemerkt: Die Leute, die das Programm bedienen sind Leute, die sich mit ihrer Materie auskennen, nicht aber mit Windows. Da gehe ich lieber auf Nummer Sicher und baue Sicherheiten ein.
Ohnehin ist der beste Schutz vor Datenverlust gegeben, wenn bei Eingabe sofort gespeichert wird.
Ja, das denken Du, ich, wir hier …
Ich denke, dass die Vorgehensweise in jedem einzelnen Fall nach abwägen von Vor- und Nachteilen entschieden werden muss. Ich bin einfach immer wieder erstaunt, dass es offenbar Leute gibt, die ganz genau zu wissen vorgeben, was meine User wirklich wollen. Damit bist jezt allerdings nicht du gemeint. ;-)
Sicher, und damit schließe ich den Kreis, wenn Du Anwender hast, die sich durch die Messages genervt fühlen und wissen, was sie machen, ist das natürlich anders gelagert. Ich erhalte Aufträge von verschiedensten Auftraggebern - und wenn ich einen neuen nicht kenne, gehe ich immer auf Nummer Sicher. Wobei ich auch keinen Stammkunden habe, der sich über eine überflüssige Sicherheitsabfrage beschwert hätte.
Eine Ausnahme kenne ich: Mich beauftragen manchmal andere Entwickler für Teilprojekte. Da lasse ich bei Zwischenständen auch ganz gern mal solche Abfragen weg. Sobald das Projekt aber so weit ist, dass es an den Kunden rausgeht, kommen diese Abfragen auch wieder rein.
Und um nochmal zurückzukommen:
Wir sind gerade dabei, aus Hunderten von Anwendungen diese Sicherheitsabfragen wieder zu entfernen, weil die User sich genervt fühlen.
Dann könnte ich bei Feldern, in die Anzahlen eingegeben werden, ja auch die Prüfung weglassen, ob es sich um einen gültigen Wert handelt, nur weil die User von den Meldungen genervt sind. ;-)
Viele Grüße
Jörg
Hallo,
um mich mal einzumischen ...
Ich habe die Erfahrung gemacht, es ist von Fenster zu Fenster, Applikation zu Applikation und vorallem User zu User einfach unterschiedlich. Du hast (also eigentlich eher ich hab) zur gleichen Zeit Semi-Pro-Business-IT-Hybrid-Users und Weichflöten als Benutzer derselben Applikation.
Es gibt imho einfach keine Pauschalentscheidung zwischen
Gewinner ist der, der für den richtigen Zweck die richtige Variante verkaufen kann.
Dann könnte ich bei Feldern, in die Anzahlen eingegeben werden, ja auch die Prüfung weglassen, ob es sich um einen gültigen Wert handelt, nur weil die User von den Meldungen genervt sind. ;-)
Das erinnert mcih an was: Benutzer können _Text_ eingeben für einen Wert "Assets under Management".... manche geben 23 ein und meinen 23 Milliarden, andere geben 770 ein und meinen 770 Millionen, dann gibt es noch die alphanumerische Variante 56M (für Millionen oder Milliarden).
Ciao denn und Wan An!
Frank
