Subj : Using Prf* routines in window procs
To   : Vitus Jensen
From : Herbert Rosenau
Date : Mon Jun 12 2000 09:32 am

Am 12.06.00 03:11 schrieb Vitus Jensen

VJ>>> So the current design will not change: WM_MOVE updates memory
VJ>>> structures about the profile contents

HR>> Absolutly needless!

VJ> No (WM_MOVE is an example, take WM_PRESPARAMCHANGED if this
VJ> suites you better).

Needless too. The PM itself knows all data. You have noways to hold them by
yourself - except on startup and shutdown of your application.

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.

VJ> You have to either compare SWPs or set an internal flag on
VJ> WM_MOVE.  So there is overhead, too.

If you have to control the size/position you have to compare to a static
min/max and update the NEW position/size with that. Both messages gets you the
old AND new size (and WM_MOVE: positions) so you don#t need to hold them by
yourself. The minimum/maximum framesize you would allow are more or less static
values. So you can smply compare the NEW (from message) ones with your min/max
and change them on the fly.

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(),
HR>> WinQueryUlong().... So you never need to hold lists of them by
HR>> yourself. Any change the user my do is announced before!

VJ> You posted the great idea of subclassing and are now going back
VJ> to query all and every window?  Doing all this querying was my
VJ> major dislike with presentation parameters and you solved it.
VJ> I'm not going back.

Yepp - but there is absolutly no need to hold all of them in own data
structures because PM does it for itself - and lets you ask for them if you
have to handle them by yourself. Holding them in own data structures costs a
lot of memory and TIME.

VJ> The subclassing code updates the in-memory-copy of the profile on
VJ> any change. On WM_SAVEAPPLICATION the changes are written back (a
VJ> very simple WM_SAVEAPPLICATION routine). And remember your saying
VJ> about coding same things only once?  One function call to add
VJ> PRESPARAM or WM_MOVE handling to a control isn't really bad.

In WM_SAVEAPPLICATION you has to ask the PM itself for the current data. You
don't need to hold all of them yourself in memory. Any action PM my change them
by user request you'll informed to get you a chance to modify the user given
data before the PM realises the change - for better control your resources. Not
to give you the possibiltity to hold them by yourself in own data structures
and spend useless memory and runtime.

On startup build your resources (frames _without_ WS_VISIBLE),
- in WM_CREATE/WM_INITDLG
 - get the current presparams, window positions, size from YOUR profile
 - set them to PM by PrfWrite...() - to os2*.ini
 - then use WinSetWindowPos() to set last saved size and position AND
   to change the state to visible. Now your resources would be displayed
   in correct sise and position with last saved (you'd done even for PM)
   presentation marams.
- in WM_MOVE/SIZE
 - only if you need to have a minimum/maximum visible window size
   and if you like the user can minimise/maximise the window
   and he is doing so: nothing to do
   if the user is simply sizing the window:
   compare the new size to your min/max, change the actual parameters
   and let PM the sizing done - absolutly nothing for you to hold in
   own memory (except your min/max
 - if the user should never min/max remove simply one/both entries
   from system menue and frame.
- WM_PRESPARAMSCHANGED
 - control the new presparams if they are useable for YOU
   if NOT change them to anything you like, let PM do the work
- WM_SAVEAPPLICATION
 - query PM for all data you has to save
   - Window position and size (special point: mini/maximised!)
   - if you'll hold pressentation params in your own profile
     get them with Prf- functions from OS2*.ini and wirte them
     into your own to have them ready on restart.
 - optinally you can ignore the message and do that only in
- WM_CLOSE
 - - see WM_SAVEAPPLICATION
   - do some cleanup on user data depending on window to close

A runtime compromise is: holding some FONT data (char width and hight) in
private words to have quicker access during draw action if you have to control
that yourself - but only if you're uses fixed fonts or you can live the
MAX_AVERAGE.

By holding all presparams and window words by yourself you'll spend more time
and memory for that as you ever can save by asking PM for current values if you
need them.

You should do:
- any drawing of bitmaps in an separate thread in one or more
 memory presenation space(s) asyncron
 - in WM_DRAW simply use a bitcopy from one presentation space (last drawn)
   into the one PM holds for drawing
- fill/delete/search listboxes in other threads
 for mainupate them use WinUpdateWindow(hwnd, FALSE)
               - do the action
       WinUpdateWindow(hwnd, TRUE)


--- Sqed/32 1.15/development  556:
* Origin: Lieber eine gute Stellung, als 'ne gute Arbeit! (2:2476/493)

You are viewing proxied material from cvs.synchro.net. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.