T.R | Title | User | Personal Name | Date | Lines |
---|
950.1 | The name of the form? | IOSG::PYE | Graham - ALL-IN-1 Sorcerer's Apprentice | Mon Jun 29 1992 09:46 | 4 |
| Is it just because the form is *CALLED* WP? Have you tried it with
something like EM, where the form is called EMC?
Graham
|
950.2 | New menu form acts via DEFAULT | CESARE::EIJS | All in 1 Piece | Mon Jun 29 1992 10:13 | 24 |
|
Sjaak,
The 'Guide' (V3.0, Chapter 6.2 (sorry, no page, I'm using the
Bookreader) states:
- If the menu doesn not contain the /CAPTIVE qualifier, search the
Named Data of the Default form
- If the menu does not contain the /CAPTIVE qualifier, treat the user
input as a form name and pass it as a parameter to the FORM
function.
<FORM EMC /CAPTIVE creates a new menu stack. Option TR puts you in a
new menu form, which doesn't contain the /CAPTIVE. So, WP is then
processed either via DEFAULT or as a FORM name.
The same for <FORM FD/CAPTIVE (also in V3.0), where C (Create) puts you
in a new menu form.
HTH,
Simon
|
950.3 | More ... | UTRTSC::BOSMAN | We're just sugar mice in the rain | Mon Jun 29 1992 10:56 | 24 |
| Hi,
� Is it just because the form is *CALLED* WP? Have you tried it with
� something like EM, where the form is called EMC?
No, yes.
� - If the menu does not contain the /CAPTIVE qualifier, treat the user
� input as a form name and pass it as a parameter to the FORM
� function.
Should that be 'If the menu does contain ...'?
� <FORM EMC /CAPTIVE creates a new menu stack. Option TR puts you in a
� new menu form, which doesn't contain the /CAPTIVE. So, WP is then
� processed either via DEFAULT or as a FORM name.
Thus a user can bypass the /CAPTIVE by invoking a new menu and /CAPTIVE
is *only* valid for the current menu. Is it logical then to say that
the programmer should add /CAPTIVE to any menu following the first
/CAPTIVE?
Thanks for any help,
Sjaak.
|
950.4 | No mistake | CESARE::EIJS | All in 1 Piece | Mon Jun 29 1992 13:04 | 16 |
|
Sjaak,
> Should that be 'If the menu does contain ...'?
No, I don't think so. Using both form names and menu options (as
specified in DEFAULT) are ignored if the menu is called with /CAPTIVE
(E.g. <FORM FD/CAPTIVE -> EM (ignored), EMC1 (ignored)).
If the user can get to a new menu from the /CAPTIVE menu, the /CAPTIVE
seems not to go along. So, it seems that any followng menu form should
be called with /CAPTIVE. Now that's going to be a lot of work...
Ciao,
Simon
|
950.5 | Topic closed | UTRTSC::BOSMAN | We're just sugar mice in the rain | Mon Jun 29 1992 13:17 | 4 |
| Sorry Simon, I should have read that twice. (Ofcourse) your right.
Thanks for the clarification,
Sjaak.
|
950.6 | You've got it right! | WAYLND::HOWARD | Our business is computers not money | Tue Jun 30 1992 22:00 | 7 |
| What you are seeing is expected behavior. Somewhere there is or was a
caution about this. All the user has to do is find a menu option to
get him to a menu without /CAPTIVE, and he is no longer captive. All
/CAPTIVE does is to prevent ALL-IN-1 from looking for a form with that
name in an open form library.
Ben
|
950.7 | No Default options either | SHALOT::NICODEM | Avoid traffic; leave work at noon | Wed Jul 01 1992 17:16 | 10 |
| RE: .-1
� All /CAPTIVE does is to prevent ALL-IN-1 from looking for a form with that
� name in an open form library.
Actually, it does more than that. It also removes the search of the
Default form when trying to match the option. So you're basically limited to
options on the current menu (or extensions thereof, create by .MORE or /MORE).
F
|