Subj : Using Prf* routines in window procs
To : Herbert Rosenau
From : Vitus Jensen
Date : Sun Jun 11 2000 08:11 pm
Moin Herbert,
10.06.00 19:13, Herbert Rosenau wrote a message to Vitus Jensen:
VJ>> So the current design will not change: WM_MOVE updates memory
VJ>> structures about the profile contents
HR> Absolutly needless!
No (WM_MOVE is an example, take WM_PRESPARAMCHANGED if this suites you better).
VJ>> and WM_SAVEAPPLICATION uses PrfWriteProfileData() to dump the
VJ>> changed entries to disk.
HR> WinQueryWindowPos() for frame window size and position does the
HR> same without having any overhead on management the info. Only
HR> size/position of child windows NOT depending on current FRAME
HR> size are object of separat handling.
You have to either compare SWPs or set an internal flag on WM_MOVE. So there
is overhead, too.
HR> Presentation params of each window can inspected at any tim with
HR> WinQuerypresParams(), ALL window depending information can be
HR> queried at any time by WinQueryWindowWords(), WinQueryUlong()....
HR> So you never need to hold lists of them by yourself. Any change
HR> the user my do is announced before!
You posted the great idea of subclassing and are now going back to query all
and every window? Doing all this querying was my major dislike with
presentation parameters and you solved it. I'm not going back.
The subclassing code updates the in-memory-copy of the profile on any change.
On WM_SAVEAPPLICATION the changes are written back (a very simple
WM_SAVEAPPLICATION routine).
And remember your saying about coding same things only once? One function call
to add PRESPARAM or WM_MOVE handling to a control isn't really bad.
By that:
[...i know...]
Bye,
Vitus
--- Sqed/rexx 162:
* Origin: Age is only important if you're a cheese. (2:2474/424.1)
