XProfan

Wäre einfacher si on per return 0 ou bien 1, WinProc 0 ou bien 1, mettons pourrait - comme normalement so (presque) aussi ist.

CustomDraw/OwnerDraw avec XProfan11 per SubClassProc wird malheureusement pas korrekt marcher peut, weil im seltensten le cas Anweisungen qui un Neuzeichnen auslösen, dans qui SubClassProc (alors im WaitInput) ausgelöst volonté, mais plan ausserhalb waitInput - wohin cependant qui Zeichnungsmessages verloren aller.

Beispiel:

cls
addstring(meineListBox,sabim)//ausserhalb des WaitInput - Message erreicht plutôt cela Nirvana statt qui subClassProc
...

tandis que 1

    waitInput

Wend

end

subClassProc

    meineListBox.zeichne()

endProc

Braucht la fois solch une Message quelque chose länger et peux pas tout de suite vom XProfan-Prozess aufgenommen volonté - erreicht vous réellement (mais seulement unsicher et de Sys trop Sys anders je pour Performance) cela waitInput et avec cela qui SubClassproc - afin de (Owner)-Zeichnen.

je fürchte avec cela, dass solange Roland ne...aucune gestacktes ProcAddr bastelt, alle cet Probleme bestehen rester. Um so erfreulicher mais ists wiederum, dass imho avec cela seulement par cela Fixen des ProcAddr-Problemes aussi qui gestackten Utilisateur Messages et qui SubClassProc unnötig volonté et es ensuite aussi ne...aucune gefährliches Subclassing plus gibt.

AddStrings dans qui SubClassProc appel ou bien cela ganze Programme seulement dans qui SubClassProc effectuer hat wieder autre Nachteile, wobei cela aussi Sinnfrei ist solange ne...aucune Stack...

Bitmap(-Controls)s pourrait on prendre, je crois je fais cela so dans qui knobcontrol.inc.

Incidemment, dass quoi je Stack nenne peux malheureusement ne...aucune einfacher Stack son, weil eigentlich garnichts gestackt volonté peux, z.B. Adressen de Sauver quelle comme Rückgabewert dienten quelle chez späterem Abruf (GT. Stack) sicherlich garnicht plus vorhanden son doit.

sous suivant Konstellation wäre es peut-être Möglich, dem Problem qui Runtime-Synchonisation sur qui Schliche trop venons - wobei je en ausgehe, dass une Umsetzung sur XProfan une gewissen Aufwandt bedeutet:

Fil1, quel qui Messages empfängt, darf pas qui Fil son, qui den Quellcode interpretiert et ausführt.

Somit peux Fil1 attendre, jusqu'à Fil 2 à Stelle X ist (subClassProc bzw. procaddr-Bereit), Stelle X effectuer et Fil 1 seulement qui Rückgabe zurückliefern. Fil 1 wartet ensuite solange, et alle Programme quelle Fil 1 une nouvelle gesandt avons plan aussi - comme sonst oui normalement aussi dans qui Windowswelt de Statten allez.

une concept, selbst Fil1 bereitzustellen et qui Runtime sozusagen nachzuladen dans Fil2 ist gescheitert, là je pas meinen Fil1 avec dem (après) Runtime-Fil2 synchonisieren konnte, weil je aucun vom XProfan-Code pour bereitgestellten Mutexe o.Ä. auffinden konnte.

06.03.2009 ▲

RGH

Salut,

je veux la fois versuchen, es quelque chose besser comme dans qui Aider trop erläutern:

Set(WinProc, N%)
(N = 0 ou bien 1)

chaque Fensterin Windows hat une Fensterprozedur, qui pour cela Travailler aller Messages zuständig ist, qui à cela la fenêtre envoyé volonté. cet wird dans qui règle mitder jeweiligen Fensterklasse festgelegt. normalement gibt es pour qui meisten Windows-Messages une windowseigene Standardbehandlung. cet sorgt zum Beispiel beim Drücken qui Tab-bouton pour, dass qui Concentrer ins prochain Dialogelement allez, sans dass on es eigens dans qui zugehörigen Windowsprozedur programmieren devrait. autre Messages volonté allerdings dans qui Fensterprozedur behandelt. qui Normalfall ist alors, dass pour alle Messages, qui pas dans qui Fensterprozedur behandelt volonté, qui Standardbehandlung aufgerufen wird.

avec Subclassing wird eh bien qui ursprüngliche Windowsprozedur par unsere eigene Windowsprozedur ersetzt. Anstelle qui pour qui Fensterklasse definierte Fensterprozedur wird eh bien unsere Procédure aufgerufen. dans qui règle verwenden wir Subclassing mais seulement, um quelques spezielle Messages einer Spezialbehandlung trop unterziehen et qui reste soll eigentlich so marcher comment gewohnt. ici venez Set(WinProc,...) ins Spiel: si WinProc beim sortir de qui SubProc sur 1 steht, wird anschließend qui ursprüngliche Windowsprozedur aufgerufen, anderenfalls plan pas. Im Normalfall wird on WinProc ensuite sur 0 mettons, si le Message dans qui SubClassProc behandelt wurde, ansonsten plan sur 1.
(dans einigen Fällen peux es cependant aussi Sinn faire aussi chez réaction sur qui Message quand même encore qui Windowsprozedur pour cet Message aufzurufen. Daher peux qui Programmierer cela avec qui Set-Funktion libre bestimmen.)

Retour dans SubClassProc
oui, Retour peux (et muss dans einigen Fällen) verwandt volonté. Retour bestimmt den Rückgabewert qui Message. chez den meisten Messages, qui moins un la fenêtre envoyé volonté, écoutes qui Rückgabewert aucun rôle, chez einigen mais une entier erhebliche! c'est ensuite qui Aider zur jeweiligen Message trop entnehmen, etwa si sur une Message angefragt wird, si cela la fenêtre geschlossen volonté peux. un Returnwert pouvoir mais seulement ensuite Sinn, si WinProc sur 0 steht, là oui andernfalls qui anschließend aufgerufene Original Fensterprozedur den Rückgabewert bestimmt.

Salut
Roland

Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

06.03.2009 ▲

Uwe
''Pascal''
Niemeier

Hi gens!

@ iF:

Wäre einfacher si on per return 0 ou bien 1, WinProc 0 ou bien 1, mettons pourrait - comme normalement so (presque) aussi ist.

Zumindest wären entsprechende spezielle Rücksprungbefehle de qui Syntax her einleuchtender gewesen...

CustomDraw/OwnerDraw avec XProfan11 per SubClassProc wird malheureusement pas korrekt marcher peut, weil im seltensten le cas Anweisungen qui un Neuzeichnen auslösen, dans qui SubClassProc (alors im WaitInput) ausgelöst volonté, mais plan ausserhalb waitInput - wohin cependant qui Zeichnungsmessages verloren aller.

tout autor oui mon Vorschlag, cela ProcAddr-Verhalten comme SubClass-Modus einzuführen

Wobei je - comment tu sais - pas qui attitude suis, SubClassing per ProcAddr wäre périlleux (bestenfalls au cours de qui Entwicklung, si on encore pas oui c'est ca sais, quoi on tut).
quelques Programme de mir nutzen ca jusqu'à zum Exzess (selbst pour mon Maßstäbe!) et sommes depuis Jahren im täglichen Dauereinsatz.
Mich ärgert seulement, qui XProfan 11 quelque chose comme grundsätzlich incorporé hat et je es pas zum courir kriege...

@ Roland:

un Returnwert pouvoir mais seulement ensuite Sinn, si WinProc sur 0 steht, là oui andernfalls qui anschließend aufgerufene Original Fensterprozedur den Rückgabewert bestimmt.

So dachte je mir cela.

dans mon cas sollte es so son, qui une bestimmte Rückgabe Windows veranlaßt, qui Proc erneut avec modifizierten Parametern aufzurufen, quoi mais anscheinend pas qui le cas ist...

vieux avec ProccAddr:

window 10,10-500,500
 $H Messages.ph
 $H Windows.ph
 $H commctrl.ph
var Lv&=create(gridbox,%hwnd,Test;0;150,0,200,10,200,200)
addstring(Lv&,Test1)
addstring(Lv&,Test2)
declare LvDraw#
struct LvDraw= HwndFrom&,idFrom&,Code&,DrawStage&,reste#(44)
dim LvDraw#,LvDraw

proc LvProc--------------------------------------------------------

    parameters wnd&,msg&,wparam&,lparam&

    si msg&=~WM_NOTIFY

        LvDraw#=lparam&

        si LvDraw#.Hwndfrom&=Lv&

            si LvDraw#.Code&=~NM_CUSTOMDRAW

                si LvDraw#.DrawStage& = ~CDDS_PREPAINT

                    imprimer PREPAINT erkannt
                    return ~CDRF_NOTIFYITEMDRAW

                elseif LvDraw#.DrawStage& = ~CDDS_ITEMPREPAINT

                    imprimer ITEMPREPAINT erkannt

                endif

            endif

        endif

    endif

    return ~DefWindowProc(wnd&,msg&,wparam&,lparam&)
    endproc-------------------------------------------------------------
    set(fastmode,1)
    ~SetWindowLong(%hwnd,~GWL_WNDPROC,procaddr(LvProc,4) )

    tandis que 1

        waitinput

    endwhile

récente avec SubClass:

window 10,10-500,500
 $H Messages.ph
 $H Windows.ph
 $H commctrl.ph
var Lv&=create(gridbox,%hwnd,Test;0;150,0,200,10,200,200)
addstring(Lv&,Test1)
addstring(Lv&,Test2)
declare LvDraw#
struct LvDraw= HwndFrom&,idFrom&,Code&,DrawStage&,reste#(44)
dim LvDraw#,LvDraw
subclassproc--------------------------------------------------------

si %smessage=~WM_NOTIFY

    LvDraw#=&slparam

    si LvDraw#.Hwndfrom&=Lv&

        si LvDraw#.Code&=~NM_CUSTOMDRAW

            si LvDraw#.DrawStage& = ~CDDS_PREPAINT

                imprimer PREPAINT erkannt
                set(subclassmode,1)--???
                set(winproc,0)-------???
                return ~CDRF_NOTIFYITEMDRAW

            elseif LvDraw#.DrawStage& = ~CDDS_ITEMPREPAINT

                imprimer ITEMPREPAINT erkannt--ici venez rien plus à!

            endif

        endif

    endif

endif

endproc-------------------------------------------------------------
SubClass %hwnd,1

tandis que 1

    waitinput

endwhile

peut-être vois je aussi seulement den forêt avant lauter Bäumen pas?

SeeYou
Pascal

RGH

Uwe Pascal Niemeier

peut-être vois je aussi seulement den forêt avant lauter Bäumen pas?

... ähem ... là lag réellement un Bug avant, qui den Rückgabewert verhinderte ...

cela RETOUR bleibt dans SUBCLASSPROC wirkungslos.

Sorry!
je vois déjà, qui prochain Bugfix venez bestimmt. Es wird wohl bientôt un XProfan 11.2 donner.

Salut
Roland

Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

Jac
de
Lad

Wird là eventuell aussi l'autre ici angesprochene avec angepasst?

Profan² 2.6 bis XProfan 11.1+XPSE+XPIA+XPRR (und irgendwann XIDE)
Core2Duo E8500/T2250, 8192/1024 MB, Radeon HD4850/Radeon XPress 1250, Vista64/XP

RGH

Jac

Wird là eventuell aussi l'autre ici angesprochene avec angepasst?

quoi oui c'est ca meinst Du avec cela?

Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

Jac
de
Lad

Subclassing außerhalb de Waitinput et cela avec ProcAddr.

Profan² 2.6 bis XProfan 11.1+XPSE+XPIA+XPRR (und irgendwann XIDE)
Core2Duo E8500/T2250, 8192/1024 MB, Radeon HD4850/Radeon XPress 1250, Vista64/XP

08.03.2009 ▲

Uwe Pascal Niemeier

Wobei je - comment tu sais - pas qui attitude suis, SubClassing per ProcAddr wäre périlleux (bestenfalls au cours de qui Entwicklung, si on encore pas oui c'est ca sais, quoi on tut).

quelques Programme de mir nutzen ca jusqu'à zum Exzess (selbst pour mon Maßstäbe!) et sommes depuis Jahren im täglichen Dauereinsatz.

Ok hör la fois, pour périlleux halte je es pas volontiers car es blockiert mich entier erheblich weshalb je seither um Stack bettle.

seulement theoretisch pour périlleux hielt je es Anfangs comme je versuchte mir vorzustellen comment cela gelöst wurde, bzw. weil ici et là toujours la fois une kleine Info kam comme car gelöst sei.

malheureusement hat sich pas seulement dans einfachsten Tests herausgestellt (je crois wir hatten cela déjà handfest), dass réellement chez einem Aufruf einer avec ProcAddr-bezogenen Funktion, si XProfan z.B. sich pas im WaitInput est, es entier simple et pas seulement chez mir garnicht selten knallt.

qui faute venons ensuite toujours comment aus qui air et sommes selten nachvollziehbar bzw. beziehbar sur cela ProcAddr-Problem.

Pour (ensuite doch jahrelangem) (hartnäckigen) nachkratzen hatte Roland - meiner Ansicht pour - cela Problem aussi bestätigt et verwiesen cela plan une avec ProcAddr-bezogene Funktion pour z.B. ENum-Apis gedacht ist - alors si XProfan steht bzw. wartet ou bien sich plan im WaitInput est.

réellement musste je enorm viel paraphraser à Software avec cela plan aucun unerklärlichen Abstürze plus passer - seither mon StackGebettel.

Auuuch si z.B. un Programme cela ProcAddr sur gefährliche Weise utilise, ensuite est cela jadis pas, dass es toujours knallt. qui l'affaire ist imho sogar so komplex, dass on dire peux, dass es Systeme gibt sur denen es ensuite ständig knallt et es Systeme gibt, chez denen es si bien comment nie Knallt.

Beide Systeme habe je ici dans Vorhaltung weshalb je ums Ver** ne...aucune ProcAddr périlleux nutze weil mir unerklärliche Abstürze horrend viel Zeit et Nerven gekostet hatten - et qui baut déjà gern sur Zuckerstäben*.

*) ausgenommmen (naturellement) qui Fraggles

quoi je pas so dolle finde ist, dass Roland - weil gefährliches procAddr nunmal pas toujours abstürzt - pas bien sûr sagt, dass il de qui Nutzung de ProcAddr dissuader serait ausgenommen pour den gedachten le cas qui EnumApis bzw. si XProfan steht. Jedenfalls pourrait je mir ensuite viel Gesabbel ersparen quoi imho aucun (plus) écouter will; mag; muss; kann; coutume.

Um es bildlich trop faire stellt Roland imho z.B. folgendes pas sûrement:

|MARKE|Print 1+5+meineFunktion()+5+2
|MARKE|andereFunktion(solala)*primadoll

Würde qui angecallte Funktion z.B. seulement chez |MARKE| Ausführung erlangen, wäre cela Problem deutlich schmächtiger.

Im aktuellen le cas peux qui gecallte Funktion imho mais mitten im 1+5+ici ou bien mitten dans meineFunktion(ici)+5 ou bien sonst mittendrin fonctionnement volonté, quoi naturellement, si on es sich vorstellt, garnicht ungefährlich son muss - bedenke on z.B. une delTree-Funktion quelle sur einmal un Call verpasst bekommt woraufhin sich ensuite irgendwas ändert. : - /

Bien sûr peux ici chacun Detailinfo de qui Wirklichkeit - qui wohl seulement Roland connaître mag - abweichen, naturellement sommes cela lediglich mon Beurteilungen qui Roland (s'il te plaît!) dans qui air zerfetzt pour faux deklariert.

09.03.2009 ▲

Jac
de
Lad

mon unqualifizierter Kommentar:

Liegt es pas daran, dass plusieurs Procs ensuite gleichzeitig versuchen sur gleiche Sachen, z.B. Variablen zuzugreifen? cela serait expliquer, pourquoi je nie Probleme avec ProcAddr() hatte (SetTimer et so), weil je cela meist seulement benutze, um dans qui Statuszeile qui l'heure et z.B. den Speicherverbrauch anzugeben, cela venez plan pas avec anderen Funktionen ins Gehege.

Profan² 2.6 bis XProfan 11.1+XPSE+XPIA+XPRR (und irgendwann XIDE)
Core2Duo E8500/T2250, 8192/1024 MB, Radeon HD4850/Radeon XPress 1250, Vista64/XP

09.03.2009 ▲

Desto moins abgearbeitet volonté muss... mais imho ist selbst un return dans la ligne 1 qui Proc périlleux.

Nachtrag: Ist wohl Wurstbrot combien abgearbeitet wird, Daufruf selbst ist imho plutôt cela Problem.

09.03.2009 ▲

ici un Beispiel welches chez égal welchem WhileLoop-paramètre pas zucken pourrait si es car geregelt wäre.