Farcallwithin Fails Using a Variable for the Database Name

Panorama X
1

farcallwithin fails under this circumstance …

local currentDBname, newWindow

currentDBname = info("databasename")
newdatabase
newWindow = info("windowname")
setactivedatabase newWindow
    farcallwithin currentDBname, .myRoutines, "label_MyCommand"
setactivedatabase ""

The error is “statement failed because currentDBname database is not open”. Can a variable not be used in this instance?

2

Figured it out, the variable must be part of a formula:

farcallwithin currentDBname + "",  .myRoutines, "label_MyCommand"
3

Yes, it was assuming that there was a database named currentDBname. That way, you don’t have to quote the database name in the normal case of a fixed database.

Your procedure has some other potential problems. The two lines of code after the newdatabase statement

newWindow = info("windoname")
setactivedatabase newWindow

don’t do anything. The active database is already the new database, so you don’t need these two lines.

The final line of code,

setactivedatabase ""

also doesn’t do anything. The active database is already associated with the current window. (Note: I’m assuming that .myRoutines doesn’t use a secret window, in that case setactivedatabase "" would do something, but it would be much cleaner to put it in the .myRoutines code if so.)

So, assuming .myRoutines doesn’t use secret windows, your code could be reduced to:

let originalDatabaseName = info("databasename")
newdatabase
farcall originalDatabaseName+"",.myRoutines,"label_MyCommand"

(I changed the name of the variable because I think calling it “current” is confusing, since it isn’t current. But of course it’s your code, so use any name you like.)

P.S. It warms my heart to see someone using callwithin. I don’t know how many of you use it, but I love it and use it frequently. Really helps to cut down the number of items in the View menu and help keep code organized.

4

Jim,

Thank you for pointing out my error when using the “newdatabase” statement. I mistook where program control would be after that statement, assuming it would remain in the old database and that I’d have to switch db’s in order for my code to control the newly created db.

I’ve discovered one very interesting issue under this circumstance. When declaring a file global (I haven’t tested it with other variable types) and setting a value for it prior to the newdatabase statement, then that file global is not available in the code after the newdatabase statement. My expectation was that it would be.

fileglobal fgVariable

fgVariable = "random text"
newdatabase
message fgVariable

The code fails at the message command.

Alternately …

 fileglobal fgVariable
 local fgVariableLocal

 fgVariable = "random text"
 fgVariableLocal = fgVariable
 newdatabase
 message fgVariableLocal

Has the expected result.

I very much enjoy the somewhat recently added ability to put subroutines and functions into a single procedure. It’s very powerful and allows for much better organization.

I usually flesh out an idea in a new procedure and when it is debugged, then I put it in the “.myRoutines” or other similarly-named procedure.

5

Finally, figured this out as well. The unsaved database file created by the newdatabase statement won’t share the file global variable because it is a separate file.

Ah well, sigh.

6

Bingo!

FYI, in Panorama X you can exclude any procedure from the Action menu – you don’t have to prefix it with a period (though that will still work). In other words, your procedure doesn’t have to begin with a period if you don’t want it to.