Conference bulova::decw_jan-89_to_nov-90

    Any string is valid but I think that "STRING" is the only one anybody
    uses.  
    
                                    August G. Reinig

    Are there any other formats besides STRING?  How about something
    like PIXMAP?
    
    thanks
    
    tim

>    Are there any other formats besides STRING?  How about something
>    like PIXMAP?
    
    The most likely ones are formats that everyone can agree upon up front
    as to what they actually mean.  How many planes are there in the PIXMAP
    data type?  Sometime in the foreseable future, DDIF and DTIF format
    data will be passed around through the clipboard.  I believe that there
    may be applications which already do DTIF (Chart, Info).
    
    Since DDIF is a pretty robust data representation format, it might be a
    good idea if we all pursued that (or DTIF).  DDIF does images pretty
    completely, there are service routines (VAXimage Application Services)
    and it would be in keeping with general CDA goals.
    
John

    
    Is it possible to use the clipboard to store line segments?
    
    I'd like to use it to cut&paste lines generated by a drafting
    package from the drafting package window into DECwrite.
    
    Since I need to be able to scale the results an image won't do.

>    Is it possible to use the clipboard to store line segments?
    
    Sure.  You could even define your own format for them.  Unfortunately,
    only you and any applications that supported your format could
    understand it.  If you put DDIF on the clipboard, then applications
    that understand DDIF through the clipboard would be able to read your
    data.
    
>    I'd like to use it to cut&paste lines generated by a drafting
>    package from the drafting package window into DECwrite.
    
    DECwrite may disable its access of the clipboard for V1 due to
    reliability problems.  It's currently disabled in our last field test. 
    
    If you can generate a DDIF file, you can use DECwrite's include
    document capability to grab up the lines and paste them onto a page of
    a DECwrite document.
    
    You might also want to look into DECwrite's live link capability if
    you're really serious about pursuing inter-application data transfers.
    For more information in that area, contact Baldwin Cheung on
    SARAH::B_CHEUNG.
    
>    Since I need to be able to scale the results an image won't do.
    
    You can scale images in DECwrite, as well as other applications.  I'm
    not suggesting that images are the way to go, but it's a possibility.
    
John

    
    DDIF is fine. 
    
    We would like to post to the clipboard when that is fully supported.
    
    Meanwhile, constructing a DDIF file is an acceptable alternate. 
    
    Is the clipboard access disabled for Ultrix as well?

    Posting DDIF to the clipboard is fully supported right now.  You post
    byte streams to the clipboard.  The clipboard doesn't care one whit
    about what these byte streams actually are.   Whenever you post
    something to the clipboard, you tell the clipboard that whenever
    someone asks for the <MUMBLE> thing on the clipboard, give them this. 
    <MUMBLE> is the format_name argument of dwt$copy_to_clipboard and
    dwt$copy_from_clipboard.
    
    There is a convention as to the data types for the various <MUMBLE>
    things found on the clipboard.  Applications must follow this
    convention or some application will try to interpret DDIF data as a
    string with results something like sending a .ps file to an ansi
    printer.  So far, the only convention that exists (that I know of) is
    that the STRING format name means that the data is stored in STRING
    format.
    
    If there is no convention for how to pass DDIF data to the clipboard,
    make one up.  Use the format name "DDIF".  If you are the first, you
    aren't violating any convention.  If worse comes to worse, and another
    name is chosen, the change to your program is simple.  Who knows, if
    you start using "DDIF", everyone else may follow and you won't have to
    make any future change.
    
                                August G. Reinig

    Definitely do not make up the atom name.  There is a registry run by
    the X consortium.  I will try to find out what the right atom name is.

Atom names should be registered with SQM. There is nothing registered for DDIF. 
Private names should start with our organization prefix which should be 
registered with the consortium. I do not know if one has been - presumably it
would be DEC.

Tim

V1.0 Paint and the V2.0 cardfiler both write DDIF to the clipboard as DDIF files
with just an image in it. (If you select the text then the cardfile still sends
text to the clipboard).

Both use the DDIF atom name.

Neal