• Identifying controls

    From Vitus Jensen@2:2474/424.1 to Herbert Rosenau on Mon May 29 17:29:48 2000
    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
    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

    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.

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


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