XProfan

Deutsch

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 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

- Seite 1 -

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.

XProfan X2
WinXP, SP3, Core(TM) i7-3770 @ 3.40GHz

06.11.2014 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

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 X2
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 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

Ich verstehe die Frage nicht.

Die Usermessage durchbricht waitinput und wäre hierfür sinnvoller als ein Timer.

XProfan X2
WinXP, SP3, Core(TM) i7-3770 @ 3.40GHz

06.11.2014 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

E.T.

Habs jetzt mal per Usermessage gemacht:
Kompilieren Markieren Separieren

 {$IQ}
Declare ProgEnde%

Proc BlinkWindow

    Parameters Fenster&

    WhileLoop 3

        ~FlashWindow(Fenster&, 1)
        sleep 50

    EndWhile

    ~SetActiveWindow(Fenster&)

    If GetFocus(%HWnd)

        print "Wieder aktiviert..." + Time$(0)

    EndIf

EndProc

WindowStyle 8+512+16
WindowTitle "Testfenster"
Window 800,600
SetWindowPos %HWnd = %WinLeft,%WinTop - 800,600;-1
CLS GetSysColor(15)
UserMessages ~wm_killfocus

WhileNot ProgEnde%

    Waitinput
    Case %UMessage : BlinkWindow(%HWnd)

    If %Key = 2

        ProgEnde% = 1

    EndIf

EndWhile

end

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 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

Warum immer sleep, das ist kontraproduktiv:
Kompilieren Markieren Separieren

WhileLoop 3

    ~FlashWindow(Fenster&, 1)
    sleep 50

EndWhile

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.

XProfan X2
WinXP, SP3, Core(TM) i7-3770 @ 3.40GHz

06.11.2014 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

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 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

Einfach ein neues Fenster, neuen Prozess oder neues Windows erzeugen!?!

XProfan X2
WinXP, SP3, Core(TM) i7-3770 @ 3.40GHz

07.11.2014 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

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

XProfan X3
Windows7 Xprofan 8,9,10 [...]

[...]

07.11.2014 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

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?

XProfan X2
WinXP, SP3, Core(TM) i7-3770 @ 3.40GHz

09.11.2014 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

E.T.

So, habs mal mit 'nem neuen Fenster probiert,
doch irgendwie das gleiche Verhalten:
Richtig aktiviert wird das HWnd nur beim ersten Durchlauf

Kompilieren Markieren Separieren

 {$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 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

Und wenn Du mal in Deiner BlinkWindow als erstes setforegroundwindow hwnd und danach(!) setactivewindow hwnd machst?

Stehen hier [...]

Gründe für dieses Verhalten?

XProfan X2
WinXP, SP3, Core(TM) i7-3770 @ 3.40GHz

10.11.2014 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

- Seite 2 -

E.T.

iF (10.11.14)

Und wenn Du mal in Deiner BlinkWindow als erstes setforegroundwindow hwnd und danach(!) setactivewindow hwnd machst?

Bringt auch nix. Hab aber selbst bei Win-internen Proggs festgestellt, das selbst da Fenster nicht immer zwingend im Vordergrund bleiben bzw. geholt werden, selbst wenn diese dringend auf eine Eingabe warten.

Naja, was solls. Warte ich auf das Profan für Android. Da kann man das Smartie auch mal schütteln, bis es macht, was es soll

, PC und Monitor sind dafür zu unhandlich

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...

07.12.2014 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

◄