F10 Taste springt immer ins Dateimenü

[stevie]

Immer wenn man in einem xclass oder xbasefenster F10 drückt, wird immer ins Dateimenü gesprungen. Selbst wenn man für F10 über den keyboard slot was anderes programmiert hat. Kann man das irgendwie abschalten?

[brandelh]

Hi,

die IBM SAA Architektur sah F10 für Menü vor.
XClass scheint das eingebaut zu haben.
Entweder über ein SetAppEvent() oder in den Keyboard-Methoden.

Du hast doch den Quellcode von XClass oder hat sich das geändert ?

Dort wird die Antwort zu finden sein.

[Martin Altmann]

Nun,
das Thema hatten wir hier schon und das hat nichts mit XClass++ zu tun!
Ist SWB und funktioniert genauso auch in anderen Programmen.

Viele Grüße,
Martin

[stevie]

Hi,

die IBM SAA Architektur sah F10 für Menü vor.
XClass scheint das eingebaut zu haben.
Entweder über ein SetAppEvent() oder in den Keyboard-Methoden.

Du hast doch den Quellcode von XClass oder hat sich das geändert ?

Dort wird die Antwort zu finden sein.

nicht nur xclass auch xbase

[Jan]

Ich hab das gleiche Problem vor kurzem auch gehabt. Weil ich die F10-Taste in einem Projekt umbiegen und auf eine eigene Funktion umbiegen wollte. Das hat mich fast zum Wahnsinn getrieben, weil immer die Windows-Funktion wieder durchgeschlagen ist und F10 einfach nicht das gemacht hat, was ich wollte. Wie Hubert vorgeschlagen hat, versuch es mit der Event-Schleife. Zur Not kannst Du das da ja auch totlegen.

Das hat in der Tat nichts mit Xbase oder sonstwas zu tun, sondern ist Windows-Fundament.

Jan

[stevie]

Ich hab das gleiche Problem vor kurzem auch gehabt. Weil ich die F10-Taste in einem Projekt umbiegen und auf eine eigene Funktion umbiegen wollte. Das hat mich fast zum Wahnsinn getrieben, weil immer die Windows-Funktion wieder durchgeschlagen ist und F10 einfach nicht das gemacht hat, was ich wollte. Wie Hubert vorgeschlagen hat, versuch es mit der Event-Schleife. Zur Not kannst Du das da ja auch totlegen.

Das hat in der Tat nichts mit Xbase oder sonstwas zu tun, sondern ist Windows-Fundament.

Jan

Setappevent und die keyboardmethoden bringen zwar den Aufruf,aber ins Dateimenü wird trotzdem gesprungen.
Es gibt doch aber Programme, die f10 nicht bieten, also muss das ja irgendwo im Programm zu verbieten gehen.

[Jan]

Hmmm. Bei mir funktioniert es jetzt sauber. Wie gesagt, ich hab das in die Eventschleife des Programms (bzw. bei diesem speziellen Projekt des jeweiligen Threads) gepackt. Null Windows-Funktionalität mehr. Nur noch das, was ich will.

Jan

[brandelh]

Hi,

es war mir entgangen, dass dies nun automatisch von Xbase++ unterstützt wird. Bei der F1 Taste mache ich ähnliches, das hatte ich auch schon mal geschrieben ... blos wo

Der Trick besteht darin den handelevent() Aufruf zu blockieren, die genauen Defines bitte aus AppEvent.ch holen, die weiß ich nicht aus dem Kopf und ich bin schon auf dem Sprung ...

Code: Alles auswählen

nEvent := AppEvent(...)
if nEvent = Xbp ... Keyboard event ?
   do case 
        case mp1 = Xbp ... Taste F10 ... dann blockieren
                nEvent := NONE  // Kürzel für keinen Event
...

if nEvent # NONE
   oXbp:handleevent(....)
endif 

am Besten hier nach F1 suchen dann findest du den genauen Code

[stevie]

Hi,

es war mir entgangen, dass dies nun automatisch von Xbase++ unterstützt wird. Bei der F1 Taste mache ich ähnliches, das hatte ich auch schon mal geschrieben ... blos wo

Der Trick besteht darin den handelevent() Aufruf zu blockieren, die genauen Defines bitte aus AppEvent.ch holen, die weiß ich nicht aus dem Kopf und ich bin schon auf dem Sprung ...

Code: Alles auswählen

nEvent := AppEvent(...)
if nEvent = Xbp ... Keyboard event ?
   do case 
        case mp1 = Xbp ... Taste F10 ... dann blockieren
                nEvent := NONE  // Kürzel für keinen Event
...

if nEvent # NONE
   oXbp:handleevent(....)
endif 

am Besten hier nach F1 suchen dann findest du den genauen Code

Kommt das mit in die Main?
F10 ist übrigens xbeK_F10
Und brandelh: Was kommt denn in Appevent und handleevent?
Ich hatte nie was damit zu tun.
Wenn ich das so in die main einbaue, treten jede Menge Compilerfehler auf. Sicher bedingt durch xclass.

nEvent := AppEvent(@mp1,@mp2,@oXbp,0)
if nEvent = XbeK_F10
do case
case mp1 = XbeK_F10
nEvent := NONE // Kürzel für keinen Event
case mp1 !=xbEK_F10
nevent:=nevent
enddo
endif

if nEvent # NONE
oXbp:handleevent(nevent,mp1,mp2)
endif

[Martin Altmann]

Hallo Stevie,
bei XClass ist das alles zum Glück viel einfacher!
Schau Dir mal die AddEventKey()-Methode an:

Code: Alles auswählen

::AddEventKey( xbeK_F10, { || ::nrbeleg(), datausles( ::editControls, ::alteWerte, .t. ), ::Ansprung() } )          // <F10> ruft Prozedur ansprung auf

Klappt wunderbar...

Viele Grüße,
Martin

[stevie]

Hallo Stevie,
bei XClass ist das alles zum Glück viel einfacher!
Schau Dir mal die AddEventKey()-Methode an:

Code: Alles auswählen

::AddEventKey( xbeK_F10, { || ::nrbeleg(), datausles( ::editControls, ::alteWerte, .t. ), ::Ansprung() } )          // <F10> ruft Prozedur ansprung auf

Klappt wunderbar...

Viele Grüße,
Martin

Bei mir nicht
Hab ne Mdi-Anwendung in der ein Dialog geöffnet wird. In diesem müsste das normalerweise dann so funktionieren.
Hauptfenster ist oApp
oDlg:AddEventKey( xbeK_F10, { ||akt(XbeK_F10)})

Proc akt(nkey)
local cColor,aZust
if nkey==xbeK_F1
dsconfirmbox(getapp():drawingArea,str(nkey), "F1", XBPMB_OK)
endif
if nkey==xbeK_F10
dsconfirmbox(getapp():drawingArea,str(nkey), "F10", XBPMB_OK)
endif
if nkey==xbeK_F8
dsconfirmbox(getapp():drawingArea,str(nkey), "F8", XBPMB_OK)
endif
return
Er springt weiterhin nur ins Menü. Wenn die Funktion bspw. mit F8 über xkeyboard aufgerufen wird, klappts. AddEventkey klappt aber weder mit f8 oder mit f10. Wenn ich das über xkeyboard mache, funktioniert zwar f10. Er springt aber gleichzeitig auch ins Menü.

[Martin Altmann]

Hallo Stevie,
hmm - dann liegt das vielleicht bei mir daran, dass ich nur modale Dialoge benutze.
Ist ein Fenster offen, kann bei mir kein Menüpunkt angewählt werden.

Viele Grüße,
Martin

[stevie]

Hallo Stevie,
hmm - dann liegt das vielleicht bei mir daran, dass ich nur modale Dialoge benutze.
Ist ein Fenster offen, kann bei mir kein Menüpunkt angewählt werden.

Viele Grüße,
Martin

Daran kanns liegen. Nur Addeventkey funktioniert auch im Hauptfenster ohne geöffnete Fenster nicht.

[Wolfgang Ciriack]

nEvent := AppEvent(@mp1,@mp2,@oXbp,0)
if nEvent = XbeK_F10
do case
case mp1 = XbeK_F10
nEvent := NONE // Kürzel für keinen Event
case mp1 !=xbEK_F10
nevent:=nevent
enddo
endif

if nEvent # NONE
oXbp:handleevent(nevent,mp1,mp2)
endif

Das ist falsch.
Muss lauten:

Code: Alles auswählen

if nEvent = XbeP_Keyboard
   do case
        case mp1 = XbeK_F10
........

[stevie]

nEvent := AppEvent(@mp1,@mp2,@oXbp,0)
if nEvent = XbeK_F10
do case
case mp1 = XbeK_F10
nEvent := NONE // Kürzel für keinen Event
case mp1 !=xbEK_F10
nevent:=nevent
enddo
endif

if nEvent # NONE
oXbp:handleevent(nevent,mp1,mp2)
endif

Das ist falsch.
Muss lauten:

Code: Alles auswählen

if nEvent = XbeP_Keyboard
   do case
        case mp1 = XbeK_F10
........

Ich habe jetzt statt Appexec()
DO WHILE .T.
nEvent := AppEvent(@mp1,@mp2,@oXbp,0)
if nEvent == XbeP_Keyboard
if mp1 = XbeK_F10
nEvent := NONE // Kürzel für keinen Event
endif
endif
if nEvent # NONE
oXbp:handleevent(nEvent,mp1,mp2)
endif
ENDDO

in das xclass-Fenster aufgenommen.
Bei if nEvent ==xbeP_Keyboard wird während des Starts der Anwendung gemeldet, dass die Variable nicht existiert. Dann muss ja da noch was falsch sein.

[Jan]

Stevie,

Du musst am Anfang ein

Code: Alles auswählen

# include "appevent.ch"

einbauen. Dann findet der auch die Variable.

Und formatier doch Deinen Code mal, ist wirklich besser zu lesen dann.

Jan

[stevie]

Stevie,

Du musst am Anfang ein

Code: Alles auswählen

# include "appevent.ch"

einbauen. Dann findet der auch die Variable.

Und formatier doch Deinen Code mal, ist wirklich besser zu lesen dann.

Jan

wenn das so einfach wäre...
Übrigens sie wird includet und ist trotzdem unbekannt. Hab sie sogar vorher nochmal definiert. Versuchs jetz mit der Zahl 1048580. NONE hab ich mit 0 definieren müssen. Dann funktioniert F10 nicht. Wie kann ich denn nun F10 für den einzelnen Dialog im Hauptfenster erlauben?
Habs jetz so:
#define NONE 0
DO WHILE nEvent != xbeP_Close

nEvent := AppEvent(@mp1,@mp2,@oXbp)
if nEvent == 1048580

if mp1 = 65657

nEvent := NONE // Kürzel für keinen Event

endif

endif

if nEvent # NONE

oXbp:handleevent(nEvent,mp1,mp2)

endif
ENDDO
Das soll aber nur fürs Hauptfenster gelten. Ich will ja schließlich im Childfenster F10 für meine Zwecke nutzen.

[stevie]

Oder vielleicht gibt es ja auch eine Möglichkeit, alle Tasten in einem Anwendungsfenster zu verbieten, aber in den einzelnen Child-Fenstern zu erlauben?

[J.Renseler]

Hallo,

die alternative zum Verändern der Eventloop wäre es, das ganze direkt in der Fensterklasse zu machen. So kannst du für jedes Fenster (bzw. sogar jedes Visuelle Objekt) einzeln bestimmen was es an Tasten/(bzw. Events) bearbeiten kann. So könntest du dir relativ einfach eine Fensterklasse bauen der du übergibst welche Tasten funktionieren und was sie auslösen.

Wichtig: für Tasten die du nicht bearbeiten möchtest musst du die Keyboard Methode deiner Superklasse aufrufen

Code: Alles auswählen

CLASS MeinDialog FROM dsDialog
  EXPORTED:
          METHOD ;
                 keyboard(nKey)
ENDCLASS

METHOD MeinDialog:keyboard( nKey)

  IF nKey == xbeK_ESC
    MsgBox("ESC gedrückt")
  ELSEIF nKey == xbeK_F10
    MsgBox("F10 gedrückt")
  ELSE
    ::dsDialog:keyboard(nKey)
  ENDIF

RETURN(SELF)

Gruß,
Jannik

[brandelh]

Hallo stefi,

ich habe kein XClass und kann es daher nicht überprüfen.

Ich denke aber, dass der F10 Event direkt im MDI Hauptfenster so belegt ist, da ja alle unverarbeiteten Events zum Schluss dort landen. Wenn XClass eine eigene Eventloop hat, muss man natürlich diese abändern oder besser wie von Janik gezeigt Das zu blockierende Fenster ableiten und die Keyboardmethode überarbeiten.

[stevie]

Hallo stefi,

besser wie von Janik gezeigt Das zu blockierende Fenster ableiten und die Keyboardmethode überarbeiten.

Ich heiße, wenn schon stevie, oder halt Stefan.
Jetzt gehts.

Code: Alles auswählen

CLASS Dlg from dsdialog

   var mp1,mp2,obj,nkey

   Exported
   Method create,keyboard,init

endclass

Method Dlg:Init(oParent, oOwner, aPos, aSize, aPP, lVisible)

   ::dsdialog:Init(oParent, oOwner, aPos, aSize, aPP, lVisible)

return self

Method Dlg:Create(oParent, oOwner, aPos, aSize, aPP, lVisible)

   ::dsdialog:Create(oParent, oOwner, aPos, aSize, aPP, lVisible)

return self

Method Dlg:keyboard(nkey)

   akt(nkey) //hier übergebe ich den Knopf an die Fkt. akt, welche dann je nach Taste entsprechendes ausführt.

return self

In so einem Fenster darf aber kein Menü oder Kontextmenü enthalten sein, daher nur als Childfenster.

[J.Renseler]

Hallo Stevie,

nur noch so als kleiner Tipp. Wenn du in den create() und init() Methoden nichts anderes mehr machen willst kannst du dir die auch sparen.

Wenn du sie nicht erneut deklarierst werden "automatisch" die create(), und init() Klassen deiner Superklasse (hier dsdialog) benutzt.

Du rufst ja in deinen eigenen create() und init ()Methoden nur die create() und init() Methoden deiner Superklasse auf.

[stevie]

Hallo Stevie,

nur noch so als kleiner Tipp. Wenn du in den create() und init() Methoden nichts anderes mehr machen willst kannst du dir die auch sparen.

Wenn du sie nicht erneut deklarierst werden "automatisch" die create(), und init() Klassen deiner Superklasse (hier dsdialog) benutzt.

Du rufst ja in deinen eigenen create() und init ()Methoden nur die create() und init() Methoden deiner Superklasse auf.

das wusste ich nicht. ich hatte es ohne init probiert, ging aber nich. deswegen hatte ich beide. hab aber beides jetz rausgenommen und dann klappts auch.
Was ich noch rausgefunden habe, das Kontextmenü kann man erlauben, wenn man für contextmenukey 0 setzt, funktioniert das Kontextmenü auch. Sonst würde bei F10 das Kontextmenü (bei mir vom Browser) geöffnet