XProfan

26.07.2007 ▲

- Página 1 -

GDL

Jo, Yo gerade gemerkt y si yo el Procedure 3veces durchlaufen lasse gehts De todos modos einwandfrei.Wennas auch ne Sauerei iss, hilfts me nichts, Yo bekomme lo anders no hin.
Und después de auch el prfellow Toolbar en mi real Programa funzt bin Yo otra vez bastante happy. Gracias nochmals allen.

Servus
Georg

Windows7 Xprofan 8,9,10 [...]

Usted bekommst no anders hin?

Was es daran no-hinbekommbar sólo una Farbstatic a erzeugen, y luego el Buttons?

GDL

@IF, el con el Static Yo ahora begriffen. Nur soetwas es no en el Ayuda oder en SKControl Ayuda. Dies es auch el Grund por qué siempre otra vez una XProfan Buch nachgefragt se.

Yo habe me damals una GW-Basic Buch (721 Páginas para 68DM) gekauft. Allein el para mich wichtige Schnittstellenprogrammierung umfasst hay 23 Páginas.

Yo blanco auch el el Kosten/Nutzen Faktor en XProfan no gerade super es.Yo sage auch ehrlich, dass Yo zurzeit keines kaufen podría.
Yo quería sólo sólo una Grund dafür nennen, por qué siempre una Buch gefragt se.

Aber Yo hoffe, que un GDL Querdenker euch no a stark en Trapp hält.

Servus
Georg

Windows7 Xprofan 8,9,10 [...]

GDL

Schade Yo kann no así rápidamente Tippen.Mi Antwort gehört antes deine.

Windows7 Xprofan 8,9,10 [...]

- Página 2 -

Andreas
Miethe

DOKTOR XPROFAN EHRENHALBER

Como es no eigenartig - el Comportamiento es absolut korrekt y zeigt dass el Principio des Herummalens en el Parent de Controls natürlich a Anzeigefehlern führt si uno auch Bereiche übermalt welche de Windows incluso en verschiedenen Fällen neugezeichnet voluntad.

¡Hola IF,

incluso si no en el Controls rumgemalt se restos seltsame Comportamiento el Toolbar-Buttons ( w.o. beschrieben ) bestehen. Se puede el verhindern indem uno el Toolbar una Message envía y zwar TB_SETPARENT. Wenn Parent %hwnd es, es el Comportamiento otra vez normal.

Ein Weg para XProfan el Color de fondo para Dialoge a bestimmen es para mich folgender, como se auch no en el Controls rumgemalt, una Colored-Static es auch no nötig.
Kompilieren Marca Separación

 $H messages.ph
 $H windows.ph
Set(FastMode,1)
declare dlg&,toolbar&,button&
declare oldproc&,brush&,ende&
Brush& = ~CreateSolidBrush(RGB(144,80,0))

Proc DialogProc

    Parameters Uwnd&,Umsg&,wParam&,lParam&

    if Umsg& = ~WM_CTLCOLORDLG

        RETURN Brush&

    endif

    if Umsg& = ~WM_SIZE

        setwindowpos toolbar& = 0,0-0,0

    Endif

    if Umsg& = ~WM_Close

        ~deleteObject(brush&)
        ende& = 1

    endif

    Return 0

endproc

window 0,0 - %maxx,%maxy
dlg&=create(window,%hwnd,,0,0,0,0)
button&=create(button,dlg&,bbb,40,80,100,30)
toolbar&=@Create(Toolbar,dlg&,0,0,0,0,0)
nächste zeile remmen um Effekt zu sehen
sendmessage(toolbar&,1061,%hwnd,0)TB_SETPARENT
@Toolbar(AddTextButton,toolbar&,8,100,Sichern,Datei speichern)
@Toolbar(AddTextButton,toolbar&,7,200,hihi,Datei speichern)
oldproc& = ~SetWindowLong(dlg&,~DWL_DLGPROC,Procaddr(DialogProc,4))
setwindowpos dlg& = 0,0-400,400

whilenot ende&

    waitinput

wend

Gruss
Andreas
________ ________ ________ ________ _
Profan 3.3 - XProfanX2
Win 95,98,ME,2000,XP,Vista - Win 7 32 / 64 Bit
ASUS X93S - Intel Core I7-NVIDIA GForce 540M 8GB Arbeitsspeicher
Homepage : [...]

Womit wir aber a) beim FastMode, y b) beim ProcAddr-Problema wären...

...qué wiederum bedeutet el esta Solución wegen b) desafortunadamente keinesfalls empfehlenswert es como Se bloquea, Programmfehler y Schlimmeres Vorprogrammiert es.

... qué wiederum el ColoredStatic empfehlen sería a Roland el ProcAddr stackt.

Andreas
Miethe

DOKTOR XPROFAN EHRENHALBER

... qué wiederum el ColoredStatic empfehlen sería a Roland el ProcAddr stackt.

¿Puede Usted el problema veces algo genauer beschreiben, Yo hatte así bisher todavía nie una Problema, y no Choque.
War me bisher auch no bekannt, así una Problema, wahrscheinlich Yo el qué verpasst ?

Klar - gab ne menge Diskussionsstoff aquí en el Comunidad a diesem Thema.

Mir war aufgefallen el algo en Abarbeitung no stimmt si una por procaddr bezogene FnAdresse angeCallt se. Nach längerem Bohren hatte se mi Vermutung bestätigt el XProfan (en reciente Versionen) en Calls en ProcAddr-Fns keinesfalls abprüft si se no vlt. todavía mitten en uno andern Abarbeitung (z.B. en uno otro Proc) befindet. Lo würfelt demnach Variableninhalte y Namen en el schlimmsten Fall simplemente durcheinander si z.B. de uno Api solch una FnCall a XProfan abgesandt se. Como se el XProfan nunmal así verhält, Tuve Roland el Vorschlag gemacht a bedenken si no mejor wäre el angecallten Fns no inmediatamente auszuführen, pero el Anfragen en una Art internen Stack a packen welcher sólo entonces después de y después de abgearbeitet se si XProfan z.B. onIdle es - also z.B. en el WaitInput. Roland se el Sache IMHO nachgehen.

Solange pero no la el Fall es puede ser sólo abraten, a z.B. Apis una con ProcAddr-bezogenen FnAdresse abzugeben para el Nutzung de z.B. no-enumeriernden Apis.

Auf Alemán es ProcAddr sólo entonces sicher benutzbar si uno el Adresse a una Api abgibt welche el Adresse sólo ancallt solange el sistema API incluso arbeitet, also el XProfanprogramm solange anhält. Hierzu zählen z.B. en el Ayuda erwähnte Apis welche algo enumierieren - z.B. Fonts etc.

Für WndProc-Zeugs sin embargo es el todo muy, muy gefährlich. Como bleiben also demnach el Usermessages - welche desafortunadamente - si Roland meiner otro Bitte en el Bezug en UMs no folgt - auch no wirklich 100% zuverlässig son.

Für mich ha Roland also para XPRofan11 zwei essentielle Aufgaben - Mensajes del usuario en una int.Stack packen, ProcAddrCalls en una int.Stack packen. Solange el no 100% funktioniert restos XProfan en uno Messages basierten Umgebung (Windows) con eingeschränktem Gebrauchswert.