| |
|
|
E.T. | Es ist wieder mal so weit, bin am verzweifeln:
Gibt es es eine Möglichkeit (in XProfan) festzustellen, wenn ein (Haupt-) Fenster den Focus verliert, z.B. an das aufrufende (nicht-profan-) Programm oder den Desktop ?? Mein (einziges) Programm-Fenster ist Top-Most, aber trotzdem möchte ich gern wissen, wenn das Fenster verlassen wird.
Habs jetzt im Moment so, das per waitinput 2000 geprüft wird, welches Fenster den Focus hat, gefällt mir aber nicht wirklich ...
Noch besser wäre nat., die ID des aufrufenden Programm's zu kennen, dann könnte ich gezielter darauf reagieren ...
...oder gibt es eine Message in XProfan, wenn das Fenster verlassen wird ? Dös wär's natürlich |
|
|
| Grüße aus Sachsen... Mario WinXP, Win7 (64 Bit),Win8(.1),Win10, Win 11, Profan 6 - X4, XPSE, und 'nen schwarzes, blinkendes Dingens, wo ich das alles reinschütte... | 06.11.2014 ▲ |
|
|
|
|
| Auf jeden Fall wirst Du eine UserMessage benötigen weil auch das in XProfan eingebaute SubClassing nicht so zuverlässig ist wie eine XProfan UserMessage. Probiere mal wm_activate aber vlt. tuts auch wm_killfocus. |
|
|
| |
|
|
|
E.T. | bleibt aber die Frage der Abfrage: wäre eine Message, welche ein waitinput durchbricht, angebracht bzw. nötig, um nicht irgendeinen Timer im Prog rödeln zu lassen |
|
|
| XProfan X2Grüße aus Sachsen... Mario WinXP, Win7 (64 Bit),Win8(.1),Win10, Win 11, Profan 6 - X4, XPSE, und 'nen schwarzes, blinkendes Dingens, wo ich das alles reinschütte... | 06.11.2014 ▲ |
|
|
|
|
| Ich verstehe die Frage nicht.
Die Usermessage durchbricht waitinput und wäre hierfür sinnvoller als ein Timer. |
|
|
| |
|
|
|
E.T. | Habs jetzt mal per Usermessage gemacht: KompilierenMarkierenSeparieren Jetzt nur die Frage: Warum funzt ~SetActiveWindow(Fenster&) nur 1x (Fenster blinkt und wird aktiviert, Taskleiste kurz da und wieder ausgeblendet), danach wird irgendwas "verschluckt": Meine (ausgeblendete) Taskleiste ploppt hoch und zeigt mir die Aktivierung von "Testfenster" an (also irgendwas kommt an), aber das Fenster wird nicht aktiviert (wird doch nicht...ne...am SetActiveWindow liegen...)
Irgendwo war ich da schon mal drüber gestolpert... ...und irgendwo hier in der Nity gibt 'nen Code, um Fenster "sicher" zu aktivieren, gleich mal suchen...
...war doch "nur " in den Vordergrund: [...] |
|
|
| Grüße aus Sachsen... Mario WinXP, Win7 (64 Bit),Win8(.1),Win10, Win 11, Profan 6 - X4, XPSE, und 'nen schwarzes, blinkendes Dingens, wo ich das alles reinschütte... | 06.11.2014 ▲ |
|
|
|
|
| Warum immer sleep, das ist kontraproduktiv: KompilierenMarkierenSeparieren Da steht auf Deutsch: Mache FlashWindow aber gibt dem Prozess keine Zeit für FlashWindow. Wird also Windows-Version-Abhängig sein wann und wie und ob das funzt. Keine gute Lösung! Eher noch WaitInput 50 solange wie Zeit-X nicht erreicht ist z.B. per getTickCount.
Das in den Vordergrundsetzen ist auch nicht so leicht windowsversionenübergreifend denn irgendwann (ab Vista?) meinte MSDN dass dies nur noch der eigene Prozess für eigene Fenster tun soll wenn ein Fenster des Prozess selbst aber bereits schon den Fokus hat. Ging man also ein bisl weg davon das ein Prozess der Fenster hat die alle kein Focus haben sich selbst in den Vordergrund bringen soll. Irgendwie half da immer nur Herumprobiere sodass es auf allen Windows-Versionen gleichermassen funktioniert. Lästig! Aber erst per API eine Fensteranweisung geben und dann per SLEEP den Thread quasi "stoppen" ist nicht im Sinne des Erfinders. |
|
|
| |
|
|
|
E.T. | ja, sleep vermeide ich auch, ist aber halt in dieses Bsp. reingeraten (mit z.Bsp. waitinput 500 passiert aber das gleiche)
Ist nur doof, das da paar Win-Progger meinen, das ich nicht selbst bestimmen darf, das mein Fenster aktiviert wird und nur noch z.B. per Taskleiste darauf "hingewiesen" wird, das wohl mal ein (wichtiges ??) Programm die Aufmerksamkeit wünscht.
Ich will wieder 3.11, das beste Win, was es je gab
Nachtrag: Ist jetzt mal so 'ne Frage: Kann da Roland was an die (manchmal dümmliche) Entwicklung von Win anpassen, oder wie hoch wäre der Aufwand? Vlt. ist es doch besser, die W-Version auszulesen und dann das Prog anzupassen (XProfan-intern oder API nutzen).
Oder anders herum: Wie weit proggt man "abwärts-kompatibel", und wo sind da die Grenzen ?? XP ist ja noch weit verbreitet und wird es wohl auch noch 'ne Weile bleiben, da wäre es auch schade, wenn dies nicht mehr per XProfan unterstützt würde. |
|
|
| Grüße aus Sachsen... Mario WinXP, Win7 (64 Bit),Win8(.1),Win10, Win 11, Profan 6 - X4, XPSE, und 'nen schwarzes, blinkendes Dingens, wo ich das alles reinschütte... | 06.11.2014 ▲ |
|
|
|
|
| Einfach ein neues Fenster, neuen Prozess oder neues Windows erzeugen!?! |
|
|
| |
|
|
|
GDL | Hallöle,
dies hier :
Ist nur doof, das da paar Win-Progger meinen, das ich nicht selbst bestimmen darf
ärgert mich auch. Nur noch Multimedia Kisten.
Wir benutzen für Steuerungsaufgaben immer noch WInME und Win98. Da war man mit den Hardwarezugriffen nicht so eingeschränkt.
Grüßle Georg |
|
|
| |
|
|
|
| Da sich Windows entwickelt kann ja nicht alles beim Alten bleiben.
Wir Holzfäller haben es auch mit immer mehr Axt-resistenten Bäumen zu tun.
Nehmen wir halt die Kettensäge.
Ein neues Fenster erstellten, dass dann oben liegt, geht doch noch? |
|
|
| |
|
|
|
E.T. | So, habs mal mit 'nem neuen Fenster probiert, doch irgendwie das gleiche Verhalten: Richtig aktiviert wird das HWnd nur beim ersten Durchlauf KompilierenMarkierenSeparieren {$IQ}
Declare ProgEnde%, HelpWindow&
Proc BlinkWindow
Parameters Fenster&
WhileLoop 3
~FlashWindow(Fenster&, 1)
Waitinput 50'man soll ja keine Zeit stehlen !!
EndWhile
~SetActiveWindow(Fenster&)
EndProc
WindowStyle 8+512+16
WindowTitle "Testfenster"
Window 800,600
SetWindowPos %HWnd = %WinLeft,%WinTop - 800,600;-1
CLS GetSysColor(15)
WhileNot ProgEnde%
UserMessages ~wm_killfocus'Message setzen
Waitinput
If %UMessage = ~wm_killfocus
Usermessages 0'sonst Endlos-Schleife !!
HelpWindow& = Create("Window",%HWnd,"",0,0,10,10)
Case GetFocus(HelpWindow&) : Print "Hilfsfenster hat Focus"
BlinkWindow(%HWnd)
destroywindow(HelpWindow&)
Case GetFocus(%HWnd) : Print "Hauptfenster hat Focus"
ElseIf %Key = 2
ProgEnde% = 1
EndIf
EndWhile
end
|
|
|
| Grüße aus Sachsen... Mario WinXP, Win7 (64 Bit),Win8(.1),Win10, Win 11, Profan 6 - X4, XPSE, und 'nen schwarzes, blinkendes Dingens, wo ich das alles reinschütte... | 10.11.2014 ▲ |
|
|
|
|
| Und wenn Du mal in Deiner BlinkWindow als erstes setforegroundwindow hwnd und danach(!) setactivewindow hwnd machst?
Stehen hier [...] Gründe für dieses Verhalten? |
|
|
| |
|
|