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

Conference noted::hackers_v1

Title:	-={ H A C K E R S }=-
Notice:	Write locked - see NOTED::HACKERS
Moderator:	DIEHRD::MORRIS

Created:	Thu Feb 20 1986
Last Modified:	Mon Aug 03 1992
Last Successful Update:	Fri Jun 06 1997
Number of topics:	680
Total number of notes:	5456

262.0. "CLI$DCL_PARSE Problem?" by KAHLUA::SANTIAGO (Lemon curry?) Fri Jun 20 1986 16:28

    I'm trying to use CLI routines to parse input from a BASIC (no snide
    comments please) program. However, CLI$DCL_PARSE doesn't seem to
    work like it should. I'm calling it with
    
    1)  return_code = CLI$DCL_PARSE(0, COMMAND_TABLE, LIB$GET_INPUT,0)
    
    for getting the DCL command that invoked the program, and
    
    2)  ret_code = CLI$DCL_PARSE(0, COMM_TBL, LIB$GET_INPUT, LIB$GET_INPUT,
    		"PROMPT> ")
    
    for getting input within the program. Problems are:
           
       When using (1) above, it hangs around until you hit RETURN, then
    continues execution of the program but inevitably returns CLI$_NOCOMD
    (no command on line) no matter how the image is invoked. When using
    (2), it sits there (displaying no prompt) and you can type anything
    you like as long as it isn't a null string. If it is, <poof> Memory
    access violation. I've been at it all morning with no results, and
    nobody around here can figure it out. Any suggestions would be warmly
    welcomed. Thanxmuch.
    
    Incidentally, the program is invoked normally (ie "RUN FOO" or 
    "$ FOO :== $MY_DIRECTORY:FOO" + "$ FOO"), not as a command defined
    with SET COMMAND. Maybe this is why (1) fails, but I still see no
    reason for it to just sit around waiting for input.

T.R	Title	User	Personal Name	Date	Lines
262.1	Use External Function	SANFAN::HAYESJO	MicroVAX On Board	`Fri Jun 20 1986 21:16`	28
	Try: Main Program: EXTERNAL long constant Get_Input, cmdtbl EXTERNAL long function CLI$DCL_Parse CALL CLI$DCL_Parse( , cmdtbl BY VALUE, Get_Input BY VALUE, ... External Function Get_Input: FUNCTION long Get_Input( STRING get_str, prompt_str & , WORD out_len ) EXTERNAL long function LIB$Get_Input stat% = LIB$Get_Input( get_str BY DESC & , prompt_str BY DESC & , out_len BY REF ) Get_Input = stat% END FUNCTION Hope this helps! John
262.2		SMEDLY::WELLS	Phil Wells	`Sat Jun 21 1986 02:23`	12
	I did a similar thing is BLISS, however, I created a .CLD that is linked with the image. There is no set command. When using DCL_PARSE, you need to specify the routine name in the .CLD file, which is then invoked by the CLI$DISPATCH call. To get commands passed in the foreign command parsed, make a call to LIB$GET_FOREIGN, and pass the results of this on to DCL_PARSE as the 1st parameter. I am not sure this answers your question, so I offer it FWIW. Phil
262.3	Thanks 1E+6!	KAHLUA::SANTIAGO	Lemon curry?	`Sat Jun 21 1986 21:02`	10
	Re .1: Thank you infinitely! It worked! Perfectly! Re .2: I'm not using CLI$DISPATCH, because then I would have to declare a whole bunch of routines which then couldn't use all my variables unless I declared them EXTERNAL, so anyway it's a kludge but I'm just using CLI$GET_VALUE with "$VERB" as argument and checking one by one. Thanks for the idea on LIB$GET_FOREIGN, it works a lot better than DCL_PARSE since it doesn't return the called program name.
262.4	PASCAL is cleaner with CLI$	SANFAN::HAYESJO	MicroVAX On Board	`Sun Jun 22 1986 02:02`	9
	A "workaround" would be (sorry Ken Hobday, et.al.) to use Pascal or another language that allows you to declare your global routines in your mainline and share global variables. Of course, I'd be delighted if someone could show me how to "globalize" BASIC routine addresses short of EXTERNALizing them. Other than this, VAX BASIC can do everything but ride a bicycle :-).
262.5	Funny I don't have those problems...	TUNDRA::HARRIMAN		`Mon Jul 28 1986 14:04`	21
	re: .4 I don't know what you are having a problem with using EXTERNAL to declare globals. I have no problems getting BASIC to understand all of my routines, even if I have to be a bit verbose sometimes. However, BASIC has all sorts of ways to declare COMMON or MAPped variables and even more sophisticated structures (even though it's a world away from PASCAL)... This is only a half-hearted defense at BASIC since I have been doing lots and lots of things with it, but it sounded to me like you don't use the MAP or COMMON statements, and wish BASIC could intelligently utilize the system symbols and other neat stuff that all the other languages do... Anyway, I have no problems with BASIC and I have applications which use many many routines, including system calls and callable VMS utilities like the SOR$ and EDT$ (ugh) routines. If you are having specific problems, start another note...? -pjh