Subj : Identifying controls
To   : Herbert Rosenau
From : Vitus Jensen
Date : Mon May 29 2000 05:29 pm

Moin Herbert,

18.05.00 17:27, Herbert Rosenau wrote a message to Vitus Jensen:

 HR> Sorry for the late replay. My system was about a week mostenly
 HR> down because on a lot of hardware problems (not all really solved
 HR> yet).
I made my own hw problems by adding a second-hand hdu and exchanging mobo, 
modem, SCSI controller, token ring adapter and serial controller.  An 
interesting experience!


 VJ>> Copying to os2.ini?  I haven't seen this.  My os2.ini seems to be
 VJ>> clean.

 HR> Because the PM calls ALL presentation params only from os2.ini
 HR> they must be set there (explicty - or implicit by calling the PM
 HR> APIs. The SQED is designed to save them independant of your
 HR> currently running system - so it has to update its own (sqed.ini)
 HR> with the presparams in os2.ini. See profile functions in your
 HR> OS/2 programming guide.

Are you talking about WinStoreWindowPos?  I thought it was widely accepted that 
this API call should be avoided.  Just because it doesn't accepts a HINI.
But I think I now have understood.


 HR>>> Filter WM_PRESPARAMCHANE of each window (subwindow of dialog) by
 HR>>> subclassing the frame. So we can do the required action blind.
 VJ>> [...source...]

 VJ>> Great idea!
 HR> Mostenly the same work should be done by same function or not? :-)

That's the only way to keep sane when writing sw.  But it's sometimes difficult 
to see what is related...


 HR>>> On startup/shutdown of sqed we'll copy the COLOR and FONT
 HR>>> presparams from/to os2.ini/sqed.ini to save them between system
 HR>>> change by using the right profile functions.

 VJ>> I still don't understand your snippets.   You are subclassing any
 VJ>> window of interest, OK.  Now on every WM_PRESPARAMCHANGED you set
 VJ>> the same parameter to your parents window.  Why? 

 HR> WM_PRESPARAMCHANGED is only a notify that the user! wishes to
 HR> make the change - it's on you to do the propper work - or ignore
 HR> the wish. In most SQED likes to make the change.

So notification of the parent window is to trigger a possible rearrangement of 
controls?


 VJ>>   And who is setting the saved parameters on restart?

 HR> SQED has in its startup code functions to read its own sqed.ini,
 HR> putting the properties in os2.ini - to inform the PM of the
 HR> current (sqed defined) ones - and on shutdown the reverse way to
 HR> save the current ones for next start. 
....

OK, I got it.
On every window destroy Sqed/32 is calling WinStoreWindowPos to parameters 
about the window into OS2.INI.  Before the application exits all stored keys 
are moved from OS2.INI to SQED.INI.
On startup all keys are copied back to OS2.INI from SQED.INI and on every 
window creation WinRestoreWindowPos is called to restore the presentation 
parameters.

This is a possibility.  But it looks a bit clumsy, I like my code a lot more 
(naturally).


 VJ>> It might be because I never wrote a major PM apps but i still
 VJ>> have no clue how to implement the save/*restore*...

 HR> It would alway better to do *all* of your real work first. Then
 HR> at last, if your application does all you wish that it has to do
 HR> make the nice to have! It's always not easy to handle the
 HR> presentation params right all the ways. Change of font size and
 HR> type has changes the dimension of static controls, entryfields,
 HR> ...... the logic of texthandling depends on them.
....

I agree, it's low priority work.  But when doing it on most cases simply 
require a single function call it's something I will do just for recreation.  
And it remains undocumented, I won't tell my users they can drop colours/fonts 
on the setup program. ;->

Bye,
    Vitus

--- Sqed/rexx 407:
 * Origin: - Mens sana in campari soda - (2:2474/424.1)

.