poor mans file format associations - OS2

This is a discussion on poor mans file format associations - OS2 ; Have writen an file format IOProc (Phoenix Suspend graphic), MMOS2 image viewer works with it. now i want that the WPS offers the additional convert submenu on *.xga files and maybe automaticly associate the image viewer (less a problem). I ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: poor mans file format associations

  1. poor mans file format associations

    Have writen an file format IOProc (Phoenix Suspend graphic),
    MMOS2 image viewer works with it. now i want that the WPS
    offers the additional convert submenu on *.xga files and
    maybe automaticly associate the image viewer (less a problem).

    I assume that the convert function is added by the somehow
    having an additional MMXGA class under MMImage that does this?

    Is there any sample code to use?

    --
    Veit Kannegieser

  2. Re: poor mans file format associations

    On Tue, 8 Feb 2005 11:21:17 UTC, "Veit Kannegieser" wrote:

    > Have writen an file format IOProc (Phoenix Suspend graphic),
    > MMOS2 image viewer works with it. now i want that the WPS
    > offers the additional convert submenu on *.xga files and
    > maybe automaticly associate the image viewer (less a problem).
    >
    > I assume that the convert function is added by the somehow
    > having an additional MMXGA class under MMImage that does this?
    >
    > Is there any sample code to use?


    Not that I'm aware of (but then, I've never looked). However,
    I do have IBM's original MMImage.idl which was never published.
    You'd need this to write your own subclass - and to avoid having
    it crash, according to the comments :-)

    As mentioned, this is the original version. IBM later added
    two more methods to enable users to set the default viewer
    association. You may want to use RWX to get their names and
    add them to the IDL for the sake of completeness. However,
    this isn't really necessary because your subclass doesn't
    need to override them - none of the other subclasses do.
    (This is the beauty of SOM: when you modify a parent class,
    all its subclasses inherit the changes at runtime without
    anyone having to do anything to make it happen.)

    If you'd like a copy of the IDL, write to me.

    BTW... the MMImage class appears to use VAC++'s class libraries.
    I see a reference to "IConversionHelper".



    --
    == == almost usable email address: rich AT e-vertise.com == ==
    __________________________________________________ _________________
    |
    | New - Remote Workplace Server v0.60
    Rich Walsh | interact with the WPS from any program
    Ft Myers, FL | http://e-vertise.com/rws/rws060.zip
    __________________________________________________ _________________

  3. Re: poor mans file format associations

    On Wed, 09 Feb 2005 03:18:00 GMT, Rich Walsh wrote:

    > Not that I'm aware of (but then, I've never looked). However,
    > I do have IBM's original MMImage.idl which was never published.
    > You'd need this to write your own subclass


    I don't think you need it. You can just fake your own version to satisfy
    the needs of the SOM compiler when writing the subclass.

    > - and to avoid having it crash, according to the comments :-)


    Don't believe everything you read... especially in IBM code/documentation.
    Some of it is dreadful.

    > As mentioned, this is the original version. IBM later added
    > two more methods to enable users to set the default viewer
    > association.


    Is that how the PRImage stuff works? ISTR you had a hand in all that?

    > You may want to use RWX to get their names and
    > add them to the IDL for the sake of completeness. However,
    > this isn't really necessary because your subclass doesn't
    > need to override them - none of the other subclasses do.
    > (This is the beauty of SOM: when you modify a parent class,
    > all its subclasses inherit the changes at runtime without
    > anyone having to do anything to make it happen.)


    Quite so, which is why you can get away with a fake minimal IDL file.

    > If you'd like a copy of the IDL, write to me.


    Please.

  4. Re: poor mans file format associations

    On Wed, 9 Feb 2005 21:40:54 UTC, Paul Ratcliffe wrote:
    > On Wed, 09 Feb 2005 03:18:00 GMT, Rich Walsh wrote:
    >
    > > Not that I'm aware of (but then, I've never looked). However,
    > > I do have IBM's original MMImage.idl which was never published.
    > > You'd need this to write your own subclass

    >
    > I don't think you need it. You can just fake your own version to satisfy
    > the needs of the SOM compiler when writing the subclass.


    Generally speaking, true - in this case, false.

    > > - and to avoid having it crash, according to the comments :-)

    >
    > Don't believe everything you read... especially in IBM code/documentation.
    > Some of it is dreadful.


    Well, if I had read the following years ago when I wrote a subclass of
    MMDataFile, maybe it wouldn't have crashed sporadically.

    // BOOL mmclsInitTypesAndExtensions();
    // * This routine is required to address a problem wherein a given
    // MMDataFile subclass could actually be awakened (i.e., its
    // wpclsInitData routine called) BEFORE the parent (MMDataFile)
    // class has received ITS wpclsInitData [etc]

    > > As mentioned, this is the original version. IBM later added
    > > two more methods to enable users to set the default viewer
    > > association.

    >
    > Is that how the PRImage stuff works? ISTR you had a hand in all that?


    I worked with the author but it was his fix - IBM's kludge hadn't been
    introduced yet. It was simple and clever: his MMImage replacement class
    overrode wpQueryDefaultView and invoked MMImage's parent's method, thus
    bypassing the annoyance introduced by MMImage and returning whatever
    value the user had set.

    > > You may want to use RWX to get their names and
    > > add them to the IDL for the sake of completeness. However,
    > > this isn't really necessary because your subclass doesn't
    > > need to override them - none of the other subclasses do.
    > > (This is the beauty of SOM: when you modify a parent class,
    > > all its subclasses inherit the changes at runtime without
    > > anyone having to do anything to make it happen.)

    >
    > Quite so, which is why you can get away with a fake minimal IDL file.


    I may be mistaken, but I think RWX is better for this task than the
    knock-off in XWP. It identifies the size of the data intoduced by a
    class, permitting you to create a more authentic-looking fake IDL.
    (I don't recall whether this really matters.)

    > > If you'd like a copy of the IDL, write to me.

    >
    > Please.


    On its way...


    --
    == == almost usable email address: rich AT e-vertise.com == ==
    __________________________________________________ _________________
    |
    | New - Remote Workplace Server v0.60
    Rich Walsh | interact with the WPS from any program
    Ft Myers, FL | http://e-vertise.com/rws/rws060.zip
    __________________________________________________ _________________

  5. Re: poor mans file format associations

    On Thu, 10 Feb 2005 07:24:01 GMT, Rich Walsh wrote:

    > Well, if I had read the following years ago when I wrote a subclass of
    > MMDataFile, maybe it wouldn't have crashed sporadically.
    >
    > // BOOL mmclsInitTypesAndExtensions();
    > // * This routine is required to address a problem wherein a given
    > // MMDataFile subclass could actually be awakened (i.e., its
    > // wpclsInitData routine called) BEFORE the parent (MMDataFile)
    > // class has received ITS wpclsInitData [etc]


    I don't understand this really. Doesn't this undermine the whole concept
    of SOM? How can a subclass be initialised before its parent?
    It's like trying to run a program before you've loaded it into memory.

    > I worked with the author but it was his fix - IBM's kludge hadn't been
    > introduced yet. It was simple and clever: his MMImage replacement class
    > overrode wpQueryDefaultView and invoked MMImage's parent's method, thus
    > bypassing the annoyance introduced by MMImage and returning whatever
    > value the user had set.


    Ah. I used this once. It was hell trying to get the syntax of how to do it
    correct, but I learnt quite a bit in the process :-)

    > I may be mistaken, but I think RWX is better for this task than the
    > knock-off in XWP. It identifies the size of the data intoduced by a
    > class, permitting you to create a more authentic-looking fake IDL.
    > (I don't recall whether this really matters.)


    I think size of instance data of a parent class is irrelevant to subclasses.

    >> Please.

    >
    > On its way...


    Got it, thanks.

  6. Re: poor mans file format associations

    Rich Walsh wrote:

    > I do have IBM's original MMImage.idl which was never published.
    > You'd need this to write your own subclass - and to avoid having
    > it crash, according to the comments :-)


    Please mail it..

    > BTW... the MMImage class appears to use VAC++'s class libraries.
    > I see a reference to "IConversionHelper".


    Don't have VAC (and don't be able to write C++)...

    --
    Veit Kannegieser

  7. Re: poor mans file format associations

    Paul Ratcliffe wrote:

    > Look at the CWMM stuff on Netlabs for some ideas.


    This seems a solution - i do not even need to write
    code. In opposite to the IBM classes, it is possible to
    extend the recognized files types, and it also
    reads out the file extensions that the registered file
    format libraries provide (via MMIOM_GETFORMATINFO).

    --
    Veit Kannegieser


+ Reply to Thread