Call statement behaving badly


#1

I have a database with two procedures which, up until today, have worked in perfect harmony. One of them calls the other like this:

let TagsInList = ""
let ListName = "3WLDS030LBP07313 3WLDS030LBP80987"
call ".ExpandTagSequence",ListName,TagsInList

but the call statement gives the error message, “CALL statement failed, procedure .ExpandTagSequence does not exist”

I then create a new procedure containing nothing other than those three lines of code (copied and pasted) and the call statement works perfectly.

I’ve renamed the two procedures, created two new ones and copied the code into them. I’ve quit and rebooted Panorama X and I’ve re-installed Panorama X, all to no avail.

What do I do next?


#2

The first procedure is incapable of calling any other procedure. Presumably it’s corrupted and copying it just propagates the corruption. Do I really have to type it all again? Maybe copy bits at a time and see where it fails?


#3

Episode 3: This works:

farcall "Control Panel",".ExpandTagSequence",ListName,TagsInList

even though both procedures are in the Control Panel database and a farcall is unnecessary. A bug in the call statement or another aberration on my iMac?


#4

The call statement only works within the currently active database. That isn’t necessarily the database that contains the call statement. If you used window, openfile, or any other statement that changes the active database, the call statement will now be trying to call a procedure in the database that is associated with the currently active window, NOT the database that contains the call statement. Remember, changing the active window changes the whole context the program is running in – different fields, different forms, different procedures, different fileglobal variables.


#5

I may, in fact, have another database active. The situation is that database A issues a farcall to procedure X in database B. Procedure X then issues a call to procedure Y, also in database B. Hence, the call to procedure Y needs to be a farcall.

This double-call process occurs only in an odd circumstance and I suspect that I had not adequately tested it prior to today, which is why I thought it was working with the original code.

Thank you for the mini-tutorial which, I’m sure, will be of use to other users.


#6

Note that using the farcall statement does NOT change the currently active database. So after the farcall of procedure X in database B, database A is still the active database. So when procedure X calls procedure Y, it must use farcall – even though procedure X and Y are both in the same database (B), the active window is still in database A.


#7

If I’d had my wits about me (an increasingly rare event these days), I’d have realised that the message, “.ExpandTagSequence does not exist” was a dead give-away that I was looking in the wrong place.