XProfan

26.07.2007 ▲

- Page 1 -

GDL

Jo, habe ich gerade gemerkt und wenn ich die Procedure 3mal durchlaufen lasse gehts auch immer einwandfrei.Wennas auch ne Sauerei iss, hilfts mir nichts, ich bekomme es anders nicht hin.
Und nachdem auch die prfellow Toolbar in meinem eigentlichen Programm funzt bin ich wieder ganz happy. Danke nochmals allen.

Servus
Georg

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

Du bekommst es nicht anders hin?

Was ist daran nicht-hinbekommbar erst ein Farbstatic zu erzeugen, und dann die Buttons?

GDL

@iF, das mit dem Static habe ich jetzt auch begriffen. Nur soetwas steht nicht in der Aiuto oder bei der SKControl Aiuto. Dies ist auch der Grund warum immer wieder nach einem XProfan Buch nachgefragt wird.

Ich habe mir damals ein GW-Basic Buch (721 Seiten per 68DM) gekauft. Allein die per mich wichtige Schnittstellenprogrammierung umfasst dort 23 Seiten.

Ich weiss auch das der Kosten/Nutzen Faktor bei XProfan nicht gerade super ist.Ich sage auch ehrlich, dass ich mir zurzeit keines kaufen potuto.
Ich wollte halt nur einen Grund dafür nennen, warum immer nach einem Buch gefragt wird.

Aber ich hoffe, dass ein GDL Querdenker euch nicht zu stark auf Trapp hält.

Servus
Georg

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

GDL

Schade ich kann nicht so schnell Tippen.Meine Antwort gehört vor deine.

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

- Page 2 -

Andreas
Miethe

DOKTOR XPROFAN EHRENHALBER

Da ist nicht eigenartig - das Verhalten ist absolut korrekt und zeigt dass das Prinzip des Herummalens auf dem Parent von Controls naturalmente zu Anzeigefehlern führt wenn man auch Bereiche übermalt welche von Windows selbst in verschiedenen Fällen neugezeichnet werden.

Hallo IF,

selbst wenn nicht auf den Controls rumgemalt wird bleibt das seltsame Verhalten der Toolbar-Buttons ( w.o. beschrieben ) bestehen. Man kann das verhindern indem man der Toolbar eine Message sendet und zwar TB_SETPARENT. Wenn Parent %hwnd ist, ist das Verhalten wieder normal.

Ein Weg per XProfan die Hintergrundfarbe per Dialoge zu bestimmen ist per mich folgender, da wird auch nicht auf den Controls rumgemalt, ein Colored-Static ist auch nicht nötig.
Kompilieren Markieren Separieren

 $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, und b) beim ProcAddr-Problem wären...

...was wiederum bedeutet das diese Lösung wegen b) leider keinesfalls empfehlenswert ist da Abstürze, Programmfehler und Schlimmeres Vorprogrammiert ist.

... was wiederum das ColoredStatic empfehlen würde bis Roland das ProcAddr stackt.

Andreas
Miethe

DOKTOR XPROFAN EHRENHALBER

... was wiederum das ColoredStatic empfehlen würde bis Roland das ProcAddr stackt.

Kannst Du das Problem mal etwas genauer beschreiben, ich hatte damit bisher noch nie ein Problem, und auch keinen Absturz.
War mir bisher auch nicht bekannt, so ein Problem, wahrscheinlich habe ich das was verpasst ?

Klar - gab ne menge Diskussionsstoff hier in der Community zu diesem Thema.

Mir war aufgefallen das etwas bei der Abarbeitung nicht stimmt wenn eine per procaddr bezogene FnAdresse angeCallt wird. Nach längerem Bohren hatte sich meine Vermutung bestätigt das XProfan (in bisherigen Versionen) bei Calls auf ProcAddr-Fns keinesfalls abprüft ob es sich nicht vlt. noch mitten in einer andern Abarbeitung (z.B. in einer anderen Proc) è. Es würfelt demnach Variableninhalte und Namen im schlimmsten Fall einfach durcheinander wenn z.B. von einer Api solch eine FnCall an XProfan abgesandt wird. Da sich das XProfan nunmal so verhält, hatte ich Roland den Vorschlag gemacht zu bedenken ob es nicht besser wäre die angecallten Fns nicht sofort auszuführen, sondern die Anfragen auf eine Art internen Stack zu packen welcher erst dann nach und nach abgearbeitet wird wenn XProfan z.B. onIdle ist - also z.B. im WaitInput. Roland wird der Sache IMHO nachgehen.

Solange das aber nicht der Fall ist kann man nur abraten, an z.B. Apis eine mit ProcAddr-bezogenen FnAdresse abzugeben per die Nutzung von z.B. nicht-enumeriernden Apis.

Auf Deutsch ist ProcAddr nur dann sicher benutzbar wenn man die Adresse an eine Api abgibt welche die Adresse nur ancallt solange die Api selbst arbeitet, also das XProfanprogramm solange anhält. Hierzu zählen z.B. in der Aiuto erwähnte Apis welche etwas enumierieren - z.B. Fonts etc.

Für WndProc-Zeugs jedoch ist das ganze sehr, sehr gefährlich. Da bleiben also demnach die Usermessages - welche leider - wenn Roland meiner anderen Bitte im Bezug auf UMs nicht folgt - auch nicht wirklich 100% zuverlässig sind.

Für mich hat Roland also per XPRofan11 zwei essentielle Aufgaben - UserMessages auf einen int.Stack packen, ProcAddrCalls auf einen int.Stack packen. Solange das nicht 100% funktioniert bleibt XProfan in einer Messages basierten Umgebung (Windows) mit eingeschränktem Gebrauchswert.