Custom statements and functions


#1

Are all the custom statements that were in Panoram 6 built in to Panorama X? Also there were custom functions (Provue) and custom functions (user). It seems that the custom functions (user) was just a Panorama database that I’m assuming can be converted to a Pan X database and registered as is. Are the items in the custom functions (Provue) built in to Pan X?


#2

Looking at the list of unimplemented statements and functions, I see several that I recognize as custom statements in Panorama 6.

The database was a wizard that created a file named Custom Functions (User).fdf. When Panorama launched, it would load all the .fdf files in the Functions folder and register them. RegisterFunction is listed as an unimplemented statement, so there are currently no provisions for registering our own custom functions.

Many of the functions in Panorama X are custom functions. Their definitions are stored in a file named CustomFunctions.def, in the Resources folder in the PanoramaX application bundle. You can open it with a text editor and read it, if you are curious to know which functions are custom functions. Some functions that were core Panorama functions in Pan 6, are custom in Pan X, and vice versa.


#3

Well, how about registercustomfunction?

I’m a bit confused at the moment – I’m not sure why this function isn’t called registerfunction like it was in Panorama 6. Maybe just a mistake? It looks like it is designed to be the same statement, even with an extra parameter retained “for compatibility with Panorama 6”. So I think I just goofed on the name. I have just modified the source code so that in the next version either of these names will work.

Panorama X doesn’t support the custom function wizard, and I don’t think it ever will. This is the first I ever heard of anyone using that wizard. Most people used the registerfunction statement (at least most of the handful of people that ever used custom functions at all). So if you have a custom function wizard, you’ll have to rework that to initialize the custom functions yourself. Shouldn’t take more than a few minutes of programming.

Custom statements aren’t fully documented yet, but there is a short discussion of how to do this in the 0.1.028 release notes:

Also, if you search this forum for custom statements, there has been some detailed discussion about this.


#4

Thanks Dave, but I believe I read in a previous update from ProVUE that you can create a database and register custom functions. My problem is that I am converting a database that used custom statements and functions in Pan 6 extensively and it’s currently not recognizing many of them them. Since I didn’t write the files originally, when it comes to the custom statements, I’m not even sure which ones are custom and which were built in.


#5

When you search for a statement in Panorama Reference, a custom statement looks like this

and a built in statement looks like this


#6

I’ve registered (for my own use) more than 50 custom statements plus a function for each of them. When I get this Database Exchange stuff sorted out, I propose to put them out for everybody.


#7

Thanks Jim. I knew it was there.

I searched the forum and read the posts but none of them answered my question.


#8

This topic got me to registering the one function that I use often. I made a mistake in the syntax of the registercustomfunction statement, and it resulted in Panorama X not recognizing my copy as being logged in.


#9

Wait – are you saying that a problem with the registercustomfunction statement caused your Panorama account to log off? So you had to go back to the Site License and log in again? That seems very, very strange.

Did you eventually get it to work?


#10

Yes, it was difficult to log in, because of that syntax error.

I got it to work by correcting the error.

The function takes addresses from the Post Office’s Zip Code lookup, which are all caps, and converts them to more readable initial caps. In the Panorama 6 Wizard, it is called uwaddress(addr) and if replacemultiple(upperword(addr),"0Th,1St,1Th,2Nd,2Th,3Rd,3Th,4Th,5Th,6Th,7Th,8Th,9Th,Po ",“0th,1st,1th,2nd,2th,3rd,3th,4th,5th,6th,7th,8th,9th,PO “,”,”)

This is the proper line of code:

registercustomfunction “uwaddress(”,1, {replacemultiple(upperword(•1),"0Th,1St,1Th,2Nd,2Th,3Rd,3Th,4Th,5Th,6Th,7Th,8Th,9Th,Po ",“0th,1st,1th,2nd,2th,3rd,3th,4th,5th,6th,7th,8th,9th,PO “,”,”)}

In my hasty reading of the directions for registercustomfunction, I think I had:

registercustomfunction “uwaddress(”, replacemultiple(upperword(•1),"0Th,1St,1Th,2Nd,2Th,3Rd,3Th,4Th,5Th,6Th,7Th,8Th,9Th,Po ",“0th,1st,1th,2nd,2th,3rd,3th,4th,5th,6th,7th,8th,9th,PO “,”,”)

in my CustomStatements .InitializeFunctions procedure, which caused all sorts of merriment.

It is a little difficult to deal with the CustomStatements database, because it normally does not show up anywhere, and even the Library does not show in the Finder without some fiddling. I dragged it to the desktop (or as I have learned to do, copy it in the Finder and paste it there to make a copy).

Now that it is correct, there is no problem.


#11

Ok, thanks for that detailed explanation, that makes perfect sense now. It’s not so much that there was an error in the registercustomfunction statement in particular, but simply that there was any runtime error in the .InitializeFunctions procedure. Since this procedure is run when Panorama is starting up, the error prevents Panorama from completing the startup process, including logging in, which is one of the last things Panorama does when starting up.

I’ve filed a bug report, and also fixed the problem.


Registering custom function in .InitializeFunctions procedure in Custom Statements database
#12

Another problem was that I do not recall getting an error message when I first closed the .InitializeFunctions procedure.


#13

Sure, it was a runtime error, not a syntax error.

For example, suppose you have code like this:

field xyz

Even if there is no field xyz, you won’t get an error when you close the procedure, only when you actually run the procedure.

So an excellent idea for the .InitializeFunctions procedure is to run it manually when you set it up to make sure there are no runtime errors. Actually that generally goes for .Initialize procedures also.


#14

And if this .initialize is going to run on an Enterprise Server, you will be sorry if you did not double, triple check it before you send it off. :wink: