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)

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.