Is Pan X compatible with macOS Monterey 12.6?
Panorama X 10.2 is compatible with macOS Monterey. If you are still using Panorama X 10.1, you’ll need to upgrade to 10.2 to use Monterey.
I’m running Panorama 10.2.0.b29 on an M1 MacBook Air running macOS Monterey 12.6, and I’d be very hesitant to say they are “compatible.” It runs, yes, but the user interface for simple database use has numerous glitches that make it curseworthy rather than a pleasant experience. I am surprised that no one has been commenting on this in the forum summaries I’ve received, and astonished to find none of my gripes on the official bug list. Maybe the problems are specific to the M1 MacBook Air and you’ve had negligible sales to that platform yet?
Forgive me if I’m missing some obvious fix, or something previously reported. I’m new to this forum and to Pan X. I’ve been using Panorama since 1992, and until recently was doing just fine with Pan 6. Then my MacBook Pro died, so I upgraded to the Air and finally had to abandon my paid-for Pan 6 and start using Pan X. So I’m seven years behind the rest of you. I haven’t taken a course in Pan X, nor studied the help database except to answer specific questions. I’ve converted only a few of my Panorama files so far, mostly just a Wordle solver that I wrote and a few routines I have for tracking book titles and personal notes. My impression has been that there are a lot of good changes, quite a few questionable ones that maybe I’ll get used to, and a great many things that aren’t working well yet. That “yet” means I’m giving you the benefit of the doubt, since you just recently got this port to the M1 working. But why aren’t the interface problems being discussed and addressed? Because I’m the only one who has seen them, and I haven’t documented them here?
Alas, that’s a big task. To start with, manual scrolling of a data sheet doesn’t always get all the way to the final record. Happens to me maybe once a week. I “hit bottom” and can’t go any farther, even with repeated attempts, but I know that I’m not seeing all the records. The workaround is to resize the form window (vertically), after which scrolling works fine.
A bigger annoyance – and one that’s consistent, not random – is that data sheet cells containing text don’t open and display properly if they are near the sides or bottom of my computer screen. I’m working with large enough databases that I like to keep them almost full screen so that I can see lots of columns and rows. In Pan 6 that wasn’t a problem. If a cell was near a screen edge, it opened further in so that the previously set cell display size could be completely shown on the computer screen. Pan 10 instead seems to have no awareness of screen size, and is happy to open a cell display that is partially (or mostly) off the visible screen area. (Have none of your developers experienced this? Maybe you all have large screens and the issue never comes up.) The workaround is that I have to keep my data sheet displayed in only the top half of my screen so that there will be enough space below to open up last-row cells that contain paragraphs of text. And if I open a cell in the last column, I frequently have to close it, swear, scroll horizontally to bring it away from my screen edge, and reopen it. For that alone I would say this version of Panorama is nearly unusable.
Another cell display problem: often an expanded cell display clips or hides a narrow border within the cell area, such that the ends of text lines disappear. I use very small fonts, so maybe 2-3 letters at each end of each line disappear. I haven’t yet determined what triggers this behavior, but it’s common. Maybe something about how the cell boundaries align with my screen resolution.
There are rarer glitches as well. A few days ago I edited a text cell and (after doing something I don’t remember) noticed that the displayed text consisted of two copies of a sentence I had deleted, rather than the text I had not deleted. I closed and reopened the cell and it was now fine.
Thankfully Pan X has not lost any of my data. Kudos for that. Pan 6 was capable of losing newly entered code if I closed the clamshell on an unsaved window and then the computer shut down later. Or something like that. Now everything saves automatically, and you also have infinite undo. Very nice. One glitch I notice, though, is that code windows that I close will often be open again after I shut down Panorama (and also my computer?) and then reopen that file, even if I had hit Save before closing the program. This could repeat over several reopenings, even over several days. It has been my practice since the 1970s to hit Save after every major entry I make to any document or program, but as far as I can tell so far Save in Pan X is a placebo command. I want it to mean “checkpoint the system in its current state,” but the fact that code views later open up again shows me that such checkpointing isn’t happening. That makes me nervous. Oh, well. I can live with it, for now.
That’s a bare beginning on the inconveniences I’ve been having to work around since switching to Pan X. I know you’ve worked hard over the past 7+ years and have done many great and wonderful things to improve the code, but I can also see that the simple, organically grown database tool that I came to love is no more. And I see from the forum that your effort is focused on bugs in advanced capabilities of tools that I’ve never had a use for, or never had available in Pan 6. Great for the power users, I guess, but as it now exists I couldn’t recommend Panorama to a neighbor or student unless they had an experienced wizard around to write the code for them. It’s kind of like the early Mac operating system and Hypercard apps grew up and became Windows 98.
One way to handle/observe the scope of a problem is to move out of the “problem” database and create a small “test” database set up to display just one problem.
For example, after you Save and Close - and the first time you Saved you checked SaveWindowPositions (is that still a thing?) right? Then when you reopen you expect the datasheet to be in the same screen location/size with the same records selected and the cursor on the same record, as when you Saved and Quit - is that it?
I don’t know if that same record/same field is a valid expectation. If it doesn’t work that way, it’s easy enough to implement by storing those things (which record, which field, also screen size and position if needed - probably not) in a permanent variable and use that in an .initialize procedure to move to the desired record/field.
But the point is - just try these “glitches” a little at a time in a new TEST database. Sometimes just a change of Font might make everything right.
For perspective, recall when you could put a Mac OS AND apps on one 3.5-inch floppy disk. Times change. Now Apple intertwines with a developer’s software and Apple’s “contributions” can cause problems. there is nothing the developer can do until Apple fixes it. I sometimes use Simply Fortran (you never forget your first love). After figuring out one issue, the developer told me that by far, Apple/Mac is the most difficult platform to support - because of the issues Apple throws at him.
Also, when I’m dealing with issues, I find myself comparing the program I’m struggling with to some Fantasy program that has absolutely no problems. It doesn’t exist. Selecting a development platform is a little like … hum, darst I dip into those waters … Well, let’s just say you aren’t looking for a perfect one, you are looking for one whose faults you can accept and work with. Because there are always issues.
FileMaker has issues. Access has issues, and so did 4th Dimension and FoxPro. But how is their user support, and what features do they have to provide workarounds?
We all want Panorama to be the best it can be. And with every iteration, for the most part, it gets better and better. I can’t imagine trying to accomplish the things Panorama can do (Not referring to behemoths like Oracle.) using another database platform. Or having such a responsive support community - including the company president himself.
I know it seems like “We the People” should be in charge; the program should do what WE want. But if things get clipped or don’t look quite right in a text window that is scrunched down to its physical minimum needed to display the text, I’m happy to widen it out a bit if that’s what the text/font needs. I’m okay with “listening to the program” to understand what it needs to show the text correctly. If necessary I might even change a font, or font size or add some pads to the front or back of the text.
Should I have to do that - No. But in the past, such issues were caused by Apple, not by Panorama.
Your post mentioned several things. Pick one, set up a small example for yourself, and post an explanation of just that problem - what you expect to happen and what did happen - and we can tackle things one bite at a time [graphic of a boa constrictor swallowing a large pumpkin (image modified out of respect for my vegetarian friends)] and see if we can find a solution for you.
Thank you for the response. I appreciate the existence of this forum, and I’m aware of Jim’s exceedingly helpful and commendable participation.
To answer your question, “I don’t know if that same record/same field is a valid expectation” does not align with what I reported about the Save function. The behavior I mentioned has to do with my opening up a view of one of my procedures, possibly browsing or editing it, then closing the view. Perhaps I open up several such view windows simultaneously or sequentially, then close all of them. I then continue to work in the data sheet, and I hit Cmd-S frequently to save my work. (I have also tried using Save from the drop-down menu.) Eventually I close the program. Later, maybe the next day, I restart Pan X and it opens my data sheet window, but it sometimes opens one or more of the procedure windows as well. If, in response, I then close the offending procedure view(s) again, save, and close the program, when I restart Pan X again there is a good chance that at least one of the offending procedure views will again be open. This can sometimes repeat several times. Eventually it stops happening. Neither the problem nor its disappearance is caused by anything I am doing, so far as I can tell.
I will begin to put some time into reporting other problems I’ve noticed. I have a long list of them, compiled as I wrote my first Pan X program – the Wordle solver – after getting my M1 MacBook Air. That was a few months ago, and I will have to revisit my notes and make sure they are understandable. However, I will generally not be taking the time to build demonstration code for them.
I am familiar with the process of isolating bugs, and with the process of devising stable workarounds and so living with the bugs. (One reason I stuck with Pan 6 all these years. I understood its flaws and limitations, but my code did what I needed it to do.) I have been programming since about 1972, in many languages and several environments. I’ve been programming in PanTalk almost exclusively since 1992.
Jim might remember a bug that I reported in May of 2014, about a strange interaction of lookup( and call( in which a parameter was being assigned a wrong value. Jim replied to my initial bug report saying that it wasn’t possible: the code had nothing in it that could do that. I worked it down to something like a three-line program calling a one-line subroutine, and Jim discovered that I was right. In a personal email, he wrote “Ken, thanks again for the excellent bug report. I mentioned on the QNA list that this will be fixed. As it turns out, the internal logic for the call( function has been completely revamped for the new version, so it turned out that when I tried your test file on the new version it already worked perfectly!” That’s great, though I never got to use that fix because I didn’t upgrade to Pan X. I lived with the workaround, which was to insert an extra, seemingly unnecessary, lookup( ahead of my code’s call( statement.
Alas, it took me a full day to work that bug down to its essentials. I don’t have the time to do that with every glitch I’ve run across. But a bigger problem is that I’m new to Pan X and to this forum. I’m seven years behind all of you, with no overview yet of what’s been developed and why, or of what discussions are ongoing. I’m a newbie here. When I encounter something annoying to me, I don’t know if it’s a feature rather than a bug, or if it’s a macOS problem, or an M1 port problem, a MacBook Air problem, or if I’m using an old approach where there’s a newer command available, or if I’m just being a grumpy old man. So for now it’s better for me to just put my observations out there for all to consider and comment upon, rather than putting in the effort to localize and fully characterize each supposed bug. Maybe we’ll get into bug hunting later.
there is nothing the developer can do until Apple fixes it.
Yes, understood. This echoes my point that Panorama used to be an organically grown little gem of a program and now it isn’t. (Not so little, of course; tremendous effort must have gone into developing even the 1992 version. But it did fit on one 3.5" floppy.) Many of Panorama’s features grew out of contributions by developers who just wanted an easy way to do something, without much concern for how that fit into a bigger system. The system itself grew to accommodate those clever interfaces. Now, to gain the advantage of using macOS system calls, many of these organic interface features and shortcuts seem to be missing. Sorting a column used to be a single keyboard command, now I have to go through several clicks on a drop-down menu. Filling a field with a constant value used to be easier; now I have to use the morph menu. Cutting and pasting records is more difficult. And to search a database I have to specify superset or subset and then do the search, rather than having separate buttons for select more or select within. (Also, the search is not remembered and so I have to keep re-entering parameters if I want to repeat it. Or have I just not learned yet how remembered search works?)
These aren’t bugs, and I don’t expect anyone to “fix” them. And I’m sure there’s some new way to set up keyboard shortcuts or otherwise adapt the interface to my preferences. I could probably even write code myself to pop up dialog boxes that help me do things the old or easy way. I’m just sad that the simple, few-click interfaces are gone. So far, in my very, very limited exposure to Pan X, it feels like we are all, even newbies, expected to use an Advanced level of the program. The training wheels are missing, or buried in a help file that resembles the thick user manual that came with my Toyota. It’s great for professionals, but so were the racks of IBM manuals that I studied at the beginning of my career. Those manuals were later supplanted in my life by a couple of thin books on C and Unix. Later I bought the 4D database system for home use and, on the same day, Panorama to be my spreadsheet. I tried to learn 4D but it was really hard. I found Panorama could do the same job for me, in addition to being a spreadsheet. Later in life I had to learn FileMaker and Excel, but Panorama was always the winner. Thanks for that. I’ll stick with it, but I’ll miss what it used to be.
–
Ken Laws
Grumpy Old Man
I can confirm that one and have a database that does it consistently. With all selected and one column alphabetized, I can’t scroll past the mid-T’s when there are 8 records left below. The scroll bar indicates that it’s at the bottom.
Using the Down arrow key, I can see the top of the next record highlight before it moves on to the rest of them without showing them. A form window does properly update with their data as each record is accessed.
Resizing the window, even to make it smaller, does make them accessible.
I have never seen or heard of this issue.
Great – if you have a database that displays this problem it would be awesome if you could send it to me, because I definitely have never seen this problem.
This may be an Apple bug, because all of the code that handles scrolling in the data sheet is Apple code. But if I can duplicate the problem, perhaps I can figure out a workaround or at least send a sensible bug report to Apple.
This is in fact in the bug tracker database.
As you can see, this bug report is over 8 years old, and I submitted it myself. The fix for this is fairly complicated, it will likely take several days of work. As you have noticed, there haven’t been any additional complaints about this in the past 8 years. To me, that is a sign that this isn’t a priority project to devote multiple days of work to. Every task worked on means some other task not worked on. I’m afraid that there are not infinite resources available for work on Panorama, in fact, the resources are very limited. I won’t say this issue will never be resolved, but it’s unlikely to get a priority bump.
I would think a much better workaround would be to set up a form for editing text that contains paragraphs of data. The data sheet isn’t really a great tool for editing super long form text. I think that’s why there haven’t been other users complaining about this issue – they probably all set up a form to edit this sort of data. The Panorama X help system is all contained in a database – some cells contain 50 pages of text, but I certainly don’t ever try to edit that in the data sheet.
I have no idea what you are describing. I can say that the software (and virtually all macOS software) is independent of screen resolution.
That sure sounds like an errant key stroke (Command-V) on your part. I’ve definitely never heard of Panorama doing that on its own.
The current state of the system includes all data, form arrangement, and procedure code. It does not include the window arrangement.
Panorama X uses Apple’s document management system. This system is “smart” so that when a save is requested, it only actually saves if the state has changed. You can tell that the state has changed because the red close circle in the upper left of the window has a little black dot in it. Also, the Undo command will be enabled. If there haven’t been any changes since the last save, there will be no black dot, and the Undo command will be dim. You can easily experiment and see that if you modify the data, or the procedure code, or a form, the black dot appears. But simply rearranging windows does not make the black dot appear.
It’s true that when the database is saved, the current window configuration is saved. But changing the window configuration is not an undo-able change, so it a window configuration change cannot be saved unless some other change is also made. The only way to change this would be to make window configuration changes undo-able, which I think would be very non-standard and horrible. Or, Panorama could abandon Apple’s document management system, and roll it’s own. Again, a veeeeery bad idea.
Please note that Panorama allows you to configure exactly what windows appear when a database opens. It’s very easy to set up, as explained on this help page:
Save Window Positions is not still a thing. The help page I mentioned just now explains how to control window positions.
We’re going to have to agree to disagree on this. The older versions of Panorama were full of all kinds of kinks and twists that many of you just got used to and forgot that they were not obvious for new users. Go back to Panorama 6 and try creating a new form – the first thing you had to do EVERY time was go thru a weird configuration dialog to set up the tools (and the tools were non-standard from every modern Mac program). Talking about data sheet scrolling, that was completely broken in previous versions of Panorama.
As for needing a coding wizard, I don’t see how that is any different from the previous version. If you want to automate your database, you need some code. Many many Panorama users then and now use the program with no coding at all. It’s true that those users don’t show up much here on the forum – they’re just quietly doing their work. But our usage stats show that they are out there, consistently getting work done month after month.
For what it’s worth, the current version of Panorama is 127 Mb, which is not a lot by modern standards. But the actual core machine code is only 4Mb. Most of the space in the current version is the help system and images.
Well, it certainly doesn’t work exactly like “classic” versions of Panorama. For 25 years these classic versions of Panorama were heavily criticized for not having a standard Mac interface. So for Panorama X, every effort was put in to make the user interface as standard as possible. I think this paid off, because in the past 5 years there have been more new users of Panorama than in the previous 25 years. It seems that new users of the program don’t think it starts at an “Advanced” level at all - it works how they expect it to.
Previous Panorama users seem to have more trouble because they have to unlearn some existing habits. That’s why I created videos to help with the transition. You can find these in the Help menu, on the www.provue.com web page, or using these links:
Converting from Panorama 6 - Converting from Panorama 6 on Vimeo
Panorama 6 to X: Basics - Panorama 6 to X Basics on Vimeo
Panorama 6 to X: Form Design - Panorama 6 to X Form Design on Vimeo
Panorama 6 to X: Programming - Panorama 6 to X Programming on Vimeo
For new users, there is a series of Quick Start videos, starting with an orientation video. For both new users and Panorama 6 users these videos are mentioned on the Getting Started with Panorama X help page, which is the very first link on the main Panorama help page, not buried at all. There is also a step-by-step tutorial which is the second link on the main help page.
You’re certainly not the first Panorama 6 user to be disappointed that Panorama X doesn’t party like it’s 1999. We’ll have to agree to disagree I think. In my opinion, the overall Panorama X experience is simpler and better for both new and experienced users. In any case, the number of Panorama 6 users started small and dwindling, so the ongoing focus is on expanding the base of new Panorama X users to a new generation. There’s plenty more to be done but my assessment is that Panorama X has been heading in the right direction. Of course, as Lincoln famously said, you can’t please everyone all the time, and I’m resigned to the fact that some users just don’t share my vision for the program. That’s fine, but FYI this forum is not the appropriate spot for discussion of alternate visions, or for an excess of negativity. I find the quotes I pulled out above are more than a bit disrespectful both to me and to the forum community in general. I’m hoping that’s not what you intended, but in the future please keep in mind that this is a small, friendly community. That said - welcome (back) to the community.
1 Like
It has been sent.
Very minor side issue: not sure when Apple made the change, but by mac OS 12.6 a changed document is no longer indicated by a black dot in the red close circle, but rather by “Edited” being appended to the window title. This new behavior is present in Panorama form windows, but I just now noticed this does not occur with the data sheet. I’m probably missing something obvious, but I couldn’t readily find any visual clue that a Panorama database has been changed from inspecting the data sheet. A curiosity.
Thanks for sending the file. I cannot duplicate this problem. I have no problem getting to the bottom of the database no matter how I do it – with the scroll bar, using the Last Record tool, or searching. Is there some particular steps you need to use to see this problem? Your description made it sound like it would be immediately obvious but it’s not.
I do not have a computer with 12.6. Perhaps there is a new Apple bug in that system. Panorama X’s code for displaying the data sheet has not changed in over 8 years, basically it has never changed since it was first written. Do you have any computers with older versions of macOS? If so, could you check to see if the problem also occurs on older versions?
On El Capitan it scrolls just fine. It continues to not scroll properly on Monterey. The scrolling works when the window is resized but if I close the file and reopen, it’s back to the failure to scroll to the last records. The Last Record tool also fails to go to the end.
And now that I wrote all of that, it works perfectly when I reopen it.
Pulling the copy from the email that I sent to you, the scrolling fails. 
Sounds like a Monterey bug. 
But other databases don’t have this problem, just this one? That’s really odd if true.
This is one of the few that I work with frequently that does not open to a form. If others are prone to it, I hadn’t seen it. Just now I found another file that is solely Datasheet. I made the window a bit smaller and saved. When I re-opened it I could not scroll to the last records.
Scrolling to the “bottom” displays just the top of another record but will not go further even though I’ve used the Down Arrow key to go to further:
Resizing the window allows me to access those remains records:
It sounds like you are saying that the problem occurs when first opening a database, but once you resize the window it works. Is that right?
Does it also happen if you open the data sheet from the View menu? Or only when first opening the database.
If you open a database, do a selection and then select all, does that fix the scrolling problem (without resizing the window)?
Select All changes nothing. With a form open, closing the Datasheet then opening it via the View menu changed nothing.
I set the file to open to the form, saved and closed it. It re-opened to the form as expected. Opening the Datasheet via View changed nothing; still no scrolling to the bottom.
Making an almost indiscernible adjustment to the window size makes it work.
If all records were already selected, for sure Select All will do nothing. Did you select a subset first and then Select All? Just want to make sure we are on the same page.
So then does it work from then on, as long as you keep it open?
Also, if you close the data sheet (leaving the form open) and then re-open the data sheet, does the problem reappear?
In limited testing, opening to a form, then opening the Datasheet with only some records selected, and using Select All, scrolling worked properly. I can think of all sorts of other ways to set the stage in order to test that.
Could you check to see whether hiding a field causes scrolling to start working properly?
Panorama has code that is run after any change in the number of visible records or visible fields. This code tells the scroll bar how far it can scroll.
Unfortunately, this exact same code is also being run when the window is first opened. I’ve double checked in the debugger that this is actually happening, and it is. I have no idea why Apple’s code would respond correctly in one situation but not in another.
When I hid some fields and kept the file open, scrolling went from not working to working. When I quit and reopened the file, scrolling was back to not working.
Could you try creating an .Initialize procedure for this database with this one line:
showpage
I think that might get it to work when opening the database. It would not help with opening it later with the View menu.
If that doesn’t work, try adding wait 0 above the showpage.
If it does work, it’s very puzzling, because Panorama is already performing the equivalent of showpage when it opens the window. So I could try adding another, doing it twice, but I’m very reluctant to do that without understanding what is going on.
I’m also puzzled that only two people have mentioned seeing this so far, and no one else has chimed in with this discussion. Seems like a problem that would get reported.