This is impossible, isn’t it?

Panorama X
23

If someone wants to point on an actual difference, I would be happy to address that. It’s certainly possible there is some specific bug. But there definitely is not a “fundamental” difference in how they work between the versions. It works the same.

It seems likely to me that you have been using this technique for something it was not actually designed to do. They were designed for one job – to temporarily switch to a different database and either grab some data or make a data change. It should be in and out quickly, just a few lines of code. If you’re doing something else super complicated, that’s not what it’s for.

There is one difference that I know of – in Panorama X using a message statement or any kind of alert stops “secret” window operation and makes the visible window current. So if you have code like this:

window "database 2:SECRET"
...
.... do secret stuff
...
message "hello"
...
... do more secret stuff here
...
window "original database"

In Panorama X this won’t work, the second batch of secret stuff won’t happen in the secret window, it will happen in the frontmost window. I’m tired tonight though, so I’m going to file this under “it’s almost always bad programming to put an alert or dialog in the middle of program logic”. Don’t do that. But if you really must, do it like this:

window "database 2:SECRET"
...
.... do secret stuff
...
window "original database"
message "hello"
window "database 2:SECRET"
...
... do more secret stuff here
...
window "original database"

But in almost every situation, a much better idea would be to move the alert to either the top or bottom of the code.

24

Unless, of course, the only reason for the message window is to check what data, if any, was extracted from the secret window. Single-step no longer works in PanX (at least it didn’t the last time I tried it some time back), so to trouble-shoot a complicated macro, one can only know what data was obtained by using a message statement. In fact, in many cases the secret window that was opened is determined by the macro itself, so one needs to check on which DB was opened secretly. A message window with info(“databasename”) doesn’t help.

Your second example looks like it might be a good way to do that. Was that covered in the Help notes?

Vic

25

With Panorama X, you also have the nsnotify statement.

That doesn’t open a window, so your secret window is left undisturbed.

26

More options would be to save the extracted data to disk via filesave. Or to save it to a local variable and display that via message, etc. later in the procedure, after the secret window was out of the way.

27

I learned the hard way that the message statement doesn’t work well for debugging, so I’ve been using the console statement which logs the necessary info in the Console application so I can see and track what’s happening. I scatter console statements liberally throughout the procedure in question and they don’t litter my screen like the nsnotify statements would.

28

Still and all, Jim, can’t you come up with a better way? With your skill at coding, would it be impossible to have secret windows work the same way they work in Pan6?

29

First of all, let’s clarify, by “work the same way” you mean “in every possible way, including non-documented behavior that was accidental based on details of how Apple’s operating system worked”. Because let’s be clear, that’s what we are talking about here. It just so happens that in earlier versions of the Macintosh operating system, opening and closing an alert doesn’t send a window activation event to the application. The old OS didn’t consider alerts to be windows. When using the newer Cocoa operating system, it does treat alerts as windows, and it does send the window activation event. Panorama responds to a window activation event by making the frontmost window active. If a secret window was active, it isn’t any more. The fact that a message alert didn’t terminate any active secret window in Panorama 6 was not something that was done on purpose. In fact, I wasn’t even aware of it until recently. Putting a message alert in secret window code is something that I would personally NEVER EVER do. So I would never discover this behavior. Apparently not to many other people do this either, since it wasn’t reported for several years after Panorama X became available.

Now that it has been reported, is it possible that a change could be made so that a secret window won’t terminate when an alert is displayed? Most likely, yes, it could. But it is not a trivial one line change. The operating system works differently now, so some engineering time would be needed to figure out how to work around that. It’s always tricky to work against the way the operating system wants to work rather than “going with the flow.” It can be difficult to get right, without introducing new bugs.

Will this change be made? Maybe, but I certainly won’t promise. This is not a documented feature of Panorama 6, it’s just something that a few people happened to try and it happened to work. I’ve added this to the issue tracker system, but I consider it a low priority item. I’ve said this before and I’m sure I’ll have to say it again, but I cannot guarantee that every tiny behavior of Panorama 6 will work exactly the same in Panorama X. As tiny anomalies are discovered each one will be evaluated for possible remediation, but most of the issues that affect a lot of users have already been resolved. Each issue is evaluated based on how many users it affects, how difficult it is for users to workaround the issue, and how difficult the fix is. I’m not going to spend a week on a fix that only affects a handful of users. That would be a disservice to all of the other Panorama users out there.

While some degree of technical skill is necessary for programming, I think it is not the top prerequisite for pulling off a huge project like Panorama X. More important is the ability to keep everything somewhat organized and prioritized with thousands of balls in the air. There are only so many hours in the day, only so much resources that can be thrown at a project. It’s not possible to find and fix every bug. It’s not possible make every tiny behavior of Panorama X exactly match Panorama 6. Now if you look at one specific little issue, like this one, and say “can this be changed?”, then yeah, sure, most likely. But that’s not the question. The question is “which issue gets worked on first, which second, and how far can we get before we run out of resources?” And the second questions is “who decides?” The answer to that question is me. It’s a constant juggling act to decide where the resources should be applied. I can’t please everyone. When I make decisions that please people, I generally never hear about it. But when a decision doesn’t match what other people’s priorities are, I often hear all about that. Fair enough, that’s just the way the world works, and it’s what I signed up for. I wish I could make everyone happy all the time, but I can’t.

So, the short answer is, yes, usually I can come up with a better way for one specific issue. But I think that’s the wrong question. To the question of “can I come up with a better way to solve every issue?”, I don’t know how to do that.

Also, remember that “issues” isn’t just small items like this, it is also big items like “I want to share my databases with my team” (i.e. Panorama Server), or “I would really like to run Panorama on my iPad.” These long term projects compete for resources with small issues. Someone who is a project manager doesn’t have the luxury of making decisions about individual issues as isolated pieces. Each individual issue must be examined in the context of the project as a whole.

30

Catching up on some posts here … One thing Jim touched on in his reply - that I think deserves more words - is APPLE changed the way they do things. I believe one of the top goals with PanX was to reconcile all the “non-Apple way of doing things” so that the next change from Apple won’t required a lot of new programming (which can introduce new problems).

It means, if Apple want’s an Alert to trigger a window activation event, I’d consider that “just life” and find a way that works that doesn’t contradict that “natural” action.

At some point, reliability and predictability are - especially in a commercial environment - more valuable than new features.