XProfan

- Página 1 -

RGH

¡Hola,

Yo voluntad veces versuchen, hay algo mejor como en el Ayuda a erläutern:

Conjunto(WinProc, N%)
(N = 0 oder 1)

Jedes Fensterin Windows ha una Fensterprozedur, el para el Editar aller Messages zuständig es, el a el Ventana geschickt voluntad. Diese se en el Regel mitder jeweiligen Fensterklasse festgelegt. Normalerweise hay para el meisten Windows-Messages una windowseigene Standardbehandlung. Diese sorgt para Ejemplo beim Drücken el Tab-Taste dafür, dass el Foco en el nächste Dialogelement va, sin dass uno lo eigens en el zugehörigen Windowsprozedur programa debería. Andere Messages voluntad allerdings en el Fensterprozedur behandelt. Der Normalfall es also, dass para todos Messages, el no en el Fensterprozedur behandelt voluntad, el Standardbehandlung aufgerufen se.

Mit Subclassing se nun el ursprüngliche Windowsprozedur por unsere propio Windowsprozedur ersetzt. Anstelle el para el Fensterklasse definierte Fensterprozedur se nun unsere Procedimiento aufgerufen. In el Regel uso wir Subclassing aber sólo, en algunos spezielle Messages uno Spezialbehandlung a unterziehen y el resto se eigentlich así trabajo como gewohnt. Hier kommt Conjunto(WinProc,...) en el Spiel: Wenn WinProc beim Verlassen el SubProc en 1 es, se anschließend el ursprüngliche Windowsprozedur aufgerufen, anderenfalls eben no. Im Normalfall se uno WinProc entonces en 0 conjunto, si la Message en el SubClassProc behandelt wurde, ansonsten eben en 1.
(In algunos Fällen kann lo sin embargo auch Sinn hacer auch en Reacción en el Message trotzdem todavía el Windowsprozedur para esta Message aufzurufen. Daher kann el Programmierer el con el Conjunto-Función frei bestimmen.)

Volver en SubClassProc
Sí, Volver kann (y muss en algunos Fällen) verwandt voluntad. Volver determinado el Rückgabewert el Message. En el meisten Messages, el a una Ventana geschickt voluntad, juega el Rückgabewert ningún papel, en algunos aber una bastante erhebliche! Es entonces el Ayuda a jeweiligen Message a entnehmen, etwa si una Message angefragt se, si el Ventana geschlossen voluntad kann. Ein Returnwert macht aber sólo entonces Sinn, si WinProc en 0 es, como sí de otra manera el anschließend aufgerufene Original Fensterprozedur el Rückgabewert determinado.

Saludo
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 Personas!

@ IF:

Wäre einfacher si uno por volver 0 oder 1, WinProc 0 oder 1, conjunto podría - como normalerweise así (fast) auch es.

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

CustomDraw/OwnerDraw con XProfan11 por SubClassProc se por desgracia, no korrekt trabajo puede, porque en el seltensten Fall Anweisungen el una Neuzeichnen auslösen, en el SubClassProc (also en el WaitInput) ausgelöst voluntad, pero eben ausserhalb waitInput - wo sin embargo el Zeichnungsmessages perdido ir.

Darum sí mein Vorschlag, el ProcAddr-Comportamiento como SubClass-Modus einzuführen

Wobei Yo - como du weißt - no Meinung bin, SubClassing por ProcAddr wäre gefährlich (bestenfalls während el desarrollo, si uno todavía no genau weiß, qué tut).
Einige Programas de me nutzen dies a para Exzess (incluso para mi Maßstäbe!) y son seit Jahren en el täglichen Dauereinsatz.
Mich ärgert sólo, daß XProfan 11 algo como grundsätzlich instalado ha y yo no para Laufen kriege...

@ Roland:

Ein Returnwert macht aber sólo entonces Sinn, si WinProc en 0 es, como sí de otra manera el anschließend aufgerufene Original Fensterprozedur el Rückgabewert determinado.

So pensamiento Yo el.

In mi caso debería lo así ser, daß una cierto Rückgabe Windows veranlaßt, el Proc erneut con modifizierten Parametern aufzurufen, qué aber anscheinend no Fall es...

Alt con 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)
declarar LvDraw#
struct LvDraw= HwndFrom&,idFrom&,Code&,DrawStage&,Rest#(44)
dim LvDraw#,LvDraw

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

    parámetros wnd&,msg&,wparam&,lparam&

    if msg&=~WM_NOTIFY

        LvDraw#=lparam&

        if LvDraw#.Hwndfrom&=Lv&

            if LvDraw#.Code&=~NM_CUSTOMDRAW

                if LvDraw#.DrawStage& = ~CDDS_PREPAINT

                    imprimir PREPAINT erkannt
                    volver ~CDRF_NOTIFYITEMDRAW

                elseif LvDraw#.DrawStage& = ~CDDS_ITEMPREPAINT

                    imprimir ITEMPREPAINT erkannt

                endif

            endif

        endif

    endif

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

    mientras que 1

        waitinput

    endwhile

Neu con 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)
declarar LvDraw#
struct LvDraw= HwndFrom&,idFrom&,Code&,DrawStage&,Rest#(44)
dim LvDraw#,LvDraw
subclassproc--------------------------------------------------------

if %smessage=~WM_NOTIFY

    LvDraw#=&slparam

    if LvDraw#.Hwndfrom&=Lv&

        if LvDraw#.Code&=~NM_CUSTOMDRAW

            if LvDraw#.DrawStage& = ~CDDS_PREPAINT

                imprimir PREPAINT erkannt
                set(subclassmode,1)--???
                set(winproc,0)-------???
                volver ~CDRF_NOTIFYITEMDRAW

            elseif LvDraw#.DrawStage& = ~CDDS_ITEMPREPAINT

                imprimir ITEMPREPAINT erkannt--Hier kommt nichts mehr a!

            endif

        endif

    endif

endif

ENDPROC-------------------------------------------------------------
SubClass %hwnd,1

mientras que 1

    waitinput

endwhile

Tal vez sehe Yo auch sólo el Wald antes lauter Bäumen no?

SeeYou
Pascal

RGH

Uwe Pascal Niemeier

Tal vez sehe Yo auch sólo el Wald antes lauter Bäumen no?

... ähem ... como lag tatsächlich una Bug antes, el el Rückgabewert verhinderte ...

Das RETORNO restos en SUBCLASSPROC wirkungslos.

Sorry!
Yo sehe ya, el nächste Bugfix kommt determinado. Lo probablemente bald una XProfan 11.2 geben.

Saludo
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 como eventuell auch el otro hier angesprochene con adaptado?

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 como eventuell auch el otro hier angesprochene con adaptado?

Was genau media Usted así?

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 y el con 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 Yo - como du weißt - no Meinung bin, SubClassing por ProcAddr wäre gefährlich (bestenfalls während el desarrollo, si uno todavía no genau weiß, qué tut).

Einige Programas de me nutzen dies a para Exzess (incluso para mi Maßstäbe!) y son seit Jahren en el täglichen Dauereinsatz.

Ok hör veces, para gefährlich halte Yo no gerne porque lo blockiert mich bastante erheblich por qué Yo seither en Stack bettle.

Nur theoretisch para gefährlich hielt Yo Anfangs como Yo versuchte me vorzustellen como el gelöst wurde, o. porque hier y como siempre veces una kleine Info kam como porque gelöst sei.

Leider ha se no sólo en einfachsten Tests herausgestellt (Yo glaube wir hatten el ya handfest), dass tatsächlich en una Aufruf uno con ProcAddr-bezogenen Función, si XProfan z.B. se no en el WaitInput befindet, lo bastante simplemente y no sólo en me garnicht selten knallt.

El Fehler kommen entonces siempre como de el Luft y son selten nachvollziehbar o. beziehbar el ProcAddr-Problema.

Nach (entonces doch jahrelangem) (hartnäckigen) nachkratzen hatte Roland - meiner Ansicht después de - el problema auch bestätigt y verwiesen el eben una con ProcAddr-bezogene Función para z.B. ENum-Apis pensamiento es - also si XProfan es o. wartet oder se eben en el WaitInput befindet.

Tatsächlich musste Yo enorm viel umschreiben a Software así eben no unerklärlichen Se bloquea mehr passieren - seither mein StackGebettel.

Auuuch si z.B. una Programa el ProcAddr en gefährliche Weise nutzt, entonces heißt el längst no, dass lo siempre knallt. El Sache es mi humilde opinión incluso así komplex, dass uno sagen kann, dass lo Systeme son en denen lo entonces ständig knallt y lo Systeme son, en denen lo casi nie Knallt.

Beide Systeme Yo aquí en Vorhaltung por qué Yo ums ver** kein ProcAddr gefährlich nutze porque me unerklärliche Se bloquea horrend viel Tiempo y Nerven gekostet hatten - y wer baut ya gern en Zuckerstäben*.

*) ausgenommmen (natürlich) el Fraggles

Was Yo no así dolle finde es, dass Roland - porque gefährliches procAddr nunmal no siempre accidentes - no está claro sagt, dass él de el Nutzung de ProcAddr abraten sería salvo para el gedachten Fall el EnumApis o. si XProfan es. Jedenfalls podría Yo entonces viel Gesabbel ersparen qué imho keiner (mehr) hören will; mag; muss; kann; costumbre.

Um lo bildlich a hacer stellt Roland imho z.B. folgendes no sicher:

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

Würde el angecallte Función z.B. sólo en |MARKE| Ausführung erlangen, wäre el problema deutlich schmächtiger.

Im aktuellen Fall kann el gecallte Función imho aber mitten en el 1+5+hier oder mitten en meineFunktion(hier)+5 oder sonst mittendrin ausgeführt voluntad, qué natürlich, si uno lo vorstellt, garnicht ungefährlich ser muss - bedenke uno z.B. una delTree-Función welche en una vez una Call verpasst bekommt woraufhin se entonces algo ändert. : - /

Natürlich kann hier jede Detailinfo de el Wirklichkeit - el wohl sólo Roland kennen mag - abweichen, natürlich son el lediglich mi Beurteilungen el Roland (Por favor,!) en el Luft zerfetzt para falso deklariert.

09.03.2009 ▲

Jac
de
Lad

Mein unqualifizierter Kommentar:

Liegt no daran, dass mehrere Procs entonces gleichzeitig versuchen en gleiche Sachen, z.B. Variables zuzugreifen? Das sería erklären, por qué Yo nie Problemas con ProcAddr() hatte (SetTimer y así), porque Yo el meist sólo benutze, en en el Statuszeile el Uhrzeit y z.B. el Speicherverbrauch anzugeben, el kommt eben no con otro Características en el 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 weniger abgearbeitet voluntad muss... aber imho es incluso una volver en Línea 1 el Proc gefährlich.

Apéndice: Ist wohl Wurstbrot wieviel abgearbeitet se, Daufruf incluso es mi humilde opinión más el problema.

09.03.2009 ▲

Hier una Ejemplo welches en egal welchem WhileLoop-Parámetro no zucken dürfte si porque geregelt wäre.

 {$cleq}
cls
float a=1

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

do {myProc()}
end

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

    a=a+1
    imprimir a
    volver 0

}

Der anhängige Screenshot zeigt, dass no jede Línea beschrieben se.

Aufgrund el Tatsache, dass natürlich 10ms vergleichbar Jahrzehnte son, entsteht el Fehler sólo relativ selten.

Dreht uno el WhileLoop-Parámetro algo höher vlt. incluso a para Exzess, así el Anwendung siempre Lustiger reagieren a a lustigen Abstürzen...

Naja, fehlt el Zeilenumbruch... liegt sólo al Imprimir es no mi Einstellung.

Zwischenablage01.png Prevista

8 kB

Hochgeladen:

10.03.2009

Ladeanzahl:

Descargar

Dokument1.exe

1.025 kB

Hochgeladen:

10.03.2009

Ladeanzahl:

Descargar

10.03.2009 ▲

- Página 2 -

Uwe
''Pascal''
Niemeier

Hi IF!

Como ya he dicho, Yo puede así no bestätigen. (Und mi Programas laufen durchaus no sólo en mi Rechner - si dieser Eindruch entstanden ser debería

)

Tal vez liegt lo a el Art, Yo esta Technik einsetze.
Hier veces bastante grob mein üblicher Programmaufbau:

proc SubClassing---------

    Hier voluntad sólo Ereignisse ausgewertet
    y quizás selbstdefinierte Messages a %Hwnd geschickt.
    Más passiert hier no (Excepción: OwnerDraw o.ä)
    ENDPROC------------------

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

        SubClassing/FastMode a

        Sinestar encargado Funct%------------------Innere Eingabeschleife

            WaitInput
            Funct% en Abhängigkeit de Irgendwas conjunto
            por ejemplo en %umessage reagíeren
            endwhile-------------------------Innere Bucle verlassen
            SubClassing/Fastmode de
            In Abhängigkeit de Funct% irgendwelche Aktionen durchführen
            y Funct%=0 conjunto
            endwhile-----------------------------Zurück para Anfang

Könnte me vorstellen, daß el en Profano bastante ähnlich aussieht y yo por lo tanto así bastante bien gefahren bin.
Aber Yo denke veces, el muß no más verfolgt voluntad
(especialmente Yo de Stacks usw. no wirklich Idea habe => learning by doing)

BTW: Kann mich a una Fall erinnern, wo Yo en uno WndProc una Standartvariable (a&) eingesetzt hatte, sin esta lokal a deklarieren.
Dann Yo zwei Stunden lang intenta rauszukriegen, por qué esta sch... Variable en el Hauptprogramm ständig völlig unmotiviert irgendwelche Werte enthielt...

SeeYou
Pascal

12.03.2009 ▲