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)

.