Can cursor focus be set

I have a button in a form, which uses getscrap to open a dialog box. The text that I enter in that dialog box is used as part of a formula to make a selection of records. Everything is working normally, except, when the dialog box opens, the cursor is not focused there to enter text. If I forget to click in the text entry box first and type without focus, the procedure runs to completion, but no selection of records is made.

I could not find any reference to setting cursor focus in Panorama X Help, and I have not found a function that manipulates the cursor. The only bit of information that I have found so far was this single note from RAmeeti in April, 2017.

[“Fill with Value, or Formula Fill, does not retain the formula that it last used if it is re-selected after a previous use. (Is there a reason for 2 different terms for this item?)

Will this dialog have available to it an assist from the menu bar or a pop-up, of formulas with parameters?

It would be nice if the cursor was automatically placed in the text box when the dialog first appears.”]

I am wondering if anyone has a comment on how to programmatically control the placement of the cursor. (I am also curious as to what “getscrap” is short for.)


The problem with the text entry not being active when opened is an Apple bug/feature that is present in all the text entry items using the standard Apple code. I came up with an alternative called GetTextSheet which is a simple text entry dialog that opens as a sheet and drops down from the tool bar of the active window. Since it is a custom rendition I have it set to make the text entry box active and ready for text input as soon as it opens.

You will find this custom statement available in my Gary’s Additions1 file on the Panorama Database Exchange under the Help menu. Once you download, run and install this file you will have the included items available after you restart Panorama X. You would then use this statement the same as any other Panorama statement in your code. Here is what the GetTextSheet looks like:


Note that this solution will only be for use locally where it has been installed and would cause an error if run on a computer that did not already have it included. Also note that once this has been installed it will remain available through any future updates of Panorama X and not need to be reinstalled.

Hi Gary,

Thank you for that information. Maybe, some day, Apple will correct this situation. I will give your solution a try and see how it works out.


Hi Gary,

Thank you for providing that code. It works great, and it does exactly what I was looking for! I just needed to study your procedure code for a few minutes until I understood what type of information parameter(1) and parameter(2) needed.

At first, I assumed that the installation program would make your code global to any of the databases in my library that called it. After working with it, it seems that your procedure needs to be copied into the group of procedures that reside in the database that needs to access it. But that is okay and easy to set up. I would not be surprised if there is a way to use you extension globally in the database library, but that is over my head at the moment.


Ken, that should already be global if you installed it into the Library/Application Support/PanoramaX/Libraries/ folder. It would also have to be installed in any additional user’s libraries if you have more than one user on your system. Other than that, it should be available in all the databases without any further action on your part.

Hi Gary,

I moved my databases from their folder on the Desktop to a newly created Libraries folder in Library/Application Support/PanoramaX. The only folders previously in the PanoramaX folder were the Client and Server folders. Much of the time after doing that PanoramaX was unable to open any database. Sometimes restarting PanoramaX would help and sometimes it didn’t. I then moved the Libraries folder into the Library/Application Support/PanoramaX/Client folder, and that corrected the trouble of not being able to open a database file. After reinstalling your database, and closing and restarting PanoramaX, I tried a call to GETTEXTSHEET from a database. A dialog popped up saying “CALL statement failed, procedure GETTEXTSHEET does not exist”.

I am not sure what I am missing, but at least everything else is working.


There should not be a CALL involved here so I’m thinking you have misinterpreted something. Ok, maybe we should start from scratch with this. When you first download and open the Gary’s Additions1 file it will run the .Initialize procedure which will ask you if you want to install the file in your Panorama X library:


Clicking the “Ok” button will install a copy of the file into the proper library folder and then alter the .Initialize procedure so the installation code is removed. At this point if you restart Panorama you will have the GetTextSheet statement available in all databases as well as the included custom functions which are part of the file. I should have made it clear that manually moving the file to the library folder alone will not work in as much as you have to alter the .Initialize procedure as well.

If you already had a custom statement and or custom function file in the folder, you could simply move the GETTEXTSHEET procedure and the “•|•|•” form from my file to the existing file in the library folder and restart Panorama from there for it to be registered and working. The move could be easily accomplished by having two View Organizer… windows open (found in the View menu). One would be for the Gary’s Additions1 file and the other would be for the existing library file in your Library/Application Support/PanoramaX/Libraries/ folder. Dragging the two items from one file to the next will transfer a copy of them to the second file. A restart of Panorama will make the GetTextSheet available to all files.

Once installed you would code it the same as a normal GetText type statement:

Let whatName="Joe Doe"
gettextsheet "Enter the name…",whatName

This will drop the dialog sheet down from the tool bar and be ready for the entry of a name which will be returned in the whatName variable (or whatever variable or field you are using).

Hi Gary,

I see now that I was not installing your database properly. I have rarely used the Downloads folder, so normally I am not likely to install a program from that folder. I have a habit of downloading programs to the Desktop, where I can find them easily. I actually had to search for your database file the first time I downloaded it, because I forgot to look in the Downloads folder for it.

The problem that I had with the installation procedure is also due, in part, to my unfamiliarity with how the Panorama Database Exchange works. I easily found the Download button, and downloaded the file. But I was a little confused by the Open button, since I had not done anything other than download your file. I was surprised to see your database open up as soon as I pressed that button. Of course I clicked on the Ok button when it asked if I wanted to install your database in my Library folder, but since nothing visual changed after the Ok button was pressed I did not know if the process had been a success or not.

After reading your last response, I removed your database and installed the program properly, according to your directions. First, I created a Libraries folder in Library/Application Support/PanoramaX. Just as you said, I found your database in that folder after I had installed it from either the Downloads folder, or from the Panorama Database Exchange. I then moved a few of my databases into that Libraries folder.

I was unable to open any of the databases that were in that Libraries folder, including yours, either through PanoramaX or from the Finder. However, after some time fiddling around doing other things, as well as quitting and restarting PanoramaX, I could open a database using PanoramaX or the Finder—sometimes but not always. In my case, it certainly is not a location that can be relied on.

I have no problems if my library of databases is somewhere else, such as in a folder on the Desktop or in the Library/Application Support/PanoramaX/Client/Libraries folder.

As you suggested, I did try moving the GETTEXTSHEET procedure (and its associated Form) around. First I moved your database in whole between library folders. After removing the unwanted copy of your database from the inactive library folder, GETTEXTSHEET was not found by any of the other databases in the active library folder. I also moved the GETTEXTSHEET procedure that I have modified from one of my databases to your database, both in the same folder, and it was not recognized globally. I realize that I may not have manipulated this file the way it needs to be handled, but right now I am out of ideas. However, this is not a pressing problem, since I can continue to use your very handy GETTEXTSHEET procedure as long as it is in the calling database


First of all: We are talking about your user library folder, not the Library folder on the top level of your disk. So the path should read

~/Library/Application Support/PanoramaX/Libraries/

That’s where _Gary’s Additions1.pandb goes.

But, Ken, your databases don’t belong there. They should stay somewhere in the Documents folder of your macOS user account.

Hi Kurt,

Thank you for providing those comments.

You are right about using the tilde in the path description. That is the path that I was using. I was just being lazy about typing the tilde, partly because PanoramaX does not occupy a position in Application Support in the top level Library folder.

I am confused about where my databases should be, in order for them to be connected with other parts of PanoramaX. Up to now, I have just used a conveniently named folder on my Desktop to store my databases, and that has worked out well for me as I develop my databases and work through problems. I only started moving the database files around yesterday as an experiment to see if having them in the same folder as Gary’s database would allow me to use _Gary’s Additions1.pandb globally. But it turned out that for much of the time that the databases were in that folder, they could not be opened.

I do not have many databases at the moment. Most of them are different versions of the same database that I keep around as I add features and as a secondary backup to go back to when I mess things up. So, at this time, having the ability to access the features that Gary provides in his database are not essential, as long as I can apply them locally.


In general, your databases should be somewhere within the Documents folder. The OS was designed such that you would then use an alias on the desktop for easy access.

The files (tables, databases) that are kept within the the Libraries folder path are ‘referenced’ rather than opened and continually altered. Those files should just have really cool stuff that you like to make use of, not ones that you enter, edit, and delete records from on a regular basis.

Well, I think things went a little off the rails here at some point. Let’s start with the basics of how things are set up to work with custom statements and functions. The Panorama X application is actually a package that contains the actual application along with many resource files including many files containing Panorama’s own statements and functions. These support files are opened secretly when Panorama starts up so they are available to all user databases that are subsequently opened. At startup Panorama also looks for files in the user’s Library/Application Support/PanoramaX/Libraries/ folder and opens them secretly as well. All included user custom statements and functions are then also registered and ready for use the same as Panorama’s own.

Your Panorama database files can be located almost anywhere convenient to you and can all use these registered custom statements the same as Panorama’s own statements and functions. If you have installed the file in the above location and it contains the properly formatted procedure for the custom statement along with any accompanying forms, it will be available to all Pan X databases. To make sure things are correct, run this code:

message customstatementdatabase("gettextsheet")

This should return the name of the file containing the gettextsheet statement. To use this statement read the Help file for gettext and simply substitute gettextsheet for gettext and follow those instructions. The parameters are the same for both statements. I can only guess the problem you have with it only working “locally” is because you are somehow using a call to the procedure which you have added to one of your own files. If it is installed correctly it will be “universal” to all files.

Hi Robert (It looks like this discussion has come full circle now.),

I did not know that the Documents folder occupies a special place in the proper functioning of the OS and other programs. I will keep that in mind and sort out my files accordingly.


I will give it another try after first removing my database files from ~Library/Application Support/PanoramaX, and reinstalling your database in ~Library/Application Support/PanoramaX/Libraries. Then I will run the code that you suggested: message customstatementdatabase("gettextsheet”).


Ken, the Library folder at the root level is not the Library folder you want to install the file. You need the User/username/Library folder and there you should already see a PanoramaX folder in the Application Support folder. I know it can be confusing having more than one Library folder located at two different levels in the Finder. My graphic above shows the hierarchy of the proper Library folder on my hard drive. You would just need to substitute your Hard Drive name if different and your user name in place of mine.

Note: I just thought that if you let my file do the installation to start with it might already be properly located and you might have been trying to use it via a call statement instead of directly as a custom statement. Just a thought. :thinking:

Gary, ~/Library/… is the correct path to the user Library. The tilde stands for the actual user.

Ken, this is not an absolute precondition for the proper functioning of macOS, but it is simply the logical place. — On the other hand, there are such preconditions in macOS; e.g. some applications will work correctly only when they are sitting in the Applications folder itself, not in any subfolder. — So it was no issue to store your databases on your Desktop (that is basically a folder in your user account) as well, but I think the macOS logic is clear: documents should normally be stored in the Documents folder.

Hi Gary and Kurt,

Thank you both for helping me avoid any confusion about where to place the database files. My next step is to sort things out and start fresh with the installation of Gary’s database.


Panorama doesn’t care where database files are kept. As long as they are in a location that is visible to you and that you have permission to access, it is fine. You also generally want to avoid using locations that the system or an application use for their own purposes, so I would avoid placing general files inside any Library folder (other than a specific file in a specific place for that purpose, for example as Gary has instructed). That’s why Apple generally makes the Library folder a bit difficult to access – you are not supposed to mess with the contents of that folder unless you know what you are doing.

Normally, putting documents somewhere nested inside your user folder is the traditional way to do this. The desktop is a folder inside your user folder, so that is fine. The documents folder is also fine, as it is inside the user folder. (The ~/Library folder is also inside your user folder, but that should generally be avoided as described in the previous paragraph.)

Hi Jim,

Your comments support the way I generally deal with my files and programs.


I reinstalled your database, removed all of my files from the …Application Support/PanoramaX/Client folder and put them in my Documents folder, and removed any Call reference to the GETTEXTSHEET procedure in all of my databases. I also removed all of the local copies of the GETTEXTSHEET procedure and its associated Form. I compared the GETTEXTSHEET procedure that is in your database to the copy that I made for use locally in my databases. They are identical. I ran message customstatementdatabase(“gettextsheet”) from one of my databases and got back the name of your database file. When I reactivated the Call to the GETTEXTSHEET procedure in the same database, the same error message was returned. Please let me know if you have any other suggestions.


I suspect you are using an actual “Call” statement here, something like

Call GETTEXTSHEET, "your prompt", variable

It should actually be

gettextsheet "your prompt", variable

The name of the custom statement isn’t case sensitive. It could have been all uppercase, or mixed case. It’s called a custom statement, because you treat it like that was the name of a statement. You don’t use Call, or FarCall.

If Panorama doesn’t have an actual statement by that name, it checks the list of registered custom statements, to see if it’s there. If it is, the registration will tell it which library database it’s in, and it will do a FarCall to that procedure in that library database. A simple Call statement isn’t going to work, because a Call is always a call to a procedure in the currently active database.

Well, the solution might actually be much simpler.

Ken’s question was how he can get the text entry focus in a dialog. I just found the supergettext statement in the documentation. It solves all problems. Here is a code sample:

local AreaCode
supergettext AreaCode,{textselect=all}

It produces a dialog window with an entry field where the default text is selected and can immediately be overwritten.