| |
|
|
 E.T. | pouvons nproc et la fenêtre principale miteinander kommunizieren ??
partiellement déjà, denk je: un Fortschrittsbalken sur dem HWND wird vom nproc richtig "fortgeschritten" (par mess à den poutre). alors peut poutre et nproc "miteinander reden".
mais sobald cela HWND einmal verdeckt était, passiert nix plus (leeres, weißes la fenêtre). Es venez aucun Aktualisierung des Fensters plus !!
Muss je maintenant cela la fenêtre selbst (z.B. per Message) trop neuzeichnen auffordern ??
Ähnlich verhält sich cela la fenêtre-menu: chez klick sur cela Croix (Schließen) sagt cela Profan-Prog: "Keine Rückmeldung", si es im nproc ist.
Muss je z.B. alle Menüs im nproc nochmal auswerten ??
Fragen sur 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 ▲ |
|
|
|
|
 | allô E.T.,
c'est so simple, il y a so gesehen keinen Unterschied, si Du aus Proc ou bien NProc heraus arbeitest.
tu peux entier "normal" dans NProcs avec Handles spielen, comme Windows et XProfan vorsieht.
quelque chose schwierig wird es cependant, si Du aus Threads heraus avec Handles spielen veux, qui mais per anderen Fil erzeugt wurden - ici erlauben qui verschiedenen Windows-Versionen unterschiedlich.
>> Muss je maintenant cela la fenêtre selbst (z.B. per Message) trop neuzeichnen auffordern ??
non, entier normal - comment sonst aussi - bzw. "garnicht".
>> Muss je maintenant cela la fenêtre selbst (z.B. per Message) trop neuzeichnen auffordern ??
non, seulement, si Du es per Proc aussi würdest.
>> Ähnlich verhält sich cela la fenêtre-menu: chez klick sur cela Croix (Schließen) sagt cela >> Profan-Prog: "Keine Rückmeldung", si es im nproc ist.
c'est doch aussi "normal" et pas anders, comme si sich cela Programme dans einer Proc est.
Vlt. venez chez einer Proc pas juste qui Anzeige, dass qui Prozess pas rückmeldet, weil XProfan alle X Zeilen Nachrichtenabrufe zwischenschiebt - mais ici reagiert oui "XProfan" "abweichend".
>> Fragen sur Fragen...
qui je alle volontiers répondre voudrais, simple um aussi selbst voyons trop peut, si et wohin encore Schwachstellen vorhanden sommes.
si quelque chose konkretes pas klappt, de quoi Du mais meinst, dass es marcher sollte, ensuite simple fix une kleinen Code posten, dass je ggf. agir peux. ^ ^ |
|
|
| |
|
|
|
 E.T. | Hab la fois am MB gebastelt: KompilierenMarqueSéparation {$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#
=s4 href='./../../funktionsreferenzen/XProfan/end/'>end
Solange cela Prog im Durchlauf_1 (Proc), peux je cela la fenêtre beliebig verdecken, Déplacer etc., XProfan kümmert sich oui ums neuzeichnen.
Im Durchlauf_2 (nProc) wird pour mehrmaligem "verdecken" des Fensters simple nix plus aktualisiert, selbst cela ~RedrawWindow(%HWnd... scheind pas plus anzukommen. Bleibt cela la fenêtre qui ganze Zeit sichtbar, flackerts naturellement très joli (am auswerten de %wmpaint im nproc suis je gescheitert ).
qui "verschluckt" cela neuzeichnen (nproc ?, XProfan ?, Windows ?) ??
(Getestet sous 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 mais statt Global serait je Progress& simple comme Funktionsparameter transfert - zum Problem: tu fais im Prinzip 1000 la fois Sleep(10) - dans cette Zeit ist qui Prozess/ (tête)Fil sprichwörtlich "beschäftigt" bzw. dank Sleep sogar "gesperrt" - Windows wird là à peine qui Possibilité avons, cela la fenêtre trop zeichnen, aussi weil qui L'assurance-chômage-Anzeige assez passif de Windows abgearbeitet wird bzw. versetzt ensuite, si grad Zeit ist.
Pratiquement gibst Du Windows dans cette Boucle aucun chance, es reagiert ici "korrekt" bzw. comment erwartet - si aussi vlt. pas absolument "wie erwünscht". ^ ^
ici serait je plutôt per ~SetTimer-Api sur une NProc montrer, qui arrêt simple seulement den SendMessage absetzt, sans Boucle.
Salopp gesprochen: fais Du alors aus einer XProfan-Funktion heraus lauter SetText, so peux Du wohl nebenher zuschauen - fais Du ca aus einer NProc heraus - so allez ca so fix, dass Windows-L'assurance-chômage pas hinterherkommt, besonders aussi weil pas z.B. alle "20 Zeilen" Nouvelles abgeholt/ verarbeitet volonté mais réellement seulement cela getan wird, quoi angewiesen ist.
un Irrglaube ist vlt. aussi, dass Sleep dem Prozess/ Fil "Zeit" gibt - réellement ist es plutôt so, dass Sleep qui Zeit stiehlt, weil dans cette Zeit qui Fil plutôt "totgestellt" ist. |
|
|
| |
|
|
|
 E.T. | Hab je wohl cela MB "etwas doof" gestaltet: Im richtigen Progg steht naturellement ne...aucune sleep , hab je seulement ins MB incorporé, avec cela on Zeit zum testen hat. Eigentlich führe je dans qui Boucle (viele,viele) String-Vergleiche par. qui effet ist mais qui gleiche comment avec sleep.
Wünschenswert wäre mir une simple Abfrage ala KompilierenMarqueSéparation mais komm je im nProc à %wmpaint vom XProfan-la fenêtre ran ?? je denk, ensuite wäre mir geholfen  ensuite devrait je Windows pas dans jeden Schleifen-Durchlauf avec 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 naturellement ne...aucune sleep , hab je seulement ins MB incorporé, >> avec cela on Zeit zum testen hat.
je comprends, seulement, dass plan Sleep ici eigentlich aucun Zeit schenkt mais seulement quelle kostet - alors diesem Fil aucun Zeit schenkt, quelque chose trop erledigen. ^ ^
>> Eigentlich führe je dans qui Boucle (viele,viele) String-Vergleiche par. qui effet >> ist mais qui gleiche comment avec sleep.
bien sûr, si Du tausende Male s$=s$+"Hallo" fais, ou bien Sleep(... dans beiden Fällen ist qui Fil pas avec Fensterzeichnerei beschäftigt.
>> mais komm je im nProc à %wmpaint vom XProfan-la fenêtre ran ?? je denk, ensuite wäre mir geholfen
%wmPaint wird vlt. de qui WProc gesetzt, si arrêt qui nouvelle wm_paint ankam - Du könntest simple cela hWnd subclassen - mais qui Weg wird oui toujours länger avec cela.
>> ensuite devrait je Windows pas dans jeden Schleifen-Durchlauf avec einer Neuzeichnen - >> Message "zuballern".
de einem GetMessage etc. habe je bisher abgesehen, weil je z.B. pas gestackte Utilisateur Messages abtragen voudrais - je lasse mir quelque chose envahir. |
|
|
| |
|
|