Conference iosg::all-in-1_v30

    
>    So the only reason for the DDIF being part of the OA$TEXT_DSAB is 
>    because of the LIST routines?? I wondered already why the FORMAT.TEXTDS 
>    (Text Data Set) for e.g. DDIF was set to 'N'. 

This is because the DDIF Text Dataset is read-only, and is therefore not 
classed as a format which can be fully processed by the Text Dataset 
mechanism.


>    The new CDA converter libraries contain the DCA/RFT converter. We could 
>    add this as a new format to FORMAT.DAT and define the CDA 
>    Frontend-Backend converters. However, the ALL-IN-1 standard List 
>    function will fail, as no TEXT DSAB is available.

The FOREIGN text dataset looks to see if the RMS file has an RMS semantic
tag, and if it does reads the file via the CDA TEXT display routine
specifying the name of the tag as the name of the CDA front-end to use. 

If the file does not have an RMS semantic tag it looks at the CDATYPES 
table in OAET which maps file types to CDA front-ends.  The V3.0 version of 
this table has an entry for file type '.DCA' mapping to DCA front-end 'DCA'.

Only after attempting the above two ways of trying to read the file does 
the FOREIGN text dataset display the message 'FOREIGN document type cannot 
be displayed'.

We have a DDIF, DTIF and DOTS text datasets to allows us to deal with these
common types of files more efficiently.  Because we know the files are of
the specified type we don't need to start looking for an RMS semantic tag, 
etc.


>    Does this mean that the current ALL-IN-1 code is very static compared 
>    to the CDA converter libraries?

No.  It dynamically changes if the files have RMS semantic tags.


Richard

Hello Richard,

as I understand your reply correctly, the FOREIGN text dataset looks at the
CDATYPES table in OAET.MAR to find a possible match. If it finds one it will
use the appropiate CDA front-end to list the document.

Now I want to read RTF files within ALL-IN-1. (A lot of our customer wants 
this too). I have included these files with TeamLinks into my ALL-IN-1 file 
cabinet. 

FULLDB shows the following attributes for the document:

Folder: TEST                             (Number: 000010)

File:   DISK$USER03:[ROBERT_GACH.A1V3.ZUCEKDVS1.DOC0]IHP21MAF.RTF
DSAB:   FOREIGN

Title:  RTF2 Document (WinWord saved as ... RTF)
Type:            DOCUMENT
Author:          R.Gach (from TeamLinks)
Handling:        RTF2

The FORMAT Master does not contain a RTF2 entry. There are a lot of FOREIGN
formats from the PC world now and I don't want to create a unique list 
function for each if CDA could do the job even better.

I want to read the file with CDA V2.0 SSB which I installed yesterday.
Therefore I modified the OAET.MAR and changed the CDATYPES table to:                                                  
                 
;+
; CDATYPES macro
;
; The following table maps file types and CDA front ends to the CDA converter.
; NOTE: The records are in alphabetical order of the file type
;-
	.MACRO	CDATABLE
;		+---------------+---------------+
;		| file type	| CDA front end |
;		+---------------+---------------+
	ct	<.AFS>,		<AFS>
	ct	<.CGM>,		<CGM>
	ct	<.DCA>,		<DCA>
	ct	<.MAC_PAINT>,	<MAC_PAINT>
	ct	<.RTF>,		<RTF>
	ct	<.SGML>,	<SGML>
	ct	<.TIFF>,	<TIFF>
	ct	<.WPF>,		<WPF>
	.ENDM

Then I compiled the OAET.MAR. Replaced it in OALIBR.OLB and linked ALL-IN-1.
But when I try to read the RTF file I get the message:
 
        Document with ".RTF" file type cannot be displayed

Have I missed something or was my understanding of the FOREIGN text dataset
completly wrong?

Any hint is appreciated.

regards,

Robert

    Robert,
    
    If you're running ALL-IN-1 v3.0 then you certainly shouldn't be
    replacing OAET in OALIBR since you now have CM support for MACRO
    
    Regards,
    
    Andrew.D.Wicks

Hello Andrew,

this was an excellent hint. I have done all my testing on a German fieldtest 
version of ALL-IN-1 (ALL-IN-1-IOS-Server for VMS V3.0 PBL122D (DE) GERMAN 
3-FEB-1992).

In this fieldtest version you can't modify OAET.MAR with CM. In CM the 
field modifiable was set to N for OAET. 

Now I tested it on a original english SSB version. I changed with CM the
CDATABLE in OAET.MAR, moved the element to live and recompiled ALL-IN-1.

                               SUCCESS!!!

It works exactly as I want. When I now read a RTF File the CDA Viewer is
involved. The Format Master doesn't contain an entry for the RTF Format.

Could you please give a short explanation why this one works? 

Thanks a lot,

Robert

> It works exactly as I want. When I now read a RTF File the CDA Viewer is
> involved. The Format Master doesn't contain an entry for the RTF Format.
>
> Could you please give a short explanation why this one works? 

A FORMAT master entry for 'RTF' is not required.  If you don't have a 'RTF' 
FORMAT master entry then users cannot set the handling of a document to 
'RTF'.  

The handling for the RTF documents will probably be blank, in which case
ALL-IN-1 will use the text dataset mechanism to read the files.  As you
have found this is able to 'understand' RTF files now that you have added
the entry to the OAET table. 


Richard

Hello Richard,

thanks for the explanation. But was I really want to know, is the diffence in
the customization behaviour.
Why does it works when I customize OAET.MAR with CM and why not as described as
in .2 ? (where I replaced OAET.OBJ in OALIBR.OLB by hand).

regards,

Robert

    Robert, 
    
    	There is a separate object library SITEOALIBR which is used for
    customised versions of sources such as OAET.  This library is used by
    default when linking ALL-IN-1.  When V3 is installed, this library
    contains the SSB versions of these sources, which is why your changes
    in OALIBR do not come into affect.  When a module is customised with
    CM (the recommended method), the object is replaced in SITEOALIBR and 
    hence included in the link. 
    
    	The SSB version of the sources are also in OALIBR.  These are used
    if the Nocustom option is specified during the Link.  The intention of
    this is to enable an uncustomised image to be produced e.g. to
    eliminate customisations as a cause of a problem.
    
    	Note there is also a SITEOALLV.OLB for language dependant sources
    which may be customised.
     
    Hope this helps,
    
    Martin.
    

    Hi
    
    just another question about this.  I've carried out the changes
    specified in the previous notes making sure the customisations
    were carried out from within CM.
    
    I've created a Word document within Teamlinks and saved it in RTF	
    format in my ALL-IN-1 IOS filing cabinet.  If I look at this
    document (from within ALL-IN-1) it has the same attributes
    as in note .2 with the file extension being .RTF and the handling
    field set to RTF2.  
    
    However, when I read the document from the WP menu it shows 
    an empty document.  If I edit the document there is information 
    in there in the RTF format.
    
    I set the handling field to blank but still no joy.
    
    Looking at the file from DCL level I was able to view the document
    in RTF format and it was fine.  I just can't see it from within
    ALL-IN-1 IOS.
    
    Any clues as to where I've gone wrong.  Maybe I'm wrong in assuming
    I could read it from within ALL-IN-1  ;-)
    
    cheers,
    
    josie

What happens if you list the document with:

	<list_alt oa$curdoc_filename


Richard

    Hi
    
    If I do this then I can the same as if I was editing the document.
    It brings up all the same text as below...
    
    {\rtf1\ansi \deff0\deflang1024{\fonttbl{\f0\froman Times New
    Roman;}{\f1\froman
    
    etc etc.  I couldn't manage to import the whole document.
    
    Is this any help?
    
    josie
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

It looks like the '.RTF' file type is not being recognized as one that has 
to be handled by CDA and therefore ALL-IN-1 is defaulting to reading the 
file using the ASCII text dataset.

Check that new CDATYPES entry is correct, and that it has been correctly 
customized into ALL-IN-1.


Richard

    I have found that to read an RTF document correctly, the appropriate
    CDA image needs to be installed.
    
    Try installing the image DDIF$READ_RTF.EXE.
    
    Malcolm

    Hi
    
    well I finally got it to work properly.  I went through all 
    the relinking process and checked everything.  It now works
    fine...really good!
    
    josie