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)

.