| |
|
|
- page 1 - |
|
GDL | Salut,
versuche justement avec einem farbigen Dialogfenster trop hantieren.si je autopaint benutze, muss je toujours cela ganze la fenêtre anéantir , là chez CLS toujours quelques Controls verdeckt volonté.
Nebenbei gibts encore Probleme, si cela Dialogfenster encore ne Toolbar hat. KompilierenMarqueSéparationdeclare dlg&,toolbar&,button&
@Set(AutoPaint,1)
usermessages 16
window 0,0 - %maxx,%maxy
dlg&=create(window,%hwnd,,0,0,%maxx,%maxy)
farbe
sleep 1000
toolbar&=@Create(Toolbar,dlg&,0,0,1,0,0)
@Toolbar(AddTextButton,toolbar&,8,100,Sichern,Datei speichern)
@Toolbar(AddTextButton,toolbar&,7,200,hihi,Datei speichern)
button&=create(button,dlg&,bbb,100,400,100,30)
proc farbe
startpaint dlg&
cls RGB(144,80,0)
endpaint
endproc
whilenot 0
waitinput
if %umessage = 16
destroywindow(dlg&)
end
ELSEIF %wmPaint
farbe
endif
Wend
salut Georg |
|
|
| |
|
|
|
| |
|
- page 1 - |
|
GDL | Jo, habe je justement gemerkt et si je qui Procedure 3fois par lasse gehts De toute façon einwandfrei.Wennas aussi ne Sauerei iss, hilfts mir rien, je bekomme es anders pas hin. et après que aussi qui prfellow Toolbar dans mon réel Programme funzt suis je wieder entier happy. merci nochmals allen.
salut Georg |
|
|
| |
|
|
|
| Du bekommst es pas anders hin?
quoi ist daran pas-hinbekommbar seulement un Farbstatic trop erzeugen, et ensuite qui Buttons? |
|
|
| |
|
|
|
GDL | @iF, cela avec dem Static habe je maintenant aussi begriffen. seulement soetwas steht pas dans qui Aider ou bien chez qui SKControl Aider. ca ist aussi qui Grund pourquoi toujours wieder pour einem XProfan livre nachgefragt wird.
j'ai mir autrefois un GW-Basic livre (721 Seiten pour 68DM) gekauft. seul qui pour mich wichtige Schnittstellenprogrammierung umfasst là 23 Seiten.
je weiss aussi cela qui coûter/Nutzen facteur chez XProfan pas justement super ist.je sage aussi honnête, dass je mir zurzeit aucun achetons pourrait. je voulais arrêt seulement une Grund pour appeler, pourquoi toujours pour einem livre gefragt wird.
mais je hoffe, dass un GDL Querdenker euch pas trop stark sur Trapp hält.
salut Georg |
|
|
| |
|
|
|
GDL | tant pis je peux pas so vite Tippen.mon Antwort est avant deine. |
|
|
| |
|
|
| |
|
- page 2 - |
|
|
Andreas Miethe
| iF
voilà pas étrange - cela Verhalten ist absolu korrekt et zeigt dass cela Prinzip des Herummalens sur dem Parent de Controls naturellement trop Anzeigefehlern führt si on aussi Bereiche übermalt quelle de Windows selbst dans verschiedenen Fällen neugezeichnet volonté.
allô IF,
selbst si pas sur den Controls rumgemalt wird bleibt cela seltsame Verhalten qui Toolbar-Buttons ( w.o. beschrieben ) bestehen. il peut cela verhindern indem on qui Toolbar une Message sendet et zwar TB_SETPARENT. si Parent %hwnd ist, ist cela Verhalten wieder normal.
un Weg pour XProfan qui Hintergrundfarbe pour Dialoge trop bestimmen ist pour mich suivant, là wird aussi pas sur den Controls rumgemalt, un Colored-Static ist aussi pas nötig. KompilierenMarqueSéparation $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 : [...] | 28.07.2007 ▲ |
|
|
|
|
| Womit wir mais a) beim FastMode, et b) beim ProcAddr-Problem wären...
...quoi wiederum bedeutet cela cet Solution à cause de b) malheureusement aucunement empfehlenswert ist là Abstürze, Bug et Schlimmeres Vorprogrammiert ist. ... quoi wiederum cela ColoredStatic empfehlen serait jusqu'à Roland cela ProcAddr stackt. |
|
|
| |
|
|
|
Andreas Miethe
| iF
Womit wir mais a) beim FastMode, et b) beim ProcAddr-Problem wären... ...quoi wiederum bedeutet cela cet Solution à cause de b) malheureusement aucunement empfehlenswert ist là Abstürze, Bug et Schlimmeres Vorprogrammiert ist. ... quoi wiederum cela ColoredStatic empfehlen serait jusqu'à Roland cela ProcAddr stackt.
peux Du cela Problem la fois quelque chose genauer décrire, je hatte avec cela bisher encore nie un Problem, et keinen Absturz. était mir bisher aussi pas bekannt, so un Problem, wahrscheinlich habe je cela quoi verpasst ? |
|
|
| 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 : [...] | 28.07.2007 ▲ |
|
|
|
|
| bien sûr - donnais ne la quantité Diskussionsstoff ici dans qui Community trop diesem Thema.
Mir était aufgefallen cela quelque chose chez qui Abarbeitung pas stimmt si une per procaddr bezogene FnAdresse angeCallt wird. Pour längerem Bohren hatte sich mon Vermutung bestätigt cela XProfan (dans bisherigen Versionen) chez Calls sur ProcAddr-Fns aucunement abprüft si es sich pas vlt. encore mitten dans einer andern Abarbeitung (z.B. dans einer anderen Proc) est. Es würfelt donc Variableninhalte et Namen im schlimmsten le cas simple durcheinander si z.B. de einer Api solch une FnCall à XProfan abgesandt wird. là sich cela XProfan nunmal so verhält, J'ai eu Roland den Vorschlag gemacht trop considérer si es pas besser wäre qui angecallten Fns pas tout de suite auszuführen, mais qui Anfragen sur une Art internen Stack trop saisir quel seulement ensuite pour et pour abgearbeitet wird si XProfan z.B. onIdle ist - alors z.B. im WaitInput. Roland wird qui l'affaire IMHO nachgehen.
Solange cela mais pas qui le cas ist peux on seulement dissuader, à z.B. Apis une avec ProcAddr-bezogenen FnAdresse abzugeben pour qui Nutzung de z.B. pas-enumeriernden Apis.
sur allemande ist ProcAddr seulement ensuite sûrement benutzbar si on qui Adresse à une Api abgibt quelle qui Adresse seulement ancallt solange qui Api selbst arbeitet, alors cela XProfanprogramm solange anhält. Hierzu zählen z.B. dans qui Aider erwähnte Apis quelle quelque chose enumierieren - z.B. Fonts etc.
Pour WndProc-Zeugs cependant ist cela ganze très, très périlleux. là rester alors donc qui Usermessages - quelle malheureusement - si Roland meiner anderen s'il te plaît im Bezug sur UMs pas folgt - aussi pas wirklich 100% zuverlässig sommes.
Pour mich hat Roland alors pour XPRofan11 deux essentielle Aufgaben - Utilisateur Messages sur une int.Stack saisir, ProcAddrCalls sur une int.Stack saisir. Solange cela pas 100% funktioniert bleibt XProfan dans einer Messages basierten environnement (Windows) avec eingeschränktem Gebrauchswert. |
|
|
| |
|
|
|
Andreas Miethe
| merci pour qui Aufklärung.
cela Thema ist réellement à mir vorrübergegangen !! alors ist attention geboten, werde je mir merken. |
|
|
| 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 : [...] | 28.07.2007 ▲ |
|
|
|
|
| c'est u.A. qui Grund weshalb je des Öfteren trop Problemen Lösungsvorschläge Poste wohin so mancher denkt:
|
|
|
| |
|
|
|
GDL | pourquoi finde je toujours solche Probleme, qui ensuite so une Rattenschwanz verursachen.
salut Georg |
|
|
| |
|
|
|
| c'est Rolands Schuld. |
|
|
| |
|
|