Alaskas ColTest bzw. EditBrowse

[Jan]

Hallo Hubert und Andreas,

nun, im Prinzip ist global abschalten fast richtig. Aber eben nur fast. Denn ich möchte mit F10 ja gerade etwas tun. Was von Dialog zu Dialog aber unterschiedlich ist. Und in manchen Dialogen auch mal garnichts ist.

Die ganze Sache sieht in dem betreffenden Teil so aus:
Erstellt wird der Dialog mit den Beleg-Kopfdaten. Dach Erstellen dieses Dialoges kommen die folgenden Punkte.

1) Direkt nach Erzeugen des Dialoges die Tastenbedienungen abfragen:

Code: Alles auswählen

oDlg:Keyboard := {|nKey,y,Obj| Checkkeys(nKey, aButton)}                //Funktionstasten über Tastatur aufrufen

2) Danach Erstmal die Buttons erzeugen, inkl. was der Druck darauf jeweils bewirken soll

Code: Alles auswählen

aButton := {{"F2=Zurück"     , GRA_CLR_DARKBLUE , {||oDlg:destroy(), SetAppFocus(oAltBrowse)}                                              }, ;
            {"F3="           , GRA_CLR_DARKGRAY , NIL                                                                                      }, ;
            {"F4=Liste"      , GRA_CLR_DARKBLUE , {||MsgBox("Liste öffnen"), SetAppFocus(oDlg)}                                            }, ;
            {"F5=Löschen"    , GRA_CLR_RED      , {||MsgBox("Beleg löschen"), SetAppFocus(oDlg)}                                           }, ;
            {"F6=s.Kdnr."    , GRA_CLR_DARKGREEN, {||MsgBox("Kundennr. suchen"), SetAppFocus(oDlg)}                                        }, ;
            {"F7="           , GRA_CLR_DARKGRAY , NIL                                                                                      }, ;
            {"F8=Speichern"  , GRA_CLR_DARKGREEN, {||MsgBox("Speichern"), SetAppFocus(oDlg)}                                               }, ;
            {"F9=Neu Kd."    , GRA_CLR_DARKPINK , {||MsgBox("Neuer Kunde"), SetAppFocus(oDlg)}                                             }, ;
            {"F10=Posit."    , GRA_CLR_DARKPINK , {||positionen_bearbeiten(oDlg, Beleg_Kopfdaten->BK_BELEG, oHauptDlg), SetAppFocus(oDlg)} }, ;
            {"F11="          , GRA_CLR_DARKPINK , NIL                                                                                      }, ;
            {"F12=W.Bedarf"  , GRA_CLR_BROWN    , {||MsgBox("Warenbedarf anzeigen"), SetAppFocus(oDlg)}                                    }, ;
            {"^F2="          , GRA_CLR_DARKGRAY , NIL                                                                                      }, ;
            {"^F3="          , GRA_CLR_DARKGRAY , NIL                                                                                      }, ;
            {"^F4=Detail"    , GRA_CLR_DARKPINK , {||zeige_detail(@oDlg, @lDetail), SetAppFocus(oDlg)}                                     }, ;
            {"^F5="          , GRA_CLR_DARKGRAY , NIL                                                                                      }, ;
            {"^F6=s.Kd-dt."  , GRA_CLR_DARKPINK , {||MsgBox("Anderer Kunde"), SetAppFocus(oDlg)}                                           }, ;
            {"^F7="          , GRA_CLR_DARKGRAY , NIL                                                                                      }, ;
            {"^F8="          , GRA_CLR_DARKGRAY , NIL                                                                                      }, ;
            {"^F9=Status"    , GRA_CLR_DARKPINK , {||MsgBox("Status"), SetAppFocus(oDlg)}                                                  }, ;
            {"^F10=Arb.S."   , GRA_CLR_DARKPINK , {||MsgBox("Arbeitsscheine drucken"), SetAppFocus(oDlg)}                                  }, ;
            {"^F11="         , GRA_CLR_DARKPINK , NIL                                                                                      }, ;
            {"^F12=Bestellen", GRA_CLR_DARKPINK , {||MsgBox("Bestellung auslösen"), SetAppFocus(oDlg)}                                     } }

erzeuge_Funktionsleiste(@oDlg, aButton)

3) Die Funktionsleiste erstellen, über die letzte Zeile im Code oben. ich zeige hier nur den relevanten Codeteil aus "erzeuge_Funktionsleiste()" an, das mit Berechnen der Buttongröße etc. lasse ich mal weg:

Code: Alles auswählen

FOR i := 1 TO LEN(aButton)
    oBut := XbpPushButtonColor():New(odlg:drawingArea, , {nX,nY}, {nButtonBreite, 25})
    oBut:activate := aButton[i][3]
    oBut:create()
    //                 Beschriftung   Farbe          Bündig Schrift
    oBut:SetCaptionClr(aButton[i][1], aButton[i][2], .F., cFont)
    nX += nButtonBreite
    IF i = 11
       nX := 0
       nY := 25
    ENDIF
NEXT

Und das ist die Ausführung bei Drücken von F10, abgefragt in "Checkkeys()" ganz oben:

Code: Alles auswählen

   CASE nKey = xbeK_F10
        IIF(aButton[9][3] <> NIL, EVAL(aButton[9][3]), NIL)

Grundsätzlich geht es dabei um diese Sache aus dem Array aButton:

Code: Alles auswählen

{||positionen_bearbeiten(oDlg, Beleg_Kopfdaten->BK_BELEG, oHauptDlg), SetAppFocus(oDlg)}

Es wird also Aufgerufen die Funktion "positionen_bearbeiten". Übergeben werden:
oDlg: Der aktuelle Dialog
Beleg_Kopfdaten->BK_BELEG: Der aktuelle Datensatz für die Kopfdaten (um die richtigen Positionen für den zu erstellenden Browse rauszufiltern)
ohauptDlg: Der AppDesktop()

Nach Beenden des Positionen-Dialoges soll der Fokus wieder auf den aktuellen Dielaog gesetzt werden, daher noch das "SetAppFocus(oDlg)".

In allen anderen Funktionstasten in allen anderen Dialogen funktioniert das auch (wobei das hier der einzige ist, wo F10 wirklich etwas tut, die anderen Dialoge, wo F10 etwas bewirken sollte, sind noch nicht so weit). Nur hier macht F10 Schwierigkeiten. Indem zwar beleg_positionen() aufgerufen wird und auch alles korrekt durchgeführt wird wie in der Position beschrieben, also Erstellen aller angegebenen Xbparts etc. Aber dann der Fokus auf dem Menü steht.

Jan

[andreas]

Hallo Jan,

ich habe es gerade bei mir mit meiner Variante ausprobiert, wobei ich den Makro durch Aufruf eines Fensters ersetzt habe.
Ich rufe bei mir eine Funktion mit allen benötigten Parametern auf, wo dann ein Fenster erzeugt und Focus gesetzt wird.
Es funktioniert.
Bei dir Passt irgendwas mit dem Focussetzen nicht.

[Jan]

Hallo Andreas,

nun, in allen anderen Dialogen ist der Fokus korrekt. Nur hier nicht

Aber vielleicht ist das ja ein Fall für den 10.?

Jan

[andreas]

Hallo Andreas,

Aber vielleicht ist das ja ein Fall für den 10.?

Jan

Hallo Jan,

ich wollte es dir mit dem 10. vorschlagen, aber ich wusste nicht, wie eilig es für diech ist. Wir können dein Problem gerne bei unserem Treffen in der Frage/Problem-Stunde ansehen. Vielleicht hilft dir auch mein Beispiel aus dem Vortrag etwas weiter.

[AUGE_OHR]

moin,

1) Direkt nach Erzeugen des Dialoges die Tastenbedienungen abfragen:

Code: Alles auswählen

oDlg:Keyboard := {|nKey,y,Obj| Checkkeys(nKey, aButton)}                //Funktionstasten über Tastatur aufrufen

soweit ist alles richtig (wobei man auch die Childs des oDlg den Key Slot
verpassen sollte ...)

2) Danach Erstmal die Buttons erzeugen, inkl. was der Druck darauf jeweils bewirken soll

Code: Alles auswählen

aButton := {{"F2=Zurück"     , GRA_CLR_DARKBLUE , {||oDlg:destroy(), SetAppFocus(oAltBrowse)}                                              }, ;
...
            {"F10=Posit."    , GRA_CLR_DARKPINK , {||positionen_bearbeiten(oDlg, Beleg_Kopfdaten->BK_BELEG, oHauptDlg), SetAppFocus(oDlg)} }, ;
...
erzeuge_Funktionsleiste(@oDlg, aButton)

Ich würde die Funktion "erzeuge_Funktionsleiste(@oDlg, aButton)" ein
Array der "tatsächlichen" Button- Objecte zurück geben lassen sonst
musst die die später aus der oDlg:Childlist() wieder raussuchen.

3) Die Funktionsleiste erstellen, über die letzte Zeile im Code oben. ich zeige hier nur den relevanten Codeteil aus "erzeuge_Funktionsleiste()" an, das mit Berechnen der Buttongröße etc. lasse ich mal weg:

Code: Alles auswählen

FOR i := 1 TO LEN(aButton)
    oBut := XbpPushButtonColor():New(odlg:drawingArea, , {nX,nY}, {nButtonBreite, 25})
    oBut:activate := aButton[i][3]
    oBut:create()
    //                 Beschriftung   Farbe          Bündig Schrift
   oBut:SetCaptionClr(aButton[i][1], aButton[i][2], .F., cFont)
    nX += nButtonBreite
    IF i = 11
       nX := 0
       nY := 25
    ENDIF
NEXT

Und das ist die Ausführung bei Drücken von F10, abgefragt in "Checkkeys()" ganz oben:

Code: Alles auswählen

   
CASE nKey = xbeK_F10
        IIF(aButton[9][3] <> NIL, EVAL(aButton[9][3]), NIL)

und woher soll er nun das oDlg bekommen ? in deinem Array hast du
zwar "ein" oDlg wie bei zu create() erzeuge_Funktionsleiste(@oDlg,
aButton) vorhanden war, aber das muss nicht das aktuelle mehr sein.

Du solltest auch bei F10 keine "Aktion selbst" ausführen ( EVAL(aButton[9][3] )
sondern statt dessen einen Event an "den" Button senden und "den die
Arbeit" tun lassen ( oBut:activate := aButton[3] )

Grundsätzlich geht es dabei um diese Sache aus dem Array aButton:

Code: Alles auswählen

{||positionen_bearbeiten(oDlg, Beleg_Kopfdaten->BK_BELEG, oHauptDlg), SetAppFocus(oDlg)}

du hast doch den Codeblock in dem :aktivate slot, also warum rufst
du den per Event nicht einfach auf ?

Code: Alles auswählen

oDlg:Keyboard := {|nKey,y,Obj| Checkkeys(nKey, oDlg)} 
...
CASE nKey = xbeK_F10
    // angenommen "der" Button wäre der 10st "Child"
    PostAppEvent(xbeP_Activate,,,oDlg:Childlist()[10])

wenn du ein Array mit "Button" Objecten (nicht Array) hast :

Code: Alles auswählen

oDlg:Keyboard := {|nKey,y,Obj| Checkkeys(nKey, aoButton)} 
...

CASE nKey = xbeK_F10
    // angenommen "der" Button wäre der 10st "Child"
    PostAppEvent(xbeP_Activate,,,aoButton[10])

Also keine Fxx "selbst ausführen", sondern einen Event an "den" Button
senden und schon klappt es, denn wenn du es "nur" über de Maus machst
gibt es ja kein Problem, oder ?

gruss by OHR
Jimmy

[Jan]

Jimmy,

es tut mir ehrlich leid. Aber das hat im Resultat alles überhaupt nichts gebracht. F10 geht immer noch auf das Menü.

Übrigens: Dein

Code: Alles auswählen

PostAppEvent(xbeP_Activate,,,oDlg:Childlist()[10]) 

muß heißen

Code: Alles auswählen

PostAppEvent(xbeP_Activate,,,oDlg:drawingArea:Childlist()[10]) 

Jan

[AUGE_OHR]

hi,

es tut mir ehrlich leid. Aber das hat im Resultat alles überhaupt nichts gebracht. F10 geht immer noch auf das Menü.

Übrigens: Dein

Code: Alles auswählen

PostAppEvent(xbeP_Activate,,,oDlg:Childlist()[10]) 

muß heißen

Code: Alles auswählen

PostAppEvent(xbeP_Activate,,,oDlg:drawingArea:Childlist()[10]) 

hm ... aber bei allen anderen geht es ? ich kann mir nur vorstellen das
F10 "woanders" abgefangen wird ... evtl. mal mit "Eventspy" beobachten ?

... nur mal so gedacht : mach doch mal aus der F10 ein F12

gruss by OHR
Jimmy

[Jan]

Jimmy,

gerade bin ich endlich mal wieder zu dem Projekt gekommen. Mit F12 funktioniert das absolut tadellos. Genau sollte das sein.

Mit F10 geht ja eigentlich auch. Nur das eben der Fokus auf dem Menü liegt und nicht auf dem Browse.

Jan

[Lutz Rübe]

Hallo Jimmy,

ich "arbeite" ja noch sehr viel im Hybrid-Mode (Text-Mode mit "eingeworfenen" GUI-Elementen) und habe dabei das gleiche Problem.

Ich habe das insofern gelöst, als ich vor der DO WHILE - Schleife (bevor TBROWSE aufgerufen wird) folgenden Command eingeschoben habe:

Code: Alles auswählen

SET KEY K_F1   TO Inkey()
SET KEY K_F10  TO Inkey()

Das mag zwar nicht die feine und elegante Art sein, aber mir hat es in meinem Fall geholfen..

Vielleicht bringt Dich diese Idee auf die Lösung ?

Gruß
Lutz

[Manfred]

Hi Lutz,

nur ne kurze Frage: Wieso benutzt Du denn noch TBrowse(), wenn Du doch schon GUI Elemente einbaust?

[Jan]

Hallo Lutz,

das bringt nichts. SET KEY ist ja nicht mehr ganz State of the Art, insbesondere in GUI. Stattdessen nehme ich ja nach Jimmys Hinweis PostAppEvent. Was ja nun leider auch nicht den gewünschten Erfolg zeigt.

Jan

[brandelh]

SET KEY ist ja nicht mehr ganz State of the Art ... PostAppEvent

Hallo,

SET KEY TO definiert eine Funktion, die Aufgerufen wird falls eine Taste gedrückt wurde.
PostAppEvent() generiert einen Event, wie KEYBOARD einen Tastendruck generiert hat.

SetKey() und für GUI besser SetAppEvent() sind die Funktionen, welche statt SET KEY verwendet werden sollten. Eventuell kann man damit auch vorbelegte Keys abfangen (F1 und F10).

Ansonsten hilft nur der Eingriff in der Eventloop.
Dort kann man es auf jeden Fall !

[Jan]

Hubert,

ansich hast Du ja recht. Aber in diesem Fall hatte ich beides versucht und bin nach den Hinweisen von Jimmy bei PostAppEvent() gebliebn.

Vielleicht habe ich mich da etwas blöd ausgedrückt. Denn klar ist SetAppEvent der Ersatz für Set Key. Nur in diesem speziellen Fall, um den es in diesem Thread geht, mache ich es eben jetzt anders.

Jan

[brandelh]

Hi,

das Problem dass ich oben herauslese ist, dass man versucht z.B. durch den KeyBoard Codeblock die F10 Taste zu erkennen und dann darauf zu reagieren.

So kann das aber meiner Meinung nach nicht funktionieren, da alle Keys zuerst in die normale Verarbeitung kommen, bevor diese beim Keyboardcodeblock ankommen. F1 und F10 werden aber vorher schon verarbeitet und dann geschluckt.

Ich habe eben mal in einer meiner abgeleiteten SLE Klassen versucht was passiert. Normalerweise kommt man aus dem SLE nicht heraus ohne J oder N einzugeben. TAB oder ein anderer Buchstabe/Zahlen etc. gibt eine Fehlermeldung. F1 und F10 geben keine Fehlermeldung sondern F1 zeigt meinen Hilfehinweis (msgbox aus Eventloop) und F10 springt ins Menü !

Meine Funktion DoEventLoop() - irgendwo habe ich diese hier auch schon veröffentlicht - fängt den F1 und wenn man will auch den F10 ab und man kann dann bestimmen was geschehen soll.
Die gilt natürlich nur für GUI Anwendungen, bei XbpCRT() funktioniert es wie bisher.

Hier steht was zur Eventloop:
Artikel über Eventloops und meine Funktion die F1 Umlenkung zeigt.

[Jan]

Hallo Hubert,

ja, das ist das Problem. Ich habe das auch mal mit Deinem EventLoop versucht. Nur habe ich da leider ein Problem, das vermutlich aus purer wissensdefiziten besteht: Je nach Dialog wird eine andere Funktion mit F10 aufgerufen, oder auch mal garkeine. Und wie mache ich das dem EventLoop klar, was er denn nun genau machen soll?

Wie die Funktionstasten belegt werden bzw. die Tastendrücke ausgewertet werden ist ja oben beschrieben, ebenso die Entwicklung durch Jimmy zu dem aktuellen Stand.

Jan

[brandelh]

Hallo Jan,

in der eventloop ist der nEvent, 2 Parameter und das Controll, das den Event ausgelöst hat.

Man müsste jetzt prüfen, ob oXbp das Control oder schon das Menü ist (debugger). Wenn es das control ist, entweder den event abändern:

Event = keyboard, Taste = 10 -> nEvent := was auch immer
vorher set nEvent was auch immer -> was ich will...

oder aber in der eventloop das control abfragen:

case keyboardevent = F10
case oXbp = x1
....
case

oder man füllt den CARGO slot mit dem Codeblock ...

jetzt muss ich aber auf die Bahn rennen

[AUGE_OHR]

hi,

gerade bin ich endlich mal wieder zu dem Projekt gekommen. Mit F12 funktioniert das absolut tadellos. Genau sollte das sein.

aha, dachte ich es mir doch ...

da alle Keys zuerst in die normale Verarbeitung kommen, bevor diese beim Keyboardcodeblock ankommen. F1 und F10 werden aber vorher schon verarbeitet und dann geschluckt.

yup, das denke ich auch.
Statt das er "die" oDlg:CheckKeys() verarbeitet nimmt er anscheinend
deine (Main) Eventloop und fängt dort F10 ab.

workaround : "der" oDlg bekommt einen "eigenen" (Sub)Eventloop

gruss by OHR
Jimmy

[Jan]

Hi Jimmy,

aha, der Arbeitstag beginnt wieder?

Nun, die Möglichkeit mit einem eigenen EventLoop je Dialog hatte ich irgendwann früher mal verworfen. Das war ungefähr zu der Zeit wo ich die entsprechende Frage im Forum gestellt hatte. Das hatte nämlich merkwürdige Nebeneffekte (frag mich jetzt nicht was das noch war). Aber ich will das gerne noch einmal versuchen und melde dann, wie das läuft.

Aber nur zum Verständnis: Ich baue also in jeden Dialog, der diese Funktionstastenleiste hat, einen eigenen EventLoop ein, der genau diese 22 Tastendrücke abfragt? Und da Hubert darauf aufmerksam gemacht hat, das mit absolut jedem Ereignis diese Schleife durchlaufen würde mit entsprechendem Performanceeinbruch 1 generelle Abfrage davor setzen, ob eine Funktionstaste gedrückt wurde?

Jan

[AUGE_OHR]

hi,

aha, der Arbeitstag beginnt wieder?

lebe eben (wieder) nach Shanghai Zeit ...

Nun, die Möglichkeit mit einem eigenen EventLoop je Dialog hatte ich irgendwann früher mal verworfen

stimmt du verwendest ja (noch) keine zusätzlichen Threads

Aber nur zum Verständnis: Ich baue also in jeden Dialog, der diese Funktionstastenleiste hat, einen eigenen EventLoop ein, der genau diese 22 Tastendrücke abfragt?

Ich weiss jetzt nicht was du schon umgebaut hast, aber in der ersten
Version hattes du eine Funktion "Checkkey" für alle oDlg. In "Checkkey"
wurde nun ein Array übergeben was dann den entsprechenden Codeblock
evaluieren sollte. Da aber alle oDlg die Funktion benutzen bin ich mir nicht
sicher ob der Parent bzw. Focus-Parent wirklich in der Situation stimmt.

Ich nehme für jedes oDlg ein STATIC FUNCTION "Checkkey"(nkey,oDlg)
wobei ich immer noch explizit "oDlg" angebe den dann hab ich "bestimmt"
das "oDlg:Childlist()" und kann dann per

Code: Alles auswählen

CASE nkey == xbeK_F10
   PostAppEvent(xbeP_Activate,,,oDlg:drawingArea:Childlist()[10])

auch wirklich "das" 10st Element auf "dem" oDlg:drawingArea aktivieren.

gruss by OHR
Jimmy

[brandelh]

Hallo Jan,

dein Problem ist, dass Windows einige Tasten anders benutzt, als du es haben willst. Mit der Eventloop kann man sowas umbiegen, aber du willst natürlich nicht das ganze Programm umschreiben, also es könnte so gehen:

Code: Alles auswählen

#define nBenutzer_F10 (xbeP_User+1)
...
// in jeder gewünschten Funktion
SetAppEvent( nBenutzer_F10, {|| F10_Funktion() } ) // Benuterdefinierter Event ! 
...
im loop
...
DO WHILE nEvent <> xbeP_Close    // Ereignis xbeP_Close ab 
      nEvent := AppEvent( @mp1, @mp2, @oXbp ) 
      do case
           case nEvent = xbeP_Keyboard .and. mp1 = xbeK_F10
                nEvent := nBenutzer_F10   // Event umbiegen auf Benutzerereignis
           case ...
           ...
      enddo
      oXbp:handleEvent( nEvent, mp1, mp2 )
ENDDO

[andreas]

Hallo Jan,

ich habe für den 10.02. in meinem Beispiel zum Vortrag deine F10 zum Aufrufen eines Fensters eingebaut. Vielleciht kann es dir weiter helfen.
Normaler weise schreibe ich in meinen Anwendungen für ein Fenster, dass die F-Tasten braucht, eigene Methode die mit ::keyboard bestimmt wird. Dann kann ich in jedem Fenster die gleichen Tasten wieder evtl. für die anderen Funktionen verwenden und brauche meine Event-Schleife nicht zu verändern. Es ist auch z.B. für die Erstellung von Modulen (DLLs) interesant.

[Jan]

So. Ich habe heute morgen im Zug mal schnell den Eventloop eingebaut. erstmal aus Zeitgründen nur in 2 Dialoge, davon natürlich einer der betreffende mt dem F10-Problem. Zumindest DAS Problem ist damit gelöst!

Ein anderes ist aufgetaucht, das konnte ich aus genannten Zeitgründen noch nicht genau eingrenzen.

Aber erstmal ist wenigstens das Frust-Problem weg. Das hat mich inzwischen echt geschafft. Wenn das korrekt läuft werde ich die Lösung hier angeben.

Andreas: Trotzdem würde ich mir natürlich auch gerne Deine Lösung nächste Woche ansehen. Vielleicht kann ich ja noch etwas verfeinern danach.

Jan

[andreas]

Hallo Jan,

hast du deine Eventloops in eigenen Threads eingebaut? Sonst könnte es zu Problemen führen, wenn du in einem Programm mehrere Event-Schleifen hast.

[Jan]

Andreas,

Du verblüffst mich immer wieder.

Nein, habe ich nicht. Nach den Ausführungen von Hubert in dem entsprechenden Thread dachte ich, das ginge auch so.

Was für Probleme tauchen denn da auf?

Jan

[brandelh]

Hallo Jan,

ich habe nicht geschrieben, dass man mehrere Eventloops machen soll.
Ich habe genau einen Eventloop, nur liegt dieser in einer Funktion, die zeitgesteuert (nur 1/10 Sekunde lang) zusätzlich aufgerufen werden kann.

Mein Beispiel oben wird natürlich im Haupt-Eventloop eingebaut und biegt nur einen event (F10) der ans Menü weitergegeben würde auf einen eigenen um, der dann reagiert wenn man auf F10 gedrückt hat.