[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference iosg::all-in-1_v30

Title:	OLD ALL-IN-1 (tm) Support Conference
Notice:	Closed - See Note 4331.l to move to IOSG::ALL-IN-1
Moderator:	IOSG::PYE

Created:	Thu Jan 30 1992
Last Modified:	Tue Jan 23 1996
Last Successful Update:	Fri Jun 06 1997
Number of topics:	4343
Total number of notes:	18308

1787.0. "OA$_ feature in V3.0" by TPIVX1::SCOTT (Does anyone look at personal names?) Mon Nov 16 1992 13:44

	In V2.3 and V2.4 of ALL-IN-1 there used to be a nice 'feature'
	which greatly helped multi-lingual application development and 
	support.

	When the ALL-IN-1 menu symbols were introduced (OA$_TYPE_STUFF), it
	was possible to create an entry form with a name begining OA$_ and
	access it in the same way as these new symbols.       
	This new form could be used in the NAMED DATA of menu forms so 
	that you could have dymanic menu options such as :-

 	    ;;OA$_MY_APP_OPTION.LLV_OPT["EDIT"];;

	    DO MY_APP_EDIT


	You could also have fields on the MENU for, say OPT1 and TXT1, 
	which could be loaded with OA$_MY_APP_OPTION.LLV_OPT["EDIT"] and 
	OA$_MY_APP_OPTION.LLV_TXT["EDIT"] respectively making the menu text 
	dynamic too.

	This meant that only data records in OA$_MY_APP_OPTION had to change
	to have an application in another language. There was no need to 
	hack around with message files, and no real need to update the menu 
	screens.
	
	This "feature" seems to have gone bye-bye in ALL-IN-1 V3.0.  

	Has anybody been able to make this work under V3.0?

	Was the "feature" removed intentionally?

	Has the syntax change?

	Is it really Monday already? :-)

	
	Regards,

	Colin SCOTT
 	
	(OA$I_KNOW_A_FEATURE_IS_NOT_SUPPORTED_BUT_IT_WAS_NICE)

T.R	Title	User	Personal Name	Date	Lines
1787.1	More of a direct question.	EVTSG8::SCOTT	Does anyone look at personal names?	`Fri Nov 20 1992 16:20`	21
	I will try and ask the same question in a different way. What has changed in V3.0 menu processing that stops the symbols/DSR like OA$_FORMNAME.FIELD[KEY] being translated as a menu option? (Within ;; ;;) It used to work in V2.3 and V2.4. Somebody somewhere must have seen this before; I'm not making it up you know :-( It was a really really really nice, easy, quick, cheap and nasty way to develop an application that could be translated into LLVs. I know it was/is not documented and was/is not supported, but I would just like to know what happened to it and can it still be done in some way. Maybe I have just answered my own question? Not supported. Thanks for any info, Colin Scott
1787.2	OA$_ is the symbol prefix for message	IOSG::NEWLAND	Richard Newland, IOSG, REO1-D/4A	`Fri Nov 20 1992 16:40`	10
	'OA$_' is the prefix for message symbols. The implementation of these symbols changed in V3.0, and it may be as a result of this that your form with a name beginning with OA$_ no longer works. What happens if you try get a value form the form by doing: <get OA$_FORMNAME.FIELD[KEY] Richard
1787.3	The GET is not a problem.	EVTSG8::SCOTT	Does anyone look at personal names?	`Mon Nov 23 1992 09:41`	23
	Richard, Doing a <get OA$_FORMNAME.FIELD[KEY] does not cause any problem, the correct value is returned. I know the prefix 'OA$_' is used for ALL-IN-1 message symbols. In V2.3 and V2.4 ANYTHING begining 'OA$_' was evaluated at menu form compilation/display time, so that options defined as :- ;;OA$_FORMNAME.FIELD[KEY];; would work. This is no longer the case. Since <get OA$_FORMNAME.FIELD[KEY] returns the correct value, I don't think the change is due to symbol processing. Has FORM processing changed to ensure that ;;OA$_something;; is an actual entry in the message file? Again, thanks for any info. Colin.
1787.4	Major surgery, so not surprising	IOSG::SHOVE	Dave Shove -- REO-D/3C	`Tue Nov 24 1992 12:11`	14
	The code in the symbol processor had major surgery in v3.0, so it isn't surprising that this has changed. The whole mechanism of "message symbols" (ones starting XX$_) was changed to use the new .A1$MSG and .A1$SECTION files. In particular, I found the following comment in the change history: ! 11-Jul-90 Add new routine Oa$sym_is_symmes. ! Add new routine Oa$sym_store_symmes ! and removed Oa$sym_store_msg_special ! and changed position of test for ! message syms in Oa$sym_get_symbol. Dave.
1787.5	Gone with the wind?	EVTSG8::SCOTT	Does anyone look at personal names?	`Wed Nov 25 1992 11:04`	38
	Dave, Thanks. One thing though.... are the comments from the form or symbol processing routine? (<get OA$_FORMNAME.FIELD[KEY] works). I know message 'special symbols' are a LOT easier to create and manage in V3.0 but not simple enough for a normal user to use. According to 'The Guide', you cannot create application specific message symbol files, they have to go in the OA$_ (generic) area and installed by the ALL-IN-1 manager. Is there any way in V3.0 where, non message symbols, user defined options can now exist on a menu? I've tried :- ;;#TRY;; ;;@#TRY;; ;;$TRY; ;;@$TRY;; ;;ENT.TXT['TEST'];; ;;@ENT.TXT['TEST'];; ;;OA$_ENT.TXT['TEST'];; (this one was ok in V2.3 & V2.4) ;;@OA$_ENT.TXT['TEST'];; None of these work. I guess the 'FEATURE' has been 'Solved' and is gone for good... Regards, Colin.
1787.6	;;xxx;; now only works with _real_ message syms	IOSG::SHOVE	Dave Shove -- REO-D/3C	`Wed Nov 25 1992 11:26`	17
	The forms compiler actually does a special check specifically for message symbols. In v2.3 and v2.4 (I only looked at v2.4) the check was: are the first four characters OA$_? if so, look up the symbol (effectively do a <GET) In v3.0, because message symbols can begin with other strings than OA$_, there's a new routine which checks whether the symbol is _really_ a message symbol (oa$sym_is_symmes) - this routine does a lot more than just check the first four characters. The forms compiler calls this routine. So, the (accidental) feature has gone - sorry. Dave.