Alaskas ColTest bzw. EditBrowse

[Jan]

Ich habe mal ein wenig mit \\Alaska\Samples\Solution\xbpget\Coltest und Editbrowse gespielt. Aber in einem Punkt stehe ich auf dem Schlauch.

Wie schaffe ich es, daß der Browse im Edit-Modus startet? Das ich nicht erst Enter oder eine Maustaste drücken muß.

Jan

[Martin Altmann]

Hallo Jan,
nun - sende doch einfach einen Mausklick oder ein Return an Dein Browseobjekt!?
Schau' mal bei PostAppEvent()...

Viele Grüße,
Martin

[Jan]

Hallo Martin,

hatte ich schon versucht, und hat nichts gebracht.

Ich denke aber ich weiß, woran das liegt: Ich habe das Beispiel in meinen eigenen Code übernommen. Und da stimmt irgendetwas mit dem Fokus nicht: Wenn ich nach dem Öfnen des Browses Enter oder CursorAb drücke, dann geht ein Systemmenü auf. Egal was ich da auswähle (Minimieren, Schließen, etc.) - eigentlich passiert nichts.

Irritierend ist für mich, daß der Fokus eindeutig auf dem Browse liegt, SetAppFocus() gibt mir den ganz klar zurück. Woher also kommt dieses Systemmenü? Ich bekomme das Teil einfach nicht weg

Jan

[Martin Altmann]

Hallo Jan,
kannst Du Deine Sourcen mal zippen (oder zumindest ein lauffähiges Progrämmchen mit dem entsprechenden Problem extrahieren) und zum download bereitstellen?
Dann kann man sich das mal anschauen - vielleicht sieht ja jemand, woran es liegt...

Viele Grüße,
Martin

[Jan]

Hallo Martin,

wenn sich jemand da durchkämpfen möchte...

Der Link ist hier. Achtung: Der Download ist 24 MB groß!

Das angesprochene Problem verbirgt sich hinter dem Button "Aufträge". Dann weiter mit F3 und F10. Hier klappt dann das Systemmenü aus bei Enter oder CursorAb. In dem Dialog nach F3 funktioniert SetAppFocus() einwandfrei. Halt nur nach F10 nicht mehr.

Bitte nicht irritieren lassen, das ganze ist noch Baustelle, wenig dokumentiert, unausgegoren, und meist erstmal nur Quick and Dirty zusammengestellt ohne Feinarbeit. Es geht dabei zuerst ausschließlich im die Machbarkeit, wie der Auftraggeber sich das vorstellt.

Die Buttonleisten lassen sich übrigens per Mausklick und per Tastatur bedienen, was eine der vielen Bedingungen zu diesem Programm ist.

Jan


PS: Das ganze ist unter 1.9 erstellt worden, die ausführbare Datei ist Quisy.exe. Die betreffende Datei ist BelegPositionen.prg, aufgerufen durch BelegKopfdaten.prg.

[Martin Altmann]

Hallo Jan,
ich habe mir Deine Exe mal kurz angeschaut und muß Dich enttäuschen - Dein SetAppFocus() scheint nicht richtig zu sein (habe noch nicht in die Sourcen geschaut). Das sieht man daran, dass auch bei Cursor rechts nichts passiert...
Setze ihn doch mal auf eine der Zellen und nicht auf das XbpBrowse-Objekt selber...

Viele Grüße,
Martin

BTW, die Beschriftungen der Buttons sind (fast) alle mehrfach verschieden überdruckt, so dass man fast nichts lesen kann - aber Du sagtest ja, dass es erst mal nur eine Machbarkeitsstudie sei...

[AUGE_OHR]

hi,

Das angesprochene Problem verbirgt sich hinter dem Button "Aufträge". Dann weiter mit F3 und F10. Hier klappt dann das Systemmenü aus bei Enter oder CursorAb. In dem Dialog nach F3 funktioniert SetAppFocus() einwandfrei. Halt nur nach F10 nicht mehr.

wie Martin schon sagte ist der focus wohl nicht richtig so. Die Frage ist
nun ob du ein "standart" XbpBrowse benutzt oder deine eigene Class ?

bei einem "standart" würde man ja SetAppFocus(oBrowse) verwenden,
aber bei meiner Class muss ich SetAppFocus(oBrowse:Browser) nehmen
um den oBrowse:Keyboard Slot ansprechen zu können.

ich werde mir mal deine Demo anschauen was die so macht.

gruss by OHR
Jimmy

[Gerd König]

Hallo Jan,

ein ähnliches Problem hatte ich mit dem Browser von XClass.

Es trat häufig dann auf, wennzwischenzeitlich ein anderes Applikationsfenster den Fokus hatte. Gelöst habe ich das Problem dadurch, daß ich den Fokus in zwei Schritten auf den Browser setze.

Code: Alles auswählen

 ......
 SetAppFocus(oDlg)
 SetAppFocus(oBrowser)
 .....

oDlg ist dabei das Dialogfenster, welches das Browserobjekt oBrowser enthält.

Grüße
Gerd

[Jan]

Moin Jimmy und Gerd,

nein, beides hat nichts geholfen.

Jan

[AUGE_OHR]

hi,

Das angesprochene Problem verbirgt sich hinter dem Button "Aufträge". Dann weiter mit F3 und F10. Hier klappt dann das Systemmenü aus bei Enter oder CursorAb.

Setze ihn doch mal auf eine der Zellen und nicht auf das XbpBrowse-Objekt selber...

also ich hätte da was :

Code: Alles auswählen

// Browser anzeigen und Focus geben
oDlg:show()
oBrowse:show()
SetAppFocus(oBrowse)

ALTD()
oSpalten :=oBrowse:getcolumn(1) 
SetAppFocus(oSpalten)

RETURN NIL

aber : das funktioniert nur wenn man F3, F10 mit der Maus geklickt hat !

In dem Dialog nach F3 funktioniert SetAppFocus() einwandfrei. Halt nur nach F10 nicht mehr.

das hab ich mir nun nicht angesehen was du damit meinst.

ein paar kleine Anmerkungen :

COMPILE_FLAGS = /ga /wi /wl /wu /b /q /w /o\OBJ\

ist beim compilieren zuständig während :

OBJ_DIR = E:\_JAN\Obj\

beim linken in dem Verzeichniss nach *.OBJ sucht.

XbpOfficeMenu.prg : ist dir aufgefallen das die Parameter "anders" über-
geben werden wie bei einem "normalen" XbpMenu() ? Damit ist es leider
nicht "abwärtz" kompatible in man kann nicht einfach durch ein #translate
ein "normales Menu upgraden".

ich habe deshalb die "original" Ownerdraw Menu Version genommen und
die mit den "Office Futures" aufgebohrt sodas die "abwärtz" kompatible ist.

noch ein Focus Problem besteht beim "umschalten" auf eine andere
Application den dein Programm scheint kein o:SetInputFocus(...oldFocus)
zu setzen wenn man zu deiner Application "zurück" kommt.

anzumerken sind "komische" Abstürze ... nix XppFatal oder so ... ?

sieht aber toll aus !

gruss by OHR
Jimmy

[Jan]

Hallo Jimmy,

danke fürs Durchsehen.

1) Ja, mit der Maus ist das alles kein Problem. Denn dann setze ich den Fokus ja beim Anklicken. Mausklick ist ja praktisch Fokus setzen und Funktion auslösen in Einem. Aber es soll eben auch mit der Tastatur funktionieren, wie sonst auch überall in dem Programm.

2) Nun, das mit dem Office-Menü ist mir nicht aufgefallen. Ich habe das erstmal einfach nur von der DevCon übernommen, ohne mich da groß einzulesen.

3) o:SetInputFocus(...oldFocus). Das verstehe ich jetzt nicht wirklich. Ich habe allerdings gestern Abend noch einige SetAppFocus() eingebaut in die Menüstruktur. Nachdem Andreas mir den entscheidenden Hinweis gegeben hatte. Denn einige Funktionen kann man über das Menü aufrufen auch wenn gerade eine andere Funktion am Laufen ist. Da gab das vorher immer Fokusprobleme, die damit behoben sind.

4) Nein, Abstürze habe ich sonst keine. Allerdings verwende ich auch nicht die aktuellsten Dateien von Alaska sondern die beiden noch aktuelleren,die Du auch kennst.

5) Optik. Danke für die Blumen. Aber wie gesagt, ist bei weitem noch nicht fertig, erstmal zum Zeigen für den Auftraggeber.

Jan

[AUGE_OHR]

hi,

1) Ja, mit der Maus ist das alles kein Problem. Denn dann setze ich den Fokus ja beim Anklicken. Mausklick ist ja praktisch Fokus setzen und Funktion auslösen in Einem. Aber es soll eben auch mit der Tastatur funktionieren, wie sonst auch überall in dem Programm.

in der "original" version kannst du nach F3 click, F10 click nicht mit Enter
weiter. mit meiner version geht er bei Enter in die erste Zelle, aber eben
nur wenn F3 / F10 geclickt wurde.

sondern die beiden noch aktuelleren

yup die fahre ich auch ... sagte doch schon damals "wie sollen wir uns
sonst unterhalten wenn wir verschiedene Versionen haben ...".

gruss by OHR
Jimmy
gruss by OHR
Jimmy

[Jan]

Hallo Jimmy,

da stellen sich mir doch 2 Fragen:

- Was ist an einem Mausklick anders als am Tastaturdrücken?
- Wo zum Donnerwetter ist der Fokus? Der ist doch definitiv auf dem Browse, oder? Warum reagiert der also nicht?

*Frust!*

Jan

[AUGE_OHR]

hi,

- Was ist an einem Mausklick anders als am Tastaturdrücken?

tja das wüsste ich manchmal auch gerne ...

wenn ich das im Debugger richtig gesehen habe wird die Funktion
Checkkeys() durchlaufen. In der gibt es die Function (?) "UNUSED" ?
Ich finde die Function "UNUSED" aber nicht sodas ich nicht sagen kann
ob dort der Focus auf oDlg gesetzt wird oder nicht.

- Wo zum Donnerwetter ist der Fokus? Der ist doch definitiv auf dem Browse, oder? Warum reagiert der also nicht?

ich denke es hängt an dem Checkkeys() welche du für den oDlg:Keyboard
verwendest. Dort gibt es ein "UNUSED(oDlg)". Wird da vielleicht ein
SetAppFocus() gemacht ?

Was mir fehlt ist der oDlg:SetInputFocus den ich nutzten würde um den
Focus auf den oBrowse zu legen, sobald man den oDlg "sieht", damit man
gleich "lostippen" kann.

gruss by OHR
Jimmy

[Jan]

Jimmy,

am Unused() kann es eigentlich nicht liegen. Das ist einzig dazu da, damit /wu keine Meldung gibt. Schau Dir mal das Ende von http://www.xbaseforum.de/viewtopic.php? ... ght=unused an. Mein Beitrag und die Antwort von Olaf darauf.

oDlg:SetInputFocus? wasisndas? Den Fokus lege ich doch mit SetAppFocus(oDlg) fest. Oder habe ich mal wieder was verpasst?

Jan

(Ich habe übrigens beide Punkte getestet. Nützt leider nichts. Ich bin ernsthaft am Überlegen mal die Jungs von Alaska zu fragen...)

[AUGE_OHR]

hi,

am Unused() kann es eigentlich nicht liegen. Das ist einzig dazu da, damit /wu keine Meldung gibt. Schau Dir mal das Ende von http://www.xbaseforum.de/viewtopic.php? ... ght=unused an.

hm ... verstehen tu ich es nicht. was soll den :

Code: Alles auswählen

#command UNUSED( <x> )       =>  <x> = <x>

"x = x" bringen ... ?

oDlg:SetInputFocus? wasisndas? Den Fokus lege ich doch mit SetAppFocus(oDlg) fest.

du kannst zwar den Focus am Anfang festlegen, aber wenn du z.B. zu
einer anderen Application wechselst dann hast du den Focus beim
zurück schalten ja nicht mehr. Also sollte man den Focus "sichern" und
ihn wieder aktivieren sobald der oDlg deiner Application wieder "sichtbar"
ist. Dies gilt auch auch für "eigene" Pop-Up Fenster wo ich gerne wieder
beim Ausgangspunkt bin von dem gestartet bin.

Code: Alles auswählen

FUNCTION blabla
LOCAL ...
STATIC oAlt := oBrowse:browser

oDlg := XbpDialog():New(....)
...
oDlg:killInputFocus := {| uNIL1, uNIL2, self | oAlt := SetAppFocus() }
oDlg:setInputFocus := {| uNIL1, uNIL2, self | SetAppfocus(oAlt) }
...
oDlg:Create()

nun noch mal zu dem Problem "Tastatur".

Code: Alles auswählen

{"F10=P.einf"    , GRA_CLR_BROWN    , {||MsgBox("Position einfügen"), SetAppFocus(oDlg)}             }

da ict das 3st. Element, was du in CheckKeys() evaluierst, ein SetAppFocus()
auf den oDlg ... nicht auf oBrowse !

gruss by OHR
Jimmy

[Rolf]

Hi Jan

Bei Dir ist mir aufgefallen das du wen das aButton erzeugt wird meistens im Activate-Slot

Code: Alles auswählen

{"F11=erste"     , GRA_CLR_BROWN    , {||oBrowse:GOTOP(), oBrowse:refreshall(), SetAppFocus(oDlg)}   }, ; 

stehen hast.

Das bedeutet doch das der Focus immer nur auf den Dialog zurück gesetzt wird. Ich nehme an das du im Keyboard-Slot nur die jeweiligen Funktionen aufrufst ohne den Focus um zu setzen. Richtiger wäre doch SetAppFocus(oBrowse) und nicht nur beim :show()

Das erklärt noch nicht das mit dem PostAppEvent(...) das müsste trotzdem funktionieren.

ich hab in das Editbrow.prg nur die folgende Zeile eingefügt und es war gleich der Cursor an

Code: Alles auswählen

   // Browser anzeigen und Focus geben
   oXbp:show()
   oBrowse:show()
   SetAppFocus( oBrowse )

PostAppEvent(xbeP_Keyboard,13,,oBrowse ) // <----------

   DO WHILE nEvent <> xbeP_Close
      nEvent := AppEvent( @mp1, @mp2, @oXbp )
      oXbp:handleEvent( nEvent, mp1, mp2 )
   ENDDO

Grüße Rolf

[Jan]

Jimmy,

hm ... verstehen tu ich es nicht. was soll den :

Code:

#command UNUSED( <x> ) => <x> = <x>

"x = x" bringen ... ?

Nichts. Soll es ja auch nicht. Es soll einfach "x" nutzen um beim Compilieren mit /wu keine Warnmeldung herauszugeben.

Wegen dem Fokus beim Zurückspringen: Das löse ich inzwischen anders. ich übergebe dem neu öffnenden Fenster den Fokus des aktuellen Fensters. und beim schließen des neuen wird der Fokus wiederhergestellt. Vielleicht nicht ganz so elegant wie deine Lösung, aber es funktioniert. Und wie gesagt: Dieses ganze Projekt ist noch Baustelle.

Jimmy und Rolf:

Daß ich beim Tastaturcode auf oDlg gehe darf doch eigentlich nichts damit zu tun haben. Denn das gilt für Bewegungen innerhalb des Browse (die übrigens auch so sehr gut funktionieren, interessanterweise). Abgesehen davon wird ja beim Betreten des Positions-Browses keine der Funktionstasten ausgelöst, so daß die da keine Rolle bei spielen dürften.

Es ist doch so, daß es insgesamt 2 Browses gibt: Erstmal den, in den man mit dem Buttonklick kommt. Und dann den fraglichen spinnenden. Für mich gibt es zwischen den beiden 2 Unterschiede: Der erste (Belegübersicht) wird grundsätzlich über einen Mausklick auf den Button aufgerufen, der andere (Positionen) auch über die Funktionstasten. Der erste ist einfach nur ein Browse, der zweite ist ein editierbarer Browse. Aber abgesehen davon sollte es eigentlich keinen Unterschied geben. Jedenfalls keinen, der das merkwürdige Verhalten erklären würde.

Jan

[Manfred]

Hi Jan,

das verstehe ich jetzt nicht. Wenn unused, warum dann noch im Quelltext belassen?

[Jan]

Hallo Manfred,

dafür gibt es mehrere Gründe:

In diesem speziellen Fall ist es so, daß oDlg im Funktionsaufruf übergeben wird. Aber in der betreffenden Funktion selber noch nicht bzw. nicht mehr benötigt wird. Also stört das beim Kompilieren, und somit UNUSED(oDlg).

Manchmal ist es aber auch so, das eine Variable in einer IF-Schleife verarbeitet wird, und sonst passiert damit nichts. Das erkennt der Compiler nicht und meckert die Variable ebenfalls an. Dann kann man gleich vorne im Code ein UNUSED(var) einbauen, und fertig ist die Sache. Hier ist allerdings in meinen Augen eine kurze Zuweisung bei der Deklaration besser, siehe nächsten Absatz.

Natürlich kann man auch einfach sagen var := "x". Damit ist die Variable ebenfalls genutzt und wird nicht angemeckert. Aber das macht es insgesamt unübersichtlicher. Denn dann kann man im Eifer des Gefechtes denken: Die wird genutzt, also fasse ich die nicht an. Und dann könnte ich /wu auch gleich weglassen. Aber bei UNUSED(var) weiß ich, daß ich da eventuell noch ein wenig aufräumen muß.

Das gilt natürlich nur für den Fall, das man im Compiler die Warnmeldungen für ungenutzte Variablen einschaltet. Sonst macht das natürlich keinerlei Sinn.

Jan

[AUGE_OHR]

hi,

Es ist doch so, daß es insgesamt 2 Browses gibt:

ich hab mir nun mal deinen Quellcode angesehen und denke ich weiss
jetzt warum ...

ich hab mal "spasseshalber" nach F10 / Enter aus dem "Menu" das
maximeiren/minimieren ausprobiert. Im Debugger kann man dann
was sehen, aber irgendwie war es nicht "das" Fenster ...

Du erstellt die "Fenster" ja mit QuisyDialog(). Dort ist aber weder Parent
oder Owner angegeben.
"schlimmer" aber ist das du scheinbar nicht die "alten" Fenster nicht
"verwaltest" sondern nur "übermalst". Das kann du ganz schnell testen
wenn du in QuisyDialog() als Parent mal AppDeskTop() nimmst. Dann
kannst du auch feststellen zu welches 4 "Fenster" das "Menu" gehört und
du landest nach F10 -> Enter auch da wo es sein sollte.

Frage : soll es eine SDI Anwendung werden oder MDI ?!

wenn MDI : wie will du z.b. auf das "normale" Menu in der Main reagieren ?
z.b. Auftrag -> F3 -> F10 -> Enter (angenommen es geht) und nun geht
der User "oben" in das Menu und wählt "Branche" ...

gruss by OHR
Jimmy

[Jan]

Hey Jimmy,

der Sinn der ganzen Sache ist ja, daß man in einem Modul sein kann und dennoch auch ein anderes, davon ganz unabhängiges Formular öffnen kann. Meist ist man halt in der Belegverwaltung, aber man kann eben schnell mal einen Artikel oder eine Adresse nachschlagen bzw. bearbeiten. Daher auch die Vorgehensweise, die Du schilderst

Auftrag -> F3 -> F10 -> Enter (angenommen es geht) und nun geht
der User "oben" in das Menu und wählt "Branche" ...

Den Teil habe ich übrigens überarbeitet, der Menüeintrag lautet jetzt

Code: Alles auswählen

oMenu1:addTextItem("Branchen",,,                      {|| Stamm_Branchen(SetAppFocus())})

damit ich nach Verlassen der Branche wieder den Fokus habe, den ich vorher auch hatte.

Mit AppDesktop() hast Du natürlich recht. Damit funktioniert es absolut wie es sollte. Funktionell gesehen. Optisch nicht, denn damit sind die einzelnen Fenster wieder auf BottomLeft gesetzt. Da stimmt doch wieder mal etwas nicht, das sollte doch eigentlich korrekt vererbt werden (daher ist das wohl noch nicht dokumentiert, auch wenn es eigentlich schon ganz gut funktioniert). Ob das mit dem Menü funktioniert muß ich noch testen, das ist jetzt erstmal verschwunden, vermutlich sind durch den Eintrag von AppDesktop() die Koordinaten verschoben.

Auf jeden Fall ein ganz großes Danke, daß Du Dir die Zeit genommen und Dich da reinvertieft hast.

Jan

[Jan]

So, ich glaube ich habe das Problem gefunden. Und brauche einen Tipp von Euch, wie ich das hinbekomme. Klar, was sonst? Aber ich denke, das geht einfach.

Nachdem ich alles durchprobiert habe, was Jimmy mir geraten hat, habe ich einerseits einiges "sauberer" programmiert. Das war sehr wichtig, und ohne Jimmys hinweise wären später sicher einige Probleme auf Grund einer verkorksten Basis aufgetaucht. Anderes war nicht wichtig, eher Verdachtsmomente, und hat auch nichts gebracht. Denn, und das hat Jimmy genauso wie ich nicht gemerkt, das Problem ist ein ganz anderes. Das ist kein Vorwurf, denn wir beide haben einen ganz falschen Weg "gesucht".

So, aber zu dem Problem: Die Grundlage war ja, daß in jedem Dialog oben eine Funktionstastenleiste existiert, die über die Funktionstasten F2 - F12 und ShiftF2 - ShiftF12 diverse Funktionen abruft. Und zwar sowohl durch Anklicken mit der Maus als auch durch Drücken auf der Tastatur. Und das Grundübel war, daß in einem bestimmten Punkt alles funktionierte wenn die Maus benutzt wurde, bei Tastaturbedienung aber zwar der nächste Dialog korrekt geöffnet wurde, bei einem weiteren Tastendruck aber nicht der eigentliche Fokus "Browse" darin bedient wurde sondern das Systemmenü. Gerade habe ich durch Zufall festgestellt, warum das so ist! Der neue Dialog hat als Aufruftaste die F10. Und was macht F10 unter Windows? Das Menü aufrufen! Das ist eine Standardfunktion, mein Programm hat sich also einfach nur Windowskonform benommen.

Und nun die Frage: Wie schalte ich diesen Windows-Konformismus ab? Ich möchte einfach erreichen, daß F10 KEIN Menü mehr aufruft. Schwierigkeit dabei: Den Umweg über einfach das Systemmenü abschalten geht nicht, das habe ich schon versucht. Denn es gibt eine Menüleiste, die auch funktionieren soll, das kann ich also nicht abschalten.

Jan

[brandelh]

Hi,

seht mal unter XbpCRT():useShortCuts nach, eventuell funktioniert das bei euch ja auch.

Ansonsten könnte man in der Eventloop zwischen

Code: Alles auswählen

nEvent := appevent....
if nEvent= ...
[color=red]   .. hier etwas anderes regeln und standardevent unterdrücken.[/color]
else
   :handleevent(nEvent...
endif

So lenke ich F1 um.

[andreas]

Hallo Jan, wenn du es global abschalten möchtest, solltest du denn Weg nehmen, den dir Hubert vorgeschlagen hat.

Wenn du es nur für ein bestimmtes Fenster machen willst, solltest du es bei dem Fenster abfangen.
Ungefähr so:

Code: Alles auswählen

Method Init...

::keyboard := {|nKey| ::Tasten(nKey) }

RETURN self

METHOD Tasten(Taste)

if taste == xbeK_F10                      //Weitersuchen
	&"{|| NIL }"	
endif

RETURN self