Conference iosg::all-in-1_v30

>  <<< Note 3003.0 by WPOSRV::BEESON "Down Under in the bottom left corner" >>>
>                   -< A question of consistancy (MCD & FM) >-
>
>    Hi,
>    
>    When doing an MCD from an index menu then the original entry is
>    overwritten by the copied entry.  The original entry in effect is
>    'lost' in that you can no longer access it.
    
Yes. It's always worked like that - you might find something in an earlier 
version of the conference explaining why this should be. However, it seems 
quite a nice feature to me in that I can immediately work on the copy I've 
made.

>    If you do an FM (which is a similar function) the original message is
>    still accessible but now the copy is 'lost'.  Which if you are copying
>    it to a place that does not match the selection criteria of the
>    original index would be expected.

No. FM (an EM operation) is the same as the FC XFD (Crossfile), operation, not 
MCD (Copy).

>    My questions are:
>    	1. Why the inconsistancy, and
>    	2. Is there a particular reason why the index is not refreshed
>    	   after either of these operations?

I'm not sure there is an inconsistency. They are different operations, and I 
suspect the pragmatic approach has been taken in both cases - the answer to 
'what is the user most likely to want to do next?'

As your previous paragraph says 'the selection criteria of the *original* 
index'. You've changed the FileCab by creating a new entry in each case - to 
get a view of the 'new' FileCab you need to respecify your criteria.

grahame

    Grahame,
    
    Thanks for putting up with the stupid questions...  Just one
    clarification, please:
    
    After doing the MCD et al why cant you simply do something like XOP
    "~~BIND~~" (or similar) with an OA$SCL_REFRESH?  Since your previous
    selection criteria should still be valid I would imagine it would work.
    
    And 1 final question:
    
    I have tried it on MCD on EM$INDEX$OPTIONS and the above seems to work
    with EM$INDEX$INBOX although the other forms use different XOP routines
    to do the bind so you would have to check those as well.  Have I missed
    something, is there some sinister reason not to rebuild the index and
    redisplay it?
    
    Again I appreciate your patience, I am looking at this issue at a
    customers request so I really do need to follow it to the nth degree.
    
    Regards,
    ajb

    btw...
    
    I just compared FM, FC XFD and MCD and I still believe FM and MCD are
    close approximations as a new copy of the document text is made in both
    cases. XFD simply creates a new header record and points to the old
    document text.
    
    Regards,
    ajb

    Rebuilding the index would lose all of your current selections, and
    anything already refiled or deleted, which you might still be intending
    to operate on further.
    
    Graham

>  <<< Note 3003.3 by WPOPTH::BEESON "Down Under in the bottom left corner" >>>
>                      -< why MCD and FM are the same... >-
    
>    I just compared FM, FC XFD and MCD and I still believe FM and MCD are
>    close approximations as a new copy of the document text is made in both
>    cases. XFD simply creates a new header record and points to the old
>    document text.
    
All I can say to this is, it didn't work like this back in my day (a way back, 
I admit!), and it doesn't work like this for me now!

On my V3.0 single-drawer system, FM creates a new DOCDB entry pointing to the 
same text file - just as XFD does. MCD gives me a new text file.

Are you calling FM to file in another drawer? You can't crossfile across 
drawers, so I imagine the MAIL FILE_MESSAGE code has been enhanced to copy the 
message if the destination folder is in another drawer.

grahame

    Hi,
    
    Thanks to you both.
    
    RE: .1 and .5, I tried it again more closely.  If the selected item is
    a document it acts like MCD (I happened to be testing against a
    document).  If its a message it works like XFD!
    
    Sorry, I should do more thorough testing before I take a mental leap of
    a cliff.
    
    Regards,
    ajb