Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   GUI-Design mit VCL / FireMonkey / Common Controls (https://www.delphipraxis.net/18-gui-design-mit-vcl-firemonkey-common-controls/)
-   -   Delphi Actions schlagen zu (sollen sie aber nicht immer) (https://www.delphipraxis.net/63359-actions-schlagen-zu-sollen-sie-aber-nicht-immer.html)

luebbe 17. Feb 2006 15:12


Actions schlagen zu (sollen sie aber nicht immer)
 
Hallo, ich habe folgendes Problem:

In meiner Anwendung gibt es mehrere Actions, die einen einzelnen Shortcut haben. z.B. 'O' für Online 'P' für Print. Aus gutem Grund (Einhandbedienung & merkbar) soll das auch so bleiben. Die Actions hängen in einem Actionmanager auf dem Hauptformular einer MDI Anwendung.

Nun hat jedoch eines meiner MDI Childwindows ein Eingabefeld. Blöderweise kann man in dieses Feld weder 'P' noch 'O' eintragen, weil die Actions die Tastendrücke vorher wegfangen.

Außer der Möglichkeit, aus dem MDI Child heraus die globalen Actions zu deaktivieren, sobald das Eingabefeld betreten wird, fällt mir nichts ein. Den Ansatz finde ich allerdings ziemlich hässlich, weil das MDI Child in sich geschlossen ist und nicht auf globale Objekte zugreifen soll. Hat noch jemand eine bessere Idee?

Gruß
-Lübbe

marabu 17. Feb 2006 16:43

Re: Actions schlagen zu (sollen sie aber nicht immer)
 
Herzlich willkommen in der Delphi-PRAXiS, Lübbe.

Du umgehst das Problem geschickt, wenn du für deine ShortCuts einen Shift-Key zum Kennbuchstaben dazu nimmst - mit Strg+P bzw. Strg+D wird auch in vielen anderen Windows-Programmen gedruckt.

Freundliche Grüße vom marabu

luebbe 20. Feb 2006 08:12

Re: Actions schlagen zu (sollen sie aber nicht immer)
 
Zitat:

Zitat von marabu
Herzlich willkommen in der Delphi-PRAXiS, Lübbe.

Danke :-)

Zitat:

Zitat von marabu
Du umgehst das Problem geschickt, wenn du für deine ShortCuts einen Shift-Key zum Kennbuchstaben dazu nimmst - mit Strg+P bzw. Strg+D wird auch in vielen anderen Windows-Programmen gedruckt.

Ich weiss. Nur ist diese Umgehung, wie ich bereits schrieb, leider nicht möglich. Manche Aktionen in der Anwendung müssen aus Kundensicht mit einer Taste, allein mit der rechten Hand bedient werden können. Kombinationen, die große Reichweite erfordern, wie z.B. Strg+H und alles "links davon" scheiden aus diesem Grunde aus. Die 12 Funktionstasten sind größtenteils belegt.

Ich benötige eine Lösung für Eintastenaktionen, normale Buchstaben, die ich:
- entweder selektiv abschalten kann, (weiss ich wie's geht, ist für mich aber die zweitbeste Lösung)
- oder einen Tipp, wie ich in einem TEdit sicher jeden Tastendruck bekomme, auch wenn z.B. eine Action mit dem Shortcut "P" aktiv ist.

Gruß
-Lübbe

marabu 20. Feb 2006 08:35

Re: Actions schlagen zu (sollen sie aber nicht immer)
 
Ich muss zugeben, dass für mich Einhandbedienung und Strg+D für Drucken vereinbar erscheinen. Auch ist ein simples D als ShortCut kontraproduktiv, wenn alle anderen Anwendungen Strg+D verwenden, aberseisdrum. Unter Berücksichtigung deiner Anforderung würde ich das Problem so lösen:

Delphi-Quellcode:
// shortcut = D
procedure TDemoForm.PrintActionUpdate(Sender: TObject);
begin
  with Sender as TAction do
    Enabled := true // deine eigenen Bedingungen
      and not (ActiveControl is TCustomEdit);
end;
Grüße vom marabu

luebbe 20. Feb 2006 09:20

Re: Actions schlagen zu (sollen sie aber nicht immer)
 
Zitat:

Zitat von marabu
Ich muss zugeben, dass für mich Einhandbedienung und Strg+D für Drucken vereinbar erscheinen. Auch ist ein simples D als ShortCut kontraproduktiv, wenn alle anderen Anwendungen Strg+D verwenden, aberseisdrum.

P für Print und O für Online waren Beispiele. Die Anwendung ist von der Ergonomie her sehr "speziell", von daher die Abweichung von vielen Windows Standards. Leg mal die linke Hand auf den Rücken und drücke Strg+D, Strg+T, Strg+Z. Irgendwie ungelenk oder?

Zitat:

Zitat von marabu
Unter Berücksichtigung deiner Anforderung würde ich das Problem so lösen:

Delphi-Quellcode:
// shortcut = D
procedure TDemoForm.PrintActionUpdate(Sender: TObject);
begin
  with Sender as TAction do
    Enabled := true // deine eigenen Bedingungen
      and not (ActiveControl is TCustomEdit);
end;

OK, Danke. Das heisst Du siehst auch keine andere Möglichkeit, als die Actions gezielt an- und auszuschalten. Schade, denn den Griff vom einen ins andere Formular wollte ich vermeiden.

Gruß & Danke
-Lübbe

marabu 20. Feb 2006 11:42

Re: Actions schlagen zu (sollen sie aber nicht immer)
 
Mir scheint du hast eine spezielle Zielgruppe im Auge. Nur linke Hand und die verkehrt herum - arbeiten deine Benutzer in der Regierung?

Mein Lösungsansatz erfordert übrigens keine formular-übergreifenden Zugriffe, da üblicherweise nur der Action-Code zentralisiert wird - die event handler bleiben in der jeweiligen Form.

Viel Erfolg mit deinem Projekt.

marabu

luebbe 20. Feb 2006 12:57

Re: Actions schlagen zu (sollen sie aber nicht immer)
 
Zitat:

Zitat von marabu
Mir scheint du hast eine spezielle Zielgruppe im Auge. Nur linke Hand und die verkehrt herum - arbeiten deine Benutzer in der Regierung?

:-D
Ich meinte: "linke Hand hinter den Rücken und mit der rechten Hand alleine tippen"

Zitat:

Zitat von marabu
Mein Lösungsansatz erfordert übrigens keine formular-übergreifenden Zugriffe, da üblicherweise nur der Action-Code zentralisiert wird - die event handler bleiben in der jeweiligen Form.

OK, hab's kapiert. mit einer kleinen Änderung geht's (Screen.ActiveControl anstatt ActiveControl und TEdit anstatt TCustomEdit). Im Hauptformular an alle betroffenen Actions folgendes gehängt

Delphi-Quellcode:
procedure TMainForm.SpecialActionUpdate(Sender: TObject);
begin
  with Sender as TAction do
    Enabled := not (Screen.ActiveControl is TEdit);
end;
und sie schalten sich brav aus und wieder an. Mir war nicht klar, dass ActionUpdate von der Anwendung selber ausgelöst wird. Das macht das Leben natürlich einfacher.

Gruß & Danke
-Lübbe


Alle Zeitangaben in WEZ +1. Es ist jetzt 22:05 Uhr.

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz