Conference iosg::all-in-1_v30

You can either: 

-- Move all the index forms that need to pick up the new option (change to
   MORE$SCROLL$KEYS$INDEX) into the appropriate site location.

-- Move the new version of MORE$SCROLL$KEYS$INDEX into the base libraries.

Naturally I'd prefer you to take the first approach as this is in line with the
general CM philosophy.  The second could be regarded as a pragmatic approach, but
it falls down when the time comes to upgrade to V3.next, because the CART won't
be aware of the change, and the new base versions provided in the kit will 
overlay the changes.

How many index forms need access to the change you propose to make?  I'd warrant
that there's only a few.  After all, do you really need to have the change
available on every index form, including those used by CM, SA, and SM?

Cheers, Tony

    Thanks Tony,
    
    But there are...
    
    WP - WP$INDEX
    EM - EM$INDEX
    II - EM$INDEX$INBOX
    IO -  "   "   OUTBOX
    IR -  "   :   READ
    IC -  "   "   CREATED
    IA - FC$IA$INDEX
    
    Index's from DIR menu :-
    COR$INDEX
    PER$INDEX
    ALL$INDEX
    NI$INDEX
    DL$INDEX
    
    TM index's :-
    TMEVINDEX
    TMEG
    TMTINDEX
    TMTG
    
    
    UDP$INDEX
    
    drawers :-
    
    FC$IAD$INDEX
    FC$IDR$INDEX
    
    GPC :-
    OAN$INDEX
    ICM - OAN$MEMBERS$INDEX
    IC - OAN$NOTEBOOK$INDEX
    
    etc etc
    
    
    As you can see there are more than a few index's !
    
    Is this an issue that needs to be addressed in a future release because
    the customer feels it is and I'm starting to wonder ! 
    Are we actually able MBA move to base for the OA application coz I'm
    having problems ?
    
    Thanks
    
    Clive

Hi Clive,

>    Is this an issue that needs to be addressed in a future release because
>    the customer feels it is and I'm starting to wonder ! 

Hmmm, these type of forms have been a problem ever since V2.3. Basically every
.MORE is a problem. 

I think a better future approach is to check how the code can be changed to
have the following working the same (or work as one paramater):

	/MORE
	.MORE

In functionality these 2 qualifiers/parameters only differ in that .MORE forms 
can contain key-stroke definitions, while /MORE forms cannot. The other 
difference is that a /MORE form doesn't have to be in the same
form library as the calling form. Something which would be the solution to 
the problem described in .0).

Another minor difference in that /MORE accepts a string/symbol with multiple
forms.

So, why not make a request for the merge of the .MORE key-stroke possibility
into the /MORE one.

>    Are we actually able MBA move to base for the OA application coz I'm
>    having problems ?

No, by default you are not able to do so. Only for applications of you are the
Original Engineer you can use the MBA. This is the theory.

If you really want to use the MBA, and accept the concequences for future
patches/upgrades (and promise not to call me for any complaints/support) the
workaround is to (temporarily) modify the "OA" record in CM$APP and set the
OEG_FLAG field to '1' (use WRITE CHANGE). Use the MBA option, and reset the
field back to '0'. But again, be carefull. 

 Ciao, 

	Simon

No, you can't use the MBA option to move an element from the OA application 
to the base area after it's been customized.  This is because you don't "own" 
the element, or rather because your system is not recognized as that of the 
"Original Engineering Group" (OEG) for the OA application. A hack is to amend 
the OEG flag in the CM$APP record for the OA record.  You'll then be able to 
use MBA but you'll get into trouble when upgrade time comes around because 
ALL-IN-1 won't realize that you've taken liberties with its flags and will 
overwrite everything (potentially) in the base area.

I know there are lots of index forms in the product.  But my point was how 
many of the standard index forms actually have to be modified for the change 
your customer wants to make?  Unless it's a change that MUST be in every 
subsystem you'll be able to confine the change to a select set.

Handling MORE$SCROLL$KEYS$INDEX in the current manner is (IMHO) not a bug 
(otherwise we wouldn't have done it like that). It just takes understanding. 
I personally favour the creation of a site (or application) versions of the 
standard index (definition) forms and link to those whenever possible.  But 
that's just me... ;-)

Tony 

    Unfortunately, there's a more [sic] fundamental difference between
    .MORE and /MORE.
    
    .MORE causes the forms' named data to be combined together when they're
    compiled. As the compiler only works on a single library, .MOREd forms
    have to be in the same library.
    
    /MORE causes the forms to be linked at run-time. For reasons buried
    deep in the forms processor code, which I don't pretend to understand,
    this means that the key definitions aren't carried from one to 'tother.
    
    So changing them to work the same, whilst apparently desirable, could
    be quite a lot of work. (Also, I've seen /MORE delibrately used so the
    key definitions are _not_ propagated).
    
    Dave.