Can cursor focus be set

Panorama X
10

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.

Ken

11

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.

12

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.
image

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.

13

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.

Gary,

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

14

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:

15

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.

16

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.

Ken

17

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.)

18

Hi Jim,

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

Gary,

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.

Ken

19

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.

20

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
AreaCode="909"
supergettext AreaCode,{textselect=all}

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

21

Hi Dave,

Well, that cuts it! I have made many mistakes during the process of getting Gary’s procedure to work for me globally. But your suggestion was the last piece needed to solve the puzzle.

This is the first time I have tried to call a procedure from inside a form. So far, most of my coding has been done within forms. When I was first setting this up, I saw at a picture in one of the help pages that showed one line of code calling a separate procedure. That looked easy enough, so I just mimicked what I saw when I wrote my code, without investigating it further.

Now the corrected procedure works perfectly, and globally. I will now retire to my studies, write some more code, and try not to make the same mistakes twice.

Thanks to everyone who helped. A simple question on how to make something more convenient just blossomed into a great experience.

Kurt,

You are too much! Just as I was posting this, you have offered an answer to my original question. I will certainly try this out.

Ken

22

Regarding placement of files on a computer, it is always the users computer. They can place their files anywhere on their computer that they wish. It is most often than the user doesn’t really want to follow the prescribed ways, nor is it ProVUE or Microsoft that typically has a problem if the user places their files elsewhere. But I am happy to share that I have made a lot of money ‘fixing’ or recovering files that have been left behind or not having been backed up by utility programs that expect for music files to be saved in the Music folder, and pictures in the Pictures folder, and videos in the Videos folder and documents in the Documents folder. Even Apple’s Migration assistant calls out these special folders for transfer options. Things will generally, most often work just fine, but do note that not every program will always consider the real world in the way that users choose to do things. Yes, the Desktop will work for most anything, but Aliases will also work as well as keep things as someone else might be expecting them. Just a thought to stay safe for those wanting to learn from others.

23

Kurt, you deserve a gold star for this.This issue has come up several times over the last two years and you are, I think, the first person to find that supergettext does not suffer from the same shortcoming. Thanks.

24

Gee, I thought I had mentioned it so many times I was becoming a repetitive bore (hence my failure to mention it on this thread), but doing a quick search it looks like I have only mentioned this once or perhaps twice, not many times. Here is a mention from 2017.

I guess as long as Apple doesn’t fix this problem in the native dialog (it did work in earlier versions of macOS) I should keep mentioning the supergettext alternative at least once per year :open_mouth: :loudspeaker:

25

Is it feasible to modify the gettext code to work the way the supergettext does?

26

As I mentioned before, only Apple can do that. It’s Apple’s code, built in to macOS.

I covered this before, but it was a couple of years ago, so I’ll repeat. The gettext statement is coded using Apple’s “stock” text entry dialog. It uses Apple code, so it will always work the way that Apple has decided is best. For whatever reason, starting with macOS 10.10 Apple decided that not automatically putting the focus on the text was the right way that this dialog should work. I don’t agree, but Apple doesn’t provide any way for a developer to customize the operation of this dialog.

The only way to change any aspect of how gettext would work would be to completely rewrite it from scratch, so that it used none of Apple’s code. I could do that – but I already have done that – that’s what the supergettext statement is. So it seems to me to be silly to make the gettext statement work exactly like the supergettext statement, and leave no method that would allow use of Apple’s stock text entry dialog. If you want the stock Apple version, use gettext, if you want the custom version, use supergettext.

27

I feel like this part of the question didn’t get answered. It isn’t sort for anything; it divides “get scrap” (not “gets crap” as you may be thinking). The thing you copy to and paste from is called the clipboard or pasteboard, but it used to be called the scrap (and the programming interface to it was the Scrap Manager), and copied/pasted material used to be called, and occasionally is still called, the “scrap”. I would suggest that the name be changed to “inputtoclip” or similar.

28

Whoops, I didn’t notice that part of the question at all. Let me elaborate on Matt’s answer.

In the earliest days of Panorama programming, Panorama had no variables at all. The only way to hold on to a value outside of a database field was in the clipboard, which as Matt points out, was also called the “scrap”. The earliest Mac’s also had a Scrapbook desk accessory that you could transfer text and pictures in and out of via the clipboard.

Since there were no variables, Panorama had a few statements that could work with the clipboard as a “poor man’s” variable, including getscrap and scrapcalc.

If this wasn’t an obsolete statement, I would agree. In 2019 Panorama makes it super easy to create and use variables, so I would recommend not using the clipboard as a variable in any new code. The only reason getscrap still exists is because some people have old databases that use it, and I really do try to maintain compatibility with existing databases and existing code to the maximum extent possible. However, I would recommend that no one should ever write any new code that uses the getscrap statement, so there is no point in renaming the statement.

I have added the text below to the help topics for the getscrap and getscrapok statements, to make it more clear that these statements are obsolete, and to add a historical note about the origin of the term.

The problem with the getscrap statement is that it clobbers the clipboard, which you may be using for something else. So if you are writing new code, don’t use the getscrap statement – use the [gettext] statement instead. Here is a version of this code that has been rewritten so that it doesn’t clobber the clipboard.

gettext "Area code:",AreaCode

Historical Note: The word “scrap” is the original name for the Macintosh clipboard from the 1980’s, so the name of this statement came from “get scrap”, i.e. get a value into the scrap, i.e. clipboard. Over the years the word “scrap” has gone out of favor and this feature is now usually called the clipboard, but the original term lives on in the name of this statement.

29

Thank you Matt and Jim for answering my off topic question.

Everyone who participated has been very helpful. I have learned quite a lot in the process. It certainly has helped me discover new features and facets about PanoramaX, including its history. It has prompted me to explore new and different areas of Panorama that I am not familiar with. As frustrating as it can be at times, I have enjoyed working with this program more than any other software I have used.

Ken

1 Like