| |
|
|
E.T. | Können nproc und Hauptfenster miteinander kommunizieren ??
Teilweise schon, denk ich: Ein Fortschrittsbalken auf dem HWND wird vom nproc richtig "fortgeschritten" (per Sendmessage an den Balken). Also können Balken und nproc "miteinander reden".
Aber sobald das HWND einmal verdeckt war, passiert nix mehr (leeres, weißes Fenster). Es kommt keine Aktualisierung des Fensters mehr !!
Muss ich jetzt das Fenster selbst (z.B. per Message) zu neuzeichnen auffordern ??
Ähnlich verhält sich das Fenster-Menü: Bei klick auf das Kreuz (Schließen) sagt das Profan-Prog: "Keine Rückmeldung", wenn es im nproc ist.
Muss ich z.B. alle Menüs im nproc nochmal auswerten ??
Fragen über Fragen... |
|
|
| 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... | 14.04.2010 ▲ |
|
|
|
|
| Hallo E.T.,
es ist so einfach, es gibt so gesehen keinen Unterschied, ob Du aus Proc oder NProc heraus arbeitest.
Du kannst ganz "normal" in NProcs mit Handles spielen, wie es Windows und XProfan vorsieht.
Etwas schwierig wird es jedoch, wenn Du aus Threads heraus mit Handles spielen willst, die aber per anderen Thread erzeugt wurden - hier erlauben die verschiedenen Windows-Versionen unterschiedlich.
>> Muss ich jetzt das Fenster selbst (z.B. per Message) zu neuzeichnen auffordern ??
Nein, ganz normal - wie sonst auch - bzw. "garnicht".
>> Muss ich jetzt das Fenster selbst (z.B. per Message) zu neuzeichnen auffordern ??
Nein, nur, wenn Du es per Proc auch würdest.
>> Ähnlich verhält sich das Fenster-Menü: Bei klick auf das Kreuz (Schließen) sagt das >> Profan-Prog: "Keine Rückmeldung", wenn es im nproc ist.
Das ist doch auch "normal" und nicht anders, als wenn sich das Programm in einer Proc befindet.
Vlt. kommt bei einer Proc nicht gleich die Anzeige, dass der Prozess nicht rückmeldet, weil XProfan alle X Zeilen Nachrichtenabrufe zwischenschiebt - aber hier reagiert ja "XProfan" "abweichend".
>> Fragen über Fragen...
Die ich alle gerne beantworten möchte, einfach um auch selbst sehen zu können, ob und wo noch Schwachstellen vorhanden sind.
Wenn etwas konkretes nicht klappt, wovon Du aber meinst, dass es funktionieren sollte, dann einfach fix einen kleinen Code posten, dass ich ggf. handeln kann. ^^ |
|
|
| |
|
|
|
E.T. | Hab mal am MB gebastelt: KompilierenMarkierenSeparieren {$IQ}
{$CLQ}
Def @Createwindowex(12) !"USER32","CreateWindowExA"
Def @Setparent(2) !"USER32","SetParent"
Declare Status&, St_Bereich#, Progress&, Classname$
Proc Status_Progress
Dim ST_Bereich#, 8
Long ST_Bereich#,0 = Width(%HWnd)-100, -1
Status& = @Create("StatusWindow",%HWND,"",2,St_Bereich#)
SetText Status&, 0, "Warte"
SetText Status&, 1, Date$(0)
Classname$="msctls_progress32"
Progress&=@Createwindowex(0,@Addr(Classname$),0,$40000000,3,@Height(%HWnd)-50,@Width(%HWnd) - 6,25,%Hwnd,0,%Hinstance,0)
@Setparent(Progress&,%HWnd)
@Showwindow(Progress&,1)
Endproc
Proc Durchlauf_1
Whileloop 1000
sleep 10
@Sendmessage(Progress&,$0400+2,100/1000*(&loop+1),0)
EndWhile
@Sendmessage(Progress&,$0400+2,0,0)
EndProc
nProc Durchlauf_2
global Progress&
Whileloop 1000
~RedrawWindow(%HWnd, 0, 0, ~RDW_FRAME | ~RDW_INVALIDATE | ~RDW_ALLCHILDREN | ~RDW_UPDATENOW | ~RDW_INTERNALPAINT)
~RedrawWindow(Progress&, 0, 0, ~RDW_FRAME | ~RDW_INVALIDATE | ~RDW_ALLCHILDREN | ~RDW_UPDATENOW | ~RDW_INTERNALPAINT)
sleep(10)
Sendmessage(Progress&,$0400+2,int(100.0/Float(1000)*Float(&loop)),0)
EndWhile
Sendmessage(Progress&,$0400+2,0,0)
EndProc
Window 800,120
WindowTitle "nProc - Message - Test"
CLS ~Getsyscolor(15)
Status_Progress
SetText Status&, 1, "Arbeite..."
SetText Status&, 0, "Durchlauf 1 ...bitte warten !!"
Durchlauf_1
SetText Status&, 0, "Durchlauf 1 (PROC) Fertig !!"
Sleep 500
SetText Status&, 0, "Durchlauf 2 (nPROC) ...bitte warten !!"
Durchlauf_2()
SetText Status&, 0, "Durchlauf 2 (nPROC) Fertig !!"
SetText Status&, 0, "Warte..."
waitinput
Dispose ST_Bereich#
end
Solange das Prog im Durchlauf_1 (Proc), kann ich das Fenster beliebig verdecken, verschieben etc., XProfan kümmert sich ja ums neuzeichnen.
Im Durchlauf_2 (nProc) wird nach mehrmaligem "verdecken" des Fensters einfach nix mehr aktualisiert, selbst das ~RedrawWindow(%HWnd... scheind nicht mehr anzukommen. Bleibt das Fenster die ganze Zeit sichtbar, flackerts natürlich sehr schön (am auswerten von %wmpaint im nproc bin ich gescheitert ).
Wer "verschluckt" das neuzeichnen (nproc ?, XProfan ?, Windows ?) ??
(Getestet unter XP) |
|
|
| 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... | 14.04.2010 ▲ |
|
|
|
|
| Unwichtig aber statt Global würde ich Progress& einfach als Funktionsparameter übergeben - zum Problem: Du machst im Prinzip 1000 mal Sleep(10) - in dieser Zeit ist der Prozess/ (Haupt)Thread sprichwörtlich "beschäftigt" bzw. dank Sleep sogar "gesperrt" - Windows wird da kaum die Möglichkeit haben, das Fenster zu zeichnen, auch weil die UI-Anzeige ziemlich passiv von Windows abgearbeitet wird bzw. versetzt dann, wenn grad Zeit ist.
Quasi gibst Du Windows in dieser Schleife keine Chance, es reagiert hier "korrekt" bzw. wie erwartet - wenn auch vlt. nicht unbedingt "wie erwünscht". ^^
Hier würde ich eher per ~SetTimer-Api auf eine NProc zeigen, die halt einfach nur den SendMessage absetzt, ohne Schleife.
Salopp gesprochen: Machst Du also aus einer XProfan-Funktion heraus lauter SetText, so kannst Du wohl nebenher zuschauen - machst Du dies aus einer NProc heraus - so geht dies so fix, dass Windows-UI nicht hinterherkommt, besonders auch weil nicht z.B. alle "20 Zeilen" Nachrichten abgeholt/ verarbeitet werden sondern tatsächlich nur das getan wird, was angewiesen ist.
Ein Irrglaube ist vlt. auch, dass Sleep dem Prozess/ Thread "Zeit" gibt - tatsächlich ist es eher so, dass Sleep die Zeit stiehlt, weil in dieser Zeit der Thread eher "totgestellt" ist. |
|
|
| |
|
|
|
E.T. | Hab ich wohl das MB "etwas doof" gestaltet: Im richtigen Progg steht natürlich kein sleep , hab ich nur ins MB eingebaut, damit man Zeit zum testen hat. Eigentlich führe ich in der Schleife (viele,viele) String-Vergleiche durch. Der Effekt ist aber der gleiche wie mit sleep.
Wünschenswert wäre mir eine einfach Abfrage ala KompilierenMarkierenSeparieren Aber komm ich im nProc an %wmpaint vom XProfan-Fenster ran ?? Ich denk, dann wäre mir geholfen Dann müsste ich Windows nicht in jeden Schleifen-Durchlauf mit einer Neuzeichnen - Message "zuballern". |
|
|
| 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... | 15.04.2010 ▲ |
|
|
|
|
| >> Im richtigen Progg steht natürlich kein sleep , hab ich nur ins MB eingebaut, >> damit man Zeit zum testen hat.
Ich verstehe, nur, dass eben Sleep hier eigentlich keine Zeit schenkt sondern nur welche kostet - also diesem Thread keine Zeit schenkt, etwas zu erledigen. ^^
>> Eigentlich führe ich in der Schleife (viele,viele) String-Vergleiche durch. Der Effekt >> ist aber der gleiche wie mit sleep.
Klar, ob Du tausende Male s$=s$+"Hallo" machst, oder Sleep(... in beiden Fällen ist der Thread nicht mit Fensterzeichnerei beschäftigt.
>> Aber komm ich im nProc an %wmpaint vom XProfan-Fenster ran ?? Ich denk, dann wäre mir geholfen
%wmPaint wird vlt. von der WProc gesetzt, ob halt die Nachricht wm_paint ankam - Du könntest einfach das hWnd subclassen - aber der Weg wird ja immer länger damit.
>> Dann müsste ich Windows nicht in jeden Schleifen-Durchlauf mit einer Neuzeichnen - >> Message "zuballern".
Von einem GetMessage etc. habe ich bisher abgesehen, weil ich z.B. nicht gestackte UserMessages abtragen möchte - ich lasse mir etwas einfallen. |
|
|
| |
|
|