Moin Herbert,

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

Sorry for the late replay. My system was about a week mostenly
down because on a lot of hardware problems (not all really solved
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!

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

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

Filter WM_PRESPARAMCHANE of each window (subwindow of dialog) by
subclassing the frame. So we can do the required action blind.

[...source...]

Great idea!

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...

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

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

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

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

And who is setting the saved parameters on restart?

SQED has in its startup code functions to read its own sqed.ini,
putting the properties in os2.ini - to inform the PM of the
current (sqed defined) ones - and on shutdown the reverse way to
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).

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

It would alway better to do *all* of your real work first. Then
at last, if your application does all you wish that it has to do
make the nice to have! It's always not easy to handle the
presentation params right all the ways. Change of font size and
type has changes the dimension of static controls, entryfields,
...... 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)