Can't run a procedure if all open form windows are in graphics mode (was "Openplain" glitch?)

I have been using an openplain procedure from one of my files to open another one so that it doesn’t execute the new file’s .Initialize procedure. It usually works, but sometimes (today, in fact) I get this message when I click on Run:

Cannot run because there is no open data window for this database

I’m looking at the open data window (form) for the database that contains the procedure with “openplain” in it while I see this error. I get this error occasionally, sometimes actually with no data window open, but that’s not the case this time. Not sure why this command requires an open data window in the first place.

What is this telling me, and what can I do to get past it?

Here is the source for the openplain statement.

Local filename,filefolder,filetype
OpenFileDialog filefolder,filename,filetype,"ZEPD"
If filename="" stop endif
OpenSecret folderpath(filefolder)+filename
if filename endswith ".pan"
elseif filename endswith ".pandb"

Window filename+":secret"

To me, it seems odd that you would use this statement. Do you really want to have to select the file every time? And are you checking that the correct file is actually selected? I’ll bet that you accidentally selected the wrong file, and that is why the error is coming up.

If you are opening the same file all the time, code something like this would be better:

opensecret myfilename
setactivedatabase myfilename

By the way,

setactivedatabase file

is the same as

window file+":secret"

Just a little “cleaner”, I think.

I do this on the advice of Gary or David (can’t remember which) when I needed to open a file whose .Initialize procedure got me into all sorts of trouble for various compatibility reasons. I use it because it’s simple; I have just used the new features of Find & Open to accomplish this and that works fine. I should point out that the error I am seeing is at the bottom of the procedure window that contains the openplain command, it’s not an error dialog. And it never executes the OpenFIleDialog command, it doesn’t get that far - it refuses to run the command at all. When it doesn’t stop at this error, it works fine for what I need.

I use this method because I need the file open so that lookup( functions in other files have something to look up while I am working with them. I would never use it for production work.

ps. the new graphics mode handles are right on!

So the problem has nothing to do with openplain. It sounds like you need to tell us more about the rest of the procedure.

It is a procedure with one word in it: openplain. A utility procedure for use while I am developing. Clicking Run gets me that response - occasionally. And in this case it seems to be reacting to a situation that does not exist.

Got it. That message means what it says. There must be at least one data window open in a database to run any procedure. You probably have only a form window open, and if that form window is in Graphics mode, that is exactly the error message you will get. That happens to me from time to time. You just have to flip the form in to Data mode and you’ll be fine. Panorama 6 worked the same way.

Since this actually has nothing to do with the openplain statement, I’m going to change the name of this thread.

You nailed it. All the times it wouldn’t work were when I was in Graphics mode, apparently. Went right by me. Aren’t you glad you don’t have to add another problem to your list?

I realize I never encountered this before because in Pan 6 graphics mode looked very different from data mode; in X you have to look carefully at only a couple of places to see which mode you’re in. Which brings up my concern with the new style. I saw a post a few weeks ago about the Properties pane, with the wish for it to extend out to the right when activated instead of left, where it obscures what you’re working on, and the entire window has to be resized in order to use both. Then back in data mode the window stays unnaturally large. Very inconvenient; if this is just an interim situation until you get time to work on it I can be patient. Also, the huge top header takes up a lot of real estate, while these controls in 6 are very compact and unobtrusive. My application has several windows open at the same time, carefully layered over each other and sharing the screen with others; I can’t afford for my windows to take up a lot more room than before.

If you right click on the toolbar you can choose from several options: Icon and Text, Icon Only, Text Only or Hide Toolbar. The default is Icon and Text which takes up the most real estate, then the Icon Only followed by the Text Only. Of course the Hide Toolbar is the least option but removes all access to the tools via the toolbar. These settings are separate for Data mode and Graphics mode and are retained until you change them. There is also a setting for Use Small Size which will reduce the toolbar even slightly smaller.

Well, in Panorama 6 the graphics mode rulers were yellow, which kind of stands out (in Panorama X, these rulers are drawn by Apple’s code, so changing the color would be tricky, though perhaps not impossible). But other than that there was just a slight change in the tool configuration between modes. I think in Panorama X there actually is quite a bit more difference between data and graphics mode – you’ve got the entire inspector palette that appears. Either way, I occasionally run into the “Cannot run because there is no open data window for this database” error with both Panorama 6 and Panorama X. (In fact I used to run into it in Panorama 6 more, because it was easier to have a database open with just one procedure window and nothing else.) Maybe Panorama should offer to switch the form window into data mode for you, assuming a form window is open.

wish for it to extend out to the right when activated instead of left

That used to be a common thing in a lot of OS X applications – I think it was called a “drawer”. I’d paste in a screen shot but I can’t think of any application that still uses them. Apple now discourages that feature. Oh wait, I thought of one, a freeware app called Appkido. Any app that uses a drawer like this will be instantly recognizable as probably abandonware, which Appkido in fact is (it hasn’t been updated in about 6 or 7 years). Here’s what the drawer looked like – extending out just like you are suggesting.

No one uses drawers any more. However, lots of modern programs use an inspector panel on the right just like the one that Panorama X uses. Here are six modern examples that I was able to find on my system in about 2 minutes – I’ve drawn an arrow to the inspector in each of these programs. All of these programs have been updated within the last year.

So I wanted a modern design that would already be immediately familiar to a lot of Mac users (and especially reviewers!), and I think Panorama X pulls that off quite well. @staylor246, you are correct that this doesn’t work very well with small windows, but we’re not using Mac Plus’s with 384 by 512 screens any more. If you need to cram a lot into a small space, I suggest looking into the new Panorama X tab panel feature.

the huge top header takes up a lot of real estate, while these controls in 6 are very compact and unobtrusive

I really liked the toolbar down the left in Panorama 1 thru 6. As you say, very compact and unobtrusive. I thought it was a great solution, and I figured other software would probably steal the idea. Wrong! Reveiwers universally slammed Panorama’s tools as “weird” and “non-standard” – especially after OS X came out with a standard system toolbar. So while I’m not a huge fan of the standard Apple toolbar, as you say, it takes up a lot of real estate, it is the standard, and what most users expect on a modern Mac application.

This is very surreal – for decades Panorama has been slammed for it’s non-standard interface. So Panorama X was designed to use standard Apple user interface conventions from A to Z, and now there’s a clamor for the old non-standard interface back!! Can’t win. Anyway, I’ve made a serious bet that going with a standard user interface is going to be a winner in the long run, and I’ve got my fingers and toes crossed. Rest assured, though, that all of the user interface changes in Panorama X were very carefully considered and planned out – this isn’t something that was just slapped together as I went along.

First off let me say that I can live with things the way they are without any problem and really love 99% of the GUI in the new version. But if I could change a few things to the way I would like them in my imaginary world - well, here goes.

  1. I too would like to see the form expand to the right to accommodate the added properties panel (260 pixels?) when going into graphics mode.

  2. Please do not expand the form to full screen size when the form is too small and opening into graphics mode! This is a pain in the rear and could be avoided if #1 above was standard.

  3. Wouldn’t it be cool if we could fully customize the form’s tool bar in data mode with our own icons and text? I know I can hide the current toolbar and fake my own but there is always a noticeable line between the custom toolbar and the title bar. See screen shot of one of my custom toolbars:

Note:This window has added the “— Edited” which I believe the system is adding to the window name. Any way to prevent or change this? Using windowname does not eliminate the added “— Edited” extension and I’m not sure why it is being added in the first place. I see that the Pan Help file uses this area to show the current Help page item name.

  1. lastly, often when editing smaller forms in graphics mode the form auto scrolls to the left and you have to then reposition it back again. If you don’t notice and correct this before going back to data mode in a form with no scroll bars you have to travel back into graphics mode and reset them again. Very minor annoyance but worth mentioning.

These are all minor points indeed but things I run into when working in Pan X every day. By and large I think Jim has done a stellar job in keeping things to the Apple standard and still allowing for our own customizations.

Thank you both, Jim and Gary, for all the details. I have to agree that doing things the Apple way pays off, for now and the future, so I guess some of my arguments should be directed at Apple! Funny, I have never used any of the apps that Jim uses as examples of inspection panes the Apple way, never seen anything using it that way, so it doesn’t have a lot of persuasive power. But Gary’s points are right on. Especially (I was already thinking about this) the customizable toolbar idea, which is in fact a feature Apple uses in Finder windows. Depending on how customizable it might be, it could be used for a lot of useful things in addition to basic navigation. If the icons for the built-in navigation buttons were customizable I’d be even happier. Gary’s last point is something that has caught my attention as well, but I figured it would take some fine tuning that would have to wait until the major issues were worked out.

Looks like the title of this topic might need to morph again…

I guess it’s a good thing I went to the trouble of making the screen shots! I thought maybe I was overdoing it.

I understand the problem, run into it all the time myself, but I don’t think this is the solution for a variety of reasons.

Please do not expand the form to full screen size when the form is too small and opening into graphics mode! This is a pain in the rear and could be avoided if #1 above was standard.

I don’t see how this could be avoided if #1 was implemented. Maybe for some edge cases, but especially if the window is short, just making it wider isn’t going to solve the problem.

I’ve seen a lot of applications that just don’t allow a window smaller than a certain size. For example in Keynote the minimum size is 440 high by 534 wide. It just won’t let you make a window smaller than that. For Pages the minimum is 400 high by 768 wide. I’m sure that’s because they just didn’t want to deal with these types of problems. If Panorama was a completely new application I would probably have imposed a similar restriction. I’m not going to do that, but at this point I’m not planning to expend any extra effort in making super small windows easy to work with, either.

Wouldn’t it be cool if we could fully customize the form’s tool bar in data mode with our own icons and text?

Of course, that would be super cool. Maybe look for that in Panorama X 10.5. It would require completely junking Apple’s NSToolbar code and writing a complete replacement, which I am loath to do.

Speaking of cool things, right now you can customize the toolbar but only on a program wide basis. You can’t have different toolbars for different forms, even just picking from the the existing tools. Again, this is a restriction that Apple has baked in. Apple’s code just isn’t designed for that type of customization, unfortunately. The customization is tied to the class of window, not to individual window instances.

Using windowname does not eliminate the added “— Edited” extension and I’m not sure why it is being added in the first place

Apple’s code adds this to indicate that the document is modified. It will go away when you save, or when auto-save happens. It will come back as soon as any undo-able operation is performed. You’ll see this on any standard document based application.

Pan Help file uses this area to show the current Help page item name

The Pan Help file doesn’t show Edited because the code never does an operation that modifies the database. When I’m doing maintenance on this database, Edited does show up.

often when editing smaller forms in graphics mode the form auto scrolls to the left and you have to then reposition it back again

Yep, I see that occasionally and it is annoying. I actually made an attempt to fix that some time ago and it seemed to reduce but not eliminate the problem. A lot of the debug work on Panorama X involves trying to figure out how to stop Apple’s code from doing something I don’t want it to do! It’s often amazingly difficult to figure this out.

You can always write a one line procedure to reset the position:

formxy 0,0

I would be more than happy if the too small window simply expanded to the “minimum” size needed for the properties panel when transitioning to graphics mode…just not to the full screen size.

Cocoa has a “zoom” function for toggling between the current size and full zoom. There is no such function for toggling between the current size and some intermediate size. Of course I could come up with some custom, non-standard solution…

Those two options seem to make sense for zooming a window in data mode but seem rather limited when actually changing the window structure itself as when you go from data mode to graphics mode. Not a huge problem but I do have a tendency to drop an expletive or two each time it happens because I have my Dock set to automatic hide/show. That means the zoom goes all the way to the very bottom of my screen and if I’m not fast enough when I go to reset the size the dock opens on top of it and I’m fighting with that to resize it.


Not wanting to tell others the way to work but as I’ve found most monitors are wider than tall, I’ve most often found that there is ample width but rarely enough height. Thus I choose to put my Dock on the side as there is always room on the side but often not on the bottom. Just a thought.

Robert Ameeti

I’ve considered that option but since I have dual monitors I wanted the dock available on both of them. With the dock on the side it is only available on either the left or right monitor depending upon the setting. On the bottom if I don’t have it set for auto hide/show it will only show on the last monitor that activated it and on the other monitor it will appear when I travel to the bottom of that screen and disappear on the other monitor. I think I’ll just leave it on the bottom with the auto hide/show option on. Thanks for the suggestion.