XProfan

- page 1 -

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.

 {$cleq}
cls
float a=1

whileLoop 3 {~setTimer(hWnd,loop,10,procAddr(myProc,4))}

do {myProc()}
end

long myProc(long _a,_b,_c,_d){

    a=a+1
    imprimer a
    return 0

}

qui anhängige Screenshot zeigt, dass pas chacun la ligne beschrieben wird.

Aufgrund qui Tatsache, dass naturellement 10ms comparable Jahrzehnte sommes, entsteht qui faute seulement relativ selten.

Dreht on den WhileLoop-paramètre quelque chose höher vlt. sogar jusqu'à zum Exzess, so wird qui Anwendung toujours Lustiger réagir jusque lustigen Abstürzen...

bof, fehlt qui Zeilenumbruch... liegt arrêt am Imprimer ist pas mon Einstellung.

Zwischenablage01.png Preview

8 kB

Hochgeladen:

10.03.2009

Downloadcounter:

Download

Dokument1.exe

1.025 kB

Hochgeladen:

10.03.2009

Downloadcounter:

Download

10.03.2009 ▲

- page 2 -

Uwe
''Pascal''
Niemeier

Hi iF!

Comme je le disais, je peux cela so pas bestätigen. (et mon Programme courir durchaus pas seulement sur meinem calculateur - si cette Eindruch entstanden son sollte

)

peut-être liegt es à qui Art, comment je cet technologie einsetze.
ici la fois entier grob mon üblicher Programmaufbau:

proc SubClassing---------

    ici volonté seulement Ereignisse ausgewertet
    et peut-être selbstdefinierte Messages à %Hwnd envoyé.
    plus passiert ici pas (Ausnahme: OwnerDraw o.ä)
    endproc------------------

    Tandis que 1-----------------------------Äußere Eingabeschleife

        SubClassing/FastMode à

        Whilenot Funct%------------------intérieur Eingabeschleife

            WaitInput
            Funct% dans dépendance de Irgendwas mettons
            z.B. sur %umessage reagíeren
            endwhile-------------------------intérieur Boucle sortir de
            SubClassing/Fastmode aus
            dans dépendance de Funct% irgendwelche Aktionen durchführen
            et Funct%=0 mettons
            endwhile-----------------------------Zurück zum Anfang

Könnte mir présenter, qui cela dans Profan entier ähnlich aussieht et je tout autor avec cela pas mal gefahren suis.
mais je denke la fois, cela doit pas plus verfolgt volonté
(zumal je de Stacks usw. pas wirklich Ahnung habe => learning by doing)

BTW: peux mich à une le cas erinnern, wohin je dans einer WndProc une Standartvariable (a&) eingesetzt hatte, sans cet bistrot trop déclarer.
ensuite habe je deux Stunden long versucht rauszukriegen, pourquoi cet sch... Variable im Hauptprogramm ständig völlig unmotiviert irgendwelche Werte enthielt...

SeeYou
Pascal

12.03.2009 ▲