XProfan

07/26/07 ▲

- Page 1 -

GDL

Jo, have I straight Pinned and if I The Procedure 3times through let GEHTS too always correct.Wennas too ne Sauerei iss, hilfts me nothing, I get it differently not there.
and after too The prfellow Toolbar in my actual Program working be I again integrally happy. thanks over again all.

Hello
Georg

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

You get not differently there?

What is on it not-hinbekommbar first one Farbstatic To produce, and then The Buttons?

GDL

@iF, with the the Static have I now too begriffen. only soetwas standing not in the Help or with the SKControl Help. these too the reason Why over ands over again to one XProfan book nachgefragt becomes.

I have me then one GW-Basic book (721 pages for 68DM) bought. alone The for me important Schnittstellenprogrammierung comprising there 23 pages.

I knows too the the cost/benefit factor with XProfan not straight super is.I say too sincere, I me zurzeit keines buy could.
I wanted to hold only a reason for name, Why always to one book demand becomes.

but I hope, that one GDL Querdenker you not To heavy on Trapp holds.

Hello
Georg

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

GDL

Schade I can't so quick type.my response heard to your.

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

- Page 2 -

Andreas
Miethe

DOKTOR XPROFAN EHRENHALBER

there's not odd - the behaviour is utterly correctly and shows that the principle the Herummalens on the Parent of Controls naturally To Anzeigefehlern lead if one too reaches übermalt which Windows self in different Make neugezeichnet go.

Hello IF,

even if not whom Controls rumgemalt becomes remaining the seltsame behaviour the Toolbar-Buttons ( w.o. described ) consist. one can the prevent because one the Toolbar a Message sends and of course TB_SETPARENT. If Parent %hwnd is, is the behaviour again normal.

One lane for XProfan The Backgroundcolor for dialogs To to determine is for me following, there becomes neither on the Controls rumgemalt, one Colored-Static is neither necessary.
Compile Mark Separation

 $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 we but a) at FastMode, and b) at ProcAddr-trouble wären...

...what against means thats Solution because of b) unfortunately under no circumstance recommendable is there Abstürze, Bug and Schlimmeres Vorprogrammiert is.

... what against the ColoredStatic recommend would To Roland the ProcAddr stackt.

Andreas
Miethe

DOKTOR XPROFAN EHRENHALBER

... what against the ColoredStatic recommend would To Roland the ProcAddr stackt.

can You, the trouble time something accurate describe, I had so yet yet never a problem, and none crash.
was me yet neither famous, so a problem, probably have I the what missed ?

clear - given ne crowd Diskussionsstoff here in the Community To this Topic.

me was noticed the something with the Abarbeitung not is correct if a by procaddr bezogene FnAdresse angeCallt becomes. After längerem bore having itself my supposition confirm the XProfan (in recent versions) with Calls on ProcAddr-Fns under no circumstance abprüft whether it not vlt. yet in the middle in a andern Abarbeitung (z.B. in a others Proc) befindet. it würfelt therefore Variableninhalte and names in the worst drop simply confusion if z.B. a Api such a FnCall on XProfan abgesandt becomes. Since the XProfan blut behave, I had Roland whom suggestion made To deliberating whether it not rather would The angecallten Fns not immediate to execute, separate The inquire on a manner internen Stack To pack which first then by degrees worn out becomes if XProfan z.B. onIdle is - means z.B. in the WaitInput. Roland becomes the thing IMHO go after.

as long as the but not the case is can only dissuade, on z.B. Apis a with ProcAddr-bezogenen FnAdresse abzugeben for Use of z.B. not-enumeriernden Apis.

On german is ProcAddr only then sure usable if one The address on a Api abgibt which The address only ancallt as long as The Api self operates, So the XProfanprogramm as long as anhält. For this, count z.B. in the Help mentioned Apis which something enumierieren - z.B. Fonts etc.

for WndProc-Zeugs however is the whole very, very dangerous. there stay means therefore The User Messages - which unfortunately - if Roland of my others Please in the reference on UMs not follows - neither really 100% reliably are.

for me has Roland means for XPRofan11 two essentielle releases - User Messages on a int.Stack pack, ProcAddrCalls on a int.Stack pack. as long as not 100% functions remaining XProfan in a Messages based surroundings (windows) with eingeschränktem Gebrauchswert.