What is the best way to transfer changes made to a custom statement across multiple computers?
Whenever I make a change or create a new statement, I grab my custom statements library file and manually copy it into the Libraries folder for each computer? Am I missing something on how to easily transfer these changes in a server environment?
Yes.
Sorry, no, the library is a single user file and not in any way managed by the server. That could be an interesting idea, but it’s not immediately obvious to me how that would best be done.
I wonder if you could do it with Apple Configurator. I have never used it, so I could not say myself, but I could imagine it could do that.
I tried uploading the file to the server, for some unknown reason it didn’t upload. I didn’t investigate further.
I will check it out Bruce, thanks!
I don’t know why it didn’t upload. But I don’t think it’s a good idea to make this database shared, the code that loads libraries when Panorama launches is not going to expect a shared database. I mean you could try it, but it definitely wasn’t written or tested with that in mind. I’ve been pondering this over the last 24 hours and it seems like a difficult problem.
If your application has a master file that users always load you could put your custom statements in there.
I’m sure that with some trial and error I could probably figure this out, but how would custom statements be loaded on startup in this configuration? Would I just use load library?
I just tried an experiment using a simple procedure I called TESTGARY in a database with code to popup a message of “OK”. In the .Initialize procedure of that database (MyTestDB) I had this code:
loadlibrary "","MyTestDB"
Now when this file is opened the testgary statement is loaded and available for use. It remains available even if I close the database containing the custom statement procedure. I don’t know if this is the recommended method but it does work. Make sure there are no other procedures in that database named with all uppercase letters or they will be loaded as custom statements as well.
I don’t think this is correct. When you use a custom statement, Panorama is actually just putting a farcall statement in your code. For example, consider the displaydata statement, which is implemented as the DISPLAYDATA procedure in the _DialogAlertLib library database (which is loaded when Panorama launches). Normally, you invoke this statement like this:
displaydata warAndPeace
But actually, Panorama’s compiler is converting this into:
farcall "_DialogAlertLib","DISPLAYDATA",warAndPeace
Same exact meaning, but the first one is a lot easier to type. But the point is, if somehow the _DialogAlertLib database was closed, the custom statement won’t work any more.
Bottom line – if you create custom statements, you should make sure that the database containing the procedures NEVER closes. Panorama won’t crash, but you will get error messages if you try to use the custom statement.
Panorama keeps an internal structure that remembers the names of all custom statements, and what database they are contained in. The function of the loadlibrary statement is to add statements to this internal structure. Once a procedure is added to this structure, Panorama assumes that it will stay in memory.
I just again tried this and used Close Database from the File menu and then checked Memory Usage… to see if the file was still present and it was not listed. I then tried a procedure with the custom statement and it still worked fine with no error generated. How can this be? I don’t have a clue, just reporting my experience. 
So, (aside from Gary’s experience) in a shared environment with a so-called Master File, a FarCall is just as good as a Custom Statement. The only difference being in the code applied to invoke it along with a touch of less effort to set it up in the first place.
Of course, a workaround is to just put the code for the statement in each file that uses it, and call it, instead of using a custom statement. Same holds true for custom functions.
That’s actually what I’m trying to avoid. When a complex procedure is identical for multiple files, it’s harder to accurately maintain; mistakes are easily introduced in one or another copy. When there are several such procedures, it’s all compounded.
Having it all in one place is highly desirable. A change is made once and it’s guaranteed to be the same for all that use it.
You can put the statements in a file that opens without windows which only has the statements and use farcall, and distribute that. As was said, this is the same as putting them in a library file. Then update and distribute that file as necessary.
Understood, but I already had the equivalent of a “master file” with these procedures installed and being accessed via FarCalls. I was hoping to use Custom Statements that would be in memory even if that file was closed by the user. Apparently that can’t be done and I’ll have to stick to the FarCalls.
Panorama X 10.2 has a new option specifically for this situation.
This is in the File>Database Options>General panel. If this is checked, closing all of the windows of the database will not close the database, it will still be open in memory but with no windows. (It can still be closed with the closefile statement.)
Perfect!! And useful for either FarCalls or Custom Statements. Thanks.
