Programm für 5 sekunden anhalten und actionevent abfangen

[crasdf]

hallo leute

ich brauch mal hilfe bei so ner idee von mir und zwar folgendes:

ich hab ein programm das durch das klicken von jbuttons insert befehle an eine db schicken.
da sind viele buttons drauf und man kann sich verklicken, deswegen moechte ich, das nach dem klick auf einen der jbuttons 5 sekunden auf die eventuelle betaetigung eines "undo" oder "cancel" buttons gewartet wird, bis der sql befehl abgesendet wird, ansonsten wird rollback gecalled.

ich tu mir sehr schwer mit google suchbegriffen bei dem thema und kann kaum was finden das das beschreibt was ich mir da vorstell

mfg
crasdf

 

[Marco13]

Klingt vom Bedienkonzept her ... SEHR "unkonventionell" ("Warum passiert nichts, wenn ich klicke? ;( " )... aber du kannst dir mal nach der Klasse "Timer" suchen - entweder den aus javax.swing oder javax.utils, je nachdem, wie genau das ablaufen soll (die eigentliche DB-Arbeit läuft ja vermutlich eh in einem eigenen Thread, ggf. mit einem SwingWorker...!?)

 

[Latur]

Ich kann Marco13 nur zustimmen!

Ich würde dir eher raten ein JOptionPane zu nutzen, um mit diesem den Nutzer auf den gewählten Befehl erneut aufmerksam zu machen und gleichzeitig ihn zur nochmaligen Bestätigung zwingen.

Benutzen kannst du es mit:

int retVal = JOptionPane.showConfirmDialog(this, "Wollen sie den Befehl XY wirklich ausführen?", "Titel hier übergeben", JOptionPane.OK_CANCEL_OPTION);
        if(retVal == JOptionPane.OK_OPTION)    {
            System.out.println("Hat auf OK gedrückt");
        } else  {
            System.err.println("Hat auf Abbrechen gedrückt");
        }

Anmerkung:
Der erste Übergabeparameter (in meinem Fall 'this'), sollte eine Referenz auf das Parent-Fenster darstellen, falls du es mit Netbeans machst ist es in den meisten fällen einfach 'this'
[Man könnte auch 'null' übergeben, allerdings wäre das schlampig ;D]

 

[Michael...]

da sind viele buttons drauf und man kann sich verklicken

Hört sich nach einem fragwürdigen Bedienkonzept und schlechten GUI Design an ;-)
Bekommt der Anwender dann überhaupt mit, dass er den falschen Button gedrückt hat?

Ich würde da bei kritischen Aktionen auch eher zu einer Bestätigung mittels JOptionPane tendieren.

 

[Andi_CH]

Sind sie sicher, dass sie die Datei löschen wollen?
Sind sie wirklich gaaaanz sicher dass sie die Datei wirklich löschen wollen?

-> und dennoch brauchen wir Backups

Man nennt das auch impulsiven Arbeitsstil - die User sollen sich besser daran gewöhnen erst zu denken...

Ja, das war ziemlich sarkastisch

Ich könnte mir etwas vorstellen.

Der User klickt und sieht ein Resultat. Allerdings wird im Hintergrund das ganze verzögert und so ein vereinfachtes Rollback ermöglicht.

So ähnlich wie bei den Beiträgen hier - da hat man ja nur eine gewisse Zeit zur Verfügung, diese zu ändern.

 

[Marco13]

Sicher wäre eine mehrstufige Undo-Funktion schöner, aber exorbitant viel, viel aufwändiger. Das einfachste (und "konventionellste") dürfte wohl ein Bestätigungsdialog sein. Ab besten ohne Focus, damit man ihn nicht versehentlich mit "Enter" bestätigt, und am besten erscheint er jedes mal an einer zufällige Bildschirmposition, damit der User wach bleibt.
(Eigentlich müßte da ein " :joke: " hin, aber ... wie löscht man in Windows Dateien? Man drückt Entf und dann sofort Enter, weil ja erst der Dialog kommt. Und wenn beim Dialog standardmäßig "Abbrechen" ausgewählt ist, drückt man irgendwann gleich Entf-Links-Enter. Die Dialoge haben keine andere Funktion, als die Anzahl der Tasten, die man drück muss, zu erhöhen. Man denkt dadurch kein Stück mehr über das nach, was man tut...)

 

[maki]

Je mehr Bestätigungsdialoge einem User gezeigt werden, umso automatischer klickt er auf OK ohne den Text zu lesen.
Würde lieber die "vielen" Buttons neu arrangieren, so dass "fehlclicks" seltener und offensichtlicher sind.

 

[vanny]

Das ist in etwa auch das Kriterium, das mich in der Regel genauso lange aufhält, wie das Programmieren an sich.
Ich versuche immer dem Programm eine größtmögliche Eigenlogik zu verpassen, so dass der User nur logische Operationen zur Verfügung hat.(Stichwort Prozeßorientiert)
Speziell bei Programmen, die eine Schnittstelle zwischen DAU und DB darstellen ist sowas Goldstaub.

Gruß Vanny

 

[bERt0r]

Vielleicht würds auch helfen auf der DB kein autocommit zu machen, sondern nur wenn der User (indem er auf einen Commit Button klickt ) das will.

 

[Cola_Colin]

Was ist das für eine db ?
Könnte man nicht die Änderungen erst mit einem Klick auf einen extra Button -fernab der anderen und mit Bestätigungsdialog- commiten, bzw mit einem anderen Button einen rollback ausführen ?

Die Möglichkeit einen Fehler leicht rückgängig machen zu können ist imho mehr Wert als ihn zu verhindern.

EDIT: langsaaaaam xD

 

[crasdf]

ok erstmal verzeihung fuer die verspaetung
nun will ich fragen beantworten
vorneweg, hier ist ein screenshot von der gui:
ImageShack® - Online Photo and Video Hosting

erstmal @Marco13
es passiert schon etwas, wenn man klickt, es soll nur 5 sekunden gewartet werden, bis etwas passiert und ja, db laeuft in einem extra thread

@Latur
erstaunlicherweise hatte ich diese idee auch schon und ich danke dir vielmals fuer den code :thumbsup:

@Michael...
schau dir den scrot an. ich weiss das das nicht brilliant designed ist. ist allerdings transparent.
wenn der user ausversehen mit der maus abgerutscht ist, wird er/sie schon merken das das jetzt der falsche button war, deswegen halte ich die bestaetigung per JOptionPane auch fuer sehr nice

@Andi CH
es ist nicht eingeplant das der user ein resultat sieht. allerdings, wie auch schon angemerkt, angesichts des aufwands einfach "herkoemmlicher" ein OptionPane zu nutzen

@Marco13
hihi ich hab auch direkt ueberlegt ob ich den focus auf ja oder nein legen soll, ich habs gerne auf ja, aber fuer den durchschnittsuser...

@maki
das klingt super. ohne dich noetigen zu wollen meinst du du kannst da n konkreten vorschlag machen wenn du dir den scrot ansiehst?

@bERt0r
auch ne gute idee, das kann man mit nem joptionpane und nem return allerdings wohl genauso machen, so das das prog nicht mal an die stelle springt an der PrepStmt.execute(); steht

@Cola_Colin
ganz normaler mysql community server. z. zt. unter windows
auch hier wuerd ich sagen das das rollback durch den dialog quasi....hm obsolete ist
oder irr ich mich da?
ahhhh

/edit:
nochmal vielen dank an Latur, habs grad eingebaut, works like a charm!

mfg
und vielen dank fuer die guten ideen
crasdf

 

[Michael...]

Kenn die Hintergründe nicht aber für mich schaut das eher nach einem Anwandungsfall für JRadioButtons aus und eventuell einem OK Button um die Aktion auszulösen.

 

[Illuvatar]

Kleiner Offtopic-Tip: Ich halte scrot für eine nicht sonderlich gelungene Abkürzung für screenshot: Ich hab mich eben einige Zeit gewundert, warum du dein Programm dauernd als Schrott bezeichnest (und das auch noch 2 mal falsch schreibst )

 

[Shulyn]

Du könntest die zustände der Buttons in einem kleinen Model halten. Der Klick auf die Buttons verändert dann nur das Model und sendet nicht sofort die Inserts ab.
Wenn der Dialog geschlossen wird (z.B. über "OK" oder "Absenden" ) werden die eigentichen Inserts erst losgeschickt.

 

[turtle]

Ich halte, wie meine Vorposter, eine JOptionPane für ganz angebracht für diesen Fall.

Ich möchte aber noch meine 2 Cents einwerfen und anregen, dass die JOptionPane sich automatisch schliessen (und die Operation ausführen) könnte, wenn der User NICHT interveniert.

Also zeigt das Programm in der JOptionPane an "Folgender Befehl <bla> wird in <x> Sekunden automatisch ausgeführt". Wenn vor Ablauf der User auf den Cancel-Button klickt, wird die Operation natürlich nicht ausgeführt.

 

[bERt0r]

Habt ihr euch den screenshot seiner GUI angesehen? Das ist eindeutig ein fall für Radiobuttons oder Checkboxen

 

[crasdf]

@Michael...
was kann das was ein bestaetigungsdialog nicht kann?

@Illuvatar
das "scrot" is nur ne angewohnheit von der linux kommandozeile

@turtle
danke fuer die bestaetigung und die idee

und @ bERt0r
was kann das besser machen was der bestaetigungsdialog nicht schon macht?
die user, die dieses tool benutzen werden wissen schon ganz genau was sie zu klicken haben, wie schon vorher gesagt ein fehlklick wuerde dem user sofort auffallen. aber kein problem er kann die bestaetigung ja verneinen!

 

[Michael...]

Beschreib doch mal wie das vom Anwender bedient werden muss/soll.

 

[bERt0r]

Mir stellen sich einfach die Haare auf, wenn ich sowas sehe und Radiobuttons vermeiden genau dein Problem. Ausserdem nervt so ein Bestätigungsdialog. Wenn ich 3 deiner Optionen aktivieren will, muss ich 6 mal klicken und es springt dauernd ein neues Dialogfeld auf. Mit Radiobuttons löse ich alles in einem Fenster und mit 4 Klicks. So viele Bestätigungsfelder sind im Allgemeinen für den Benutzer ein Horror, es sei denn er will das genau so haben, dann bin ich ruhig