"unmatch control word" error message

[Han]

(12-24-2013 02:02 AM)Bob Frazee Wrote:  Han;
It occurs when I execute the WindChillPgm program. I went back and checked the subroutine and found a syntax error. I cleared that by inserting in the InputPgm(),DegF,Mph in the parenthesis of the subroutine.

So you changed the how the program InputPgm was defined from InputPgm() -- no arguments -- to InputPgm(DegF, Mph) which takes two arguments. Did you realize that DegF and Mph as used are now also a local variable to the InputPgm, and distinct from the non-exported global variables of the same name?

Quote:Next I got an "invalid input" error message.

Well of course you would. You just changed the how InputPgm was defined, so that it now requires two input values. The program that called InputPgm was called as: InputPgm() -- without arguments -- so that is why you got the invalid input error.

Quote:Went to the "WindChillPgm", and added DegF,Mph in the parenthesis of that InputPgm() statement. Now I have no errors in either program, but the values I enter into the INPUT statement, are not being returned to the main "WindChillPgm".

Because you created an instance of local variables in InputPgm having the same name as global variables that you declared at the top of your source file. Local variables have highest priority in the case of variables of the same name but of different types overlapping in scope.

Quote:Actually, I'm not sure how to get the variables back to the main program. I tried {DegF,Mph}:=InputPgm(DegF,Mph); in the main program but that gave me an invalid information(green i) input error as soon as I hit the check button, but it did allow me to exit the program and run it again. When I ran it, it gave me an error "bad argument type", and dumped me out of the program. Hope this helps. I'm still curious as to what "unmatch control word" is.
rcf

InputPgm was not coded to return anything! Moreover, programs can only return a single object. So if you want multiple results returned, you must return a list containing each result. This list object must then be saved under a single variable within the calling program.

You are completely misusing variables. You declared several non-exported global variables:

Code:

DegF;Mph;wct;wcto;ft;

When you passed the values of two of them in

Code:

WindChillIntroDisplay(DegF,Mph);

did you ensure that the WindChillIntroDisplay routine was defined to take two input values? That is:

Code:


WindChillIntroDisplay(a,b) // <-- notice the dummy input (local) variables?
BEGIN
  // some code
END;

I presume this is what you meant by adding in the variables inside the parentheses. If WindChillIntroDisplay was not defined to take input, then you will certainly get an error. What I don't understand is why you even pass global variables at all. The whole point of global variables is that all programs/subroutines in that source file can use the variables without having to pass them to each other. When you "went in and added DegF and Mph into the parenthesis" you basically created LOCAL variables of the same name as the non-exported GLOBAL variables. Those local variables have higher priority than the global variables. I wrote two articles explaining both the types and priority of variables as well as how to declare them. You may want to peruse them for some clarification.

None of your subroutines should need to pass global variables around. That would defeat the purpose of global variables. You simply declare them at the top and then just use them just like you would use any of the upper case variables A through Z. So WindChillIntroDisplay and all other programs should only be called (and defined) without arguments unless you are passing values not stored in a global variable.