Alaskas ColTest bzw. EditBrowse
Moderator: Moderatoren
- Jan
- Marvin
- Beiträge: 14655
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Alaskas ColTest bzw. EditBrowse
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
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
- Foren-Administrator
- Beiträge: 16517
- Registriert: Fr, 23. Sep 2005 4:58
- Wohnort: Berlin
- Hat sich bedankt: 111 Mal
- Danksagung erhalten: 48 Mal
- Kontaktdaten:
Hallo Jan,
nun - sende doch einfach einen Mausklick oder ein Return an Dein Browseobjekt!?
Schau' mal bei PostAppEvent()...
Viele Grüße,
Martin
nun - sende doch einfach einen Mausklick oder ein Return an Dein Browseobjekt!?
Schau' mal bei PostAppEvent()...
Viele Grüße,
Martin
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/
Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
- Jan
- Marvin
- Beiträge: 14655
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
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
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
- Foren-Administrator
- Beiträge: 16517
- Registriert: Fr, 23. Sep 2005 4:58
- Wohnort: Berlin
- Hat sich bedankt: 111 Mal
- Danksagung erhalten: 48 Mal
- Kontaktdaten:
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
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
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/
Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
- Jan
- Marvin
- Beiträge: 14655
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
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.
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
- Foren-Administrator
- Beiträge: 16517
- Registriert: Fr, 23. Sep 2005 4:58
- Wohnort: Berlin
- Hat sich bedankt: 111 Mal
- Danksagung erhalten: 48 Mal
- Kontaktdaten:
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...
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...
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/
Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
- AUGE_OHR
- Marvin
- Beiträge: 12909
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
hi,
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
wie Martin schon sagte ist der focus wohl nicht richtig so. Die Frage istJan hat geschrieben: 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.
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
-
- Rekursionen-Architekt
- Beiträge: 193
- Registriert: Fr, 09. Jun 2006 7:52
- Wohnort: Nähe Sömmerda
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.
oDlg ist dabei das Dialogfenster, welches das Browserobjekt oBrowser enthält.
Grüße
Gerd
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)
.....
Grüße
Gerd
- AUGE_OHR
- Marvin
- Beiträge: 12909
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
hi,
aber : das funktioniert nur wenn man F3, F10 mit der Maus geklickt hat !
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 hat geschrieben: 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.
also ich hätte da was :Martin hat geschrieben: Setze ihn doch mal auf eine der Zellen und nicht auf das XbpBrowse-Objekt selber...
Code: Alles auswählen
// Browser anzeigen und Focus geben
oDlg:show()
oBrowse:show()
SetAppFocus(oBrowse)
ALTD()
oSpalten :=oBrowse:getcolumn(1)
SetAppFocus(oSpalten)
RETURN NIL
das hab ich mir nun nicht angesehen was du damit meinst.Jan hat geschrieben: In dem Dialog nach F3 funktioniert SetAppFocus() einwandfrei. Halt nur nach F10 nicht mehr.
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
- Marvin
- Beiträge: 14655
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
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
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
- Marvin
- Beiträge: 12909
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
hi,
weiter. mit meiner version geht er bei Enter in die erste Zelle, aber eben
nur wenn F3 / F10 geclickt wurde.
sonst unterhalten wenn wir verschiedene Versionen haben ...".
gruss by OHR
Jimmy
gruss by OHR
Jimmy
in der "original" version kannst du nach F3 click, F10 click nicht mit EnterJan hat geschrieben: 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.
weiter. mit meiner version geht er bei Enter in die erste Zelle, aber eben
nur wenn F3 / F10 geclickt wurde.
yup die fahre ich auch ... sagte doch schon damals "wie sollen wir unsJan hat geschrieben: sondern die beiden noch aktuelleren
sonst unterhalten wenn wir verschiedene Versionen haben ...".
gruss by OHR
Jimmy
gruss by OHR
Jimmy
- AUGE_OHR
- Marvin
- Beiträge: 12909
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
hi,
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.
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
tja das wüsste ich manchmal auch gerne ...Jan hat geschrieben: - Was ist an einem Mausklick anders als am Tastaturdrücken?
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.
ich denke es hängt an dem Checkkeys() welche du für den oDlg:KeyboardJan hat geschrieben: - Wo zum Donnerwetter ist der Fokus? Der ist doch definitiv auf dem Browse, oder? Warum reagiert der also nicht?
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
- Marvin
- Beiträge: 14655
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
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...)
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
- Marvin
- Beiträge: 12909
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
hi,
"x = x" bringen ... ?
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.
nun noch mal zu dem Problem "Tastatur".
da ict das 3st. Element, was du in CheckKeys() evaluierst, ein SetAppFocus()
auf den oDlg ... nicht auf oBrowse !
gruss by OHR
Jimmy
hm ... verstehen tu ich es nicht. was soll den :Jan hat geschrieben: 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.
Code: Alles auswählen
#command UNUSED( <x> ) => <x> = <x>
du kannst zwar den Focus am Anfang festlegen, aber wenn du z.B. zuJan hat geschrieben: oDlg:SetInputFocus? wasisndas? Den Fokus lege ich doch mit SetAppFocus(oDlg) fest.
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()
Code: Alles auswählen
{"F10=P.einf" , GRA_CLR_BROWN , {||MsgBox("Position einfügen"), SetAppFocus(oDlg)} }
auf den oDlg ... nicht auf oBrowse !
gruss by OHR
Jimmy
Hi Jan
Bei Dir ist mir aufgefallen das du wen das aButton erzeugt wird meistens im Activate-Slot
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
Grüße Rolf
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)} }, ;
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
- Jan
- Marvin
- Beiträge: 14655
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Jimmy,
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
Nichts. Soll es ja auch nicht. Es soll einfach "x" nutzen um beim Compilieren mit /wu keine Warnmeldung herauszugeben.hm ... verstehen tu ich es nicht. was soll den :
Code:
#command UNUSED( <x> ) => <x> = <x>
"x = x" bringen ... ?
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
- Foren-Administrator
- Beiträge: 21199
- Registriert: Di, 29. Nov 2005 16:58
- Wohnort: Kreis Wesel
- Hat sich bedankt: 210 Mal
- Danksagung erhalten: 67 Mal
Hi Jan,
das verstehe ich jetzt nicht. Wenn unused, warum dann noch im Quelltext belassen?
das verstehe ich jetzt nicht. Wenn unused, warum dann noch im Quelltext belassen?
Gruß Manfred
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
- Jan
- Marvin
- Beiträge: 14655
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
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
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
- Marvin
- Beiträge: 12909
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
hi,
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
ich hab mir nun mal deinen Quellcode angesehen und denke ich weissJan hat geschrieben: Es ist doch so, daß es insgesamt 2 Browses gibt:
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
- Marvin
- Beiträge: 14655
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
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 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
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
Den Teil habe ich übrigens überarbeitet, der Menüeintrag lautet jetztAuftrag -> F3 -> F10 -> Enter (angenommen es geht) und nun geht
der User "oben" in das Menu und wählt "Branche" ...
Code: Alles auswählen
oMenu1:addTextItem("Branchen",,, {|| Stamm_Branchen(SetAppFocus())})
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
- Marvin
- Beiträge: 14655
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
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
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
- Foren-Moderator
- Beiträge: 15697
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 66 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Hi,
seht mal unter XbpCRT():useShortCuts nach, eventuell funktioniert das bei euch ja auch.
Ansonsten könnte man in der Eventloop zwischen
So lenke ich F1 um.
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
Gruß
Hubert
Hubert
- andreas
- Der Entwickler von "Deep Thought"
- Beiträge: 1902
- Registriert: Mi, 28. Sep 2005 10:53
- Wohnort: Osnabrück
- Hat sich bedankt: 4 Mal
- Kontaktdaten:
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:
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