XProfan

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

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.

Ejemplo:

cls
addstring(meineListBox,sabim)//ausserhalb des WaitInput - Message erreicht más el Nirvana en lugar de el subClassProc
...

mientras que 1

    waitInput

wend

end

subClassProc

    meineListBox.zeichne()

endProc

Braucht veces solch una Message algo länger y kann no inmediatamente vom XProfan-Prozess aufgenommen voluntad - erreicht ellos tatsächlich (aber sólo unsicher y de Sys a Sys anders je después de Performance) el waitInput y así el SubClassproc - en a (Owner)-Dibujar.

Yo fürchte así, dass solange Roland kein gestacktes ProcAddr bastelt, todos esta Problemas bestehen bleiben. Um así erfreulicher aber ists wiederum, dass imho así sólo por el Fixen des ProcAddr-Problemes auch el gestackten Mensajes del usuario y el SubClassProc unnötig y ser lo entonces auch kein gefährliches Subclassing mehr son.

AddStrings en el SubClassProc aufrufen oder todos Programa sólo en el SubClassProc ausführen ha otra vez otro Nachteile, wobei el auch Sinnfrei es solange kein Stack...

Mapa de bits(-Controls)s podría uno nehmen, Yo glaube Yo mache el así en el knobcontrol.inc.

Übrigens, dass Yo Stack nenne kann desafortunadamente kein einfacher Stack ser, porque eigentlich garnichts gestackt voluntad kann, z.B. Adressen de Guardar welche como Rückgabewert dienten welche en späterem Abruf (ca. Stack) sicherlich garnicht mehr disponible ser necesario.

Bajo folgender Konstellation wäre lo tal vez Möglich, el Problema el Runtime-Synchonisation en el Schliche a kommen - wobei Yo su ausgehe, dass una Umsetzung en XProfan una gewissen Aufwandt bedeutet:

Hilo1, welcher el Messages empfängt, darf no Hilo ser, el el Quellcode interpretiert y ausführt.

Somit kann Hilo1 warten, a Hilo 2 a Punto X es (subClassProc o. procaddr-Bereit), Punto X ausführen y Hilo 1 sólo el Rückgabe zurückliefern. Hilo 1 wartet entonces solange, y todos Programas welche Hilo 1 una Nachricht gesandt haben eben auch - como sonst sí normalerweise auch en el Windowswelt de Statten va.

Un Concepto, incluso Hilo1 bereitzustellen y el Runtime sozusagen nachzuladen en Hilo2 es gescheitert, como Yo no media Hilo1 con el (danach) Runtime-Hilo2 synchonisieren podría, porque Yo no vom XProfan-Code dafür bereitgestellten Mutexe o.Ä. auffinden podría.

06.03.2009 ▲

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.