I have been doing a lot of work and making a lot of changes to an imported V6 procedure which didn’t work in PanX. I saved the open procedure window to cause it to re-open anytime the db is opened. That has worked fine for several weeks but now I don’t want it to open automatically any longer as a db window, but I can’t stop it from opening automatically anyhow.
I have closed it, re-booted Mac, re-saved, (all the usual stuff), but to no avail. Anybody know what to do to fix this?
Thanks
Close the window then make any other change to the database, for example just edit data cell and press return. Then save and the window won’t open any more.
Thanks Jim. I tried just saving many times and that did not work. Didn’t think to do a dummy edit.
On a closely related matter, how can a prevent opened forms, which had been previously saved along with a db, from reopening when I procedurely open a db with <opendatabase “xyz”>?
I am using an Init procedure where I want to open only the database followed by opening certain forms in specific window positions. Problem is I can’t prevent previously saved forms from opening on their own when I execute “opendatabase”.
You can use the OpenSecret command to open the database without windows.
Read its documentation carefully before using.
Thanks Dave. For me, the problem is keeping it open, despite windows being opned and closed mmanually, which is why I like to hide some open forms off-screen. That technique is not perfect either but it has worked well for me for many years and I am not at all anxious to spnd time figuring out what isn’t working for me with the hidden db:)
Panorama X 10.2 has a new option to keep a database open permanently once it’s open. With this option set, closing the last open window makes the database “secret” instead of removing it from memory. So once that release becomes available, that will make it super easy to make it work the way you want, without off-screen windows. The new release also allows you to specify associated databases that will automatically open when you open a “main” database.
It’s a show stopper for me right now. Are you willing to hazard a guess at how soon it might be or can you tell me what to do meanwhile as a patch. My system is suffering from “form window chaos” and I can’t manage the windows. It seems as though previously saved window positions are overriding windows which I have positioned through procedures and with 5 databases simultaneously interacting I am not exaggerating by calling it a mess. The system is pretty much useless!.
Thanks for any ideas.
Jack
When a database opens Panorama is always going to re-open the window positions from the last time the database was saved. Panorama 6 was the same, except that it didn’t re-open procedure windows. There is no way to use procedures to open windows to specific locations automatically when the database opens, and still would not be any way to do that in Panorama X 10.2.
Then I have lost my mind Jim because of I’ve been using the .Initialize Procedure in Pan 6 for years to set up windows exactly as I want them and no matter how many goofy things I do with them, and save, during a session, when I quit Panorama and re-start the screen always returns to my original setup.
Maybe we are talking about two different subjects. I can’t be sure. :):)
I’m afraid I’ve forgotten many of the details of Panorama 6 at this point. I just looked and in the Panorama 6 Save As dialog there is an option to “save database windows” that you can un-check. I thought at that point it would automatically show the data sheet, but maybe you are using that as a starting point for your procedure. There is also a “no windows” option, but I think in that case the .Initialize procedure doesn’t run. But as I say, the details are fuzzy, the last time I worked with the Panorama 6 source code was about eleven years ago.
Thanks, once again, for your candor Jim. What you have assumed about how I have achieved these results is exactly right. The option to not save window positions is in the General Preferences window of Pan6. Furthermore I have taken advantage of this ability to not save window positions in many of my 57 Pan6 db tools which I have designed over all of these years. I use many of these databases to store information which is very important to me.
Do you have any suggestions to offer me on how I can best proceed to retain what I have without having to do a complete philosophical and physical re-design? Is there some kind of work-around that might be feasible to brute force my way through this?
As always, a big thank you for your thoughtful support.
Jack
Well, I wouldn’t agree completely. I have seen some of my PanoramaX databases that opened in the correct position, but in a collapsed window state, in other words: toolbar only, window height zero. (No setting I would ever use actively.)
In affected databases I have added e.g. this code to the .Initialize procedure to resize the window:
local newWindowRect
newWindowRect=rectangleadjust( info("screenrectangle"),50,25,-70,-80)
zoomwindowrectangle newWindowRect, "noscroll"
I have seen a similar behavior (See my earlier reply). Sometime windows open one place, sometimes another place and sometimes not at all.
The most devastating result of always saving window positions is that if a window is temporarily moved or resized to uncover something it is obscuring, and then the content is edited or or somehow changed, saving the content also saves the unwanted window position. It doesn’t work for me.
I’m hoping that Jim is going to pull a rabbit out of a hat and come up with a way to not be forced to save window positions just like Panorama 6 did.
My window strategy is designed to ensure a specific window always opens and is displayed in the same position when a DB is opened. To do this, I close the DB with a button, not the red dot. The button procedure closes all the windows other than the window I want to stay open, then saves, then closes the database. When I open the database, the .Initialize procedure opens the desired window, returns it to its desired size, and places it top center.
I have two custom procedures to help with this, closeotherwindows, which will close every DB window in the same DB except the one that is foremost when the procedure is executed, and fixwindow, which ensure the window is scrolled correctly and sized to its default size. zoomalign “top” puts the window in the top center of the screen. Once these statements were defined, managing windows upon opening, which had been a nuisance, became simple.
The code for closeotherwindows is:
/*
<PROCEDUREINFO>
<description>
The CLOSEOTHERWINDOWS statement will close all the windows of the current database except the one that calls it.
</description>
<body>
Description
The statement gets of list of all the open windows and removes the current window from the list. The procedure then loops through that list and closes each of those windows if the database is the same as the calling window, which leaves only
the window calling the procedure open.
Note that this statement relies upon another custom statement: closeanywindow, which will close a window which is actually non-closeable, which it does by deleting the form and immediately re-creating it.
</body>
<errors>
</errors>
<author>Jim Rea provided the essential part of this procedure.</author>
</PROCEDUREINFO>
*/
/* Define the variables that are needed. */
// current window is always listed first by info("windows"), so skip it
let otherwindows = arrayrange(info("windownumbers"),2,-1,cr())
console otherwindows
looparray otherwindows,cr(),otherwindow
// is this window in the same database as original window?
if windowinfo(val(otherwindow),"database")=info("databasename")
// bring window forward, then close it
window val(otherwindow)
closeanywindow
endif
endloop
The code for closeanywindow is:
/*
<PROCEDUREINFO>
<description>This statement closes a window even if the close button has been disabled or if the window is a clone window. </description>
<body>
Closeanywindw tries to close the window with a closewindow statement. If that does not work it tries to close with a closeclonewindow statmeent. If that does not work, it just closes a window by saving the window into a variable, deleting the form with a setformoption statement, then importing it from the variable. This effectively closes the window.
</body>
<errors></errors>
<seealso>closewindow</seealso>
<history><revision version=1</revision></history>
<author>Tom Cooper with major help from Gary Yonaites</author>
</PROCEDUREINFO>
*/
if info("clonewindow")
closeclonewindow
rtn
elseif info("windowtype")=5 or info("windowtype")=2
closewindow
rtn
else
try
closedialog
catch
nsnotify "Sorry, I can't close that window for some reason."
endcatch
endif
rtn
The code for fixwindow is;
/*
<PROCEDUREINFO>
<description>
The FixWindow statement resizes the current window to the size of its maximum height and maximum width as set in the window properties and removes the toolbar and turns off the scroll bars. It retrieves that information with the form blueprint statement, which retrieves all of the settings for the current window, then extracts the maximum height and width with a tagdata statement.
</description>
<tags>windows,adjusting</tags>
<body>
The statement is self-documenting.
</body>
<errors>
<error message="The max height or max width for this window have not been set.">
Set the max width and height.
<error message="GCDLCM statement: The input set includes a negative number.">
Negative numbers are not permitted as input.
</errors>
<history>
<revision version="1.0" status="No Change">New in this version</revision>
</history>
<author>Tom Cooper</author>
</PROCEDUREINFO>
*/
formxy 0,0
setwindowoptions "Toolbar",false()
if getformoption("","","MAXIMUMHEIGHT")=0 or getformoption("","","MAXIMUMWIDTH")=0
beep
alertsheet "Max Height and/or Max Width are not set for this form."+cr()+cr()+"Form name: "+info("Formname")
return
endif
zoomwindow
getformoption("","","WINDOWTOPEDGE"),
getformoption("","","WINDOWLEFTEDGE"),
getformoption("","","MAXIMUMHEIGHT")+24,
getformoption("","","MAXIMUMWIDTH"), "notoolbars noscroll"Thank you very much Tom for taking the time to explain this and to include your code.
In my toughest Pan6 conversion I am trying to control 5 simultaneously open db’s; each as you have done. They are dynamically interactive and must remain open.
I had built these tools to use in my retirement never thinking that I would have to re-do 30 years of Panorama db systems development instead of “fishing” You can imagine that I am trying to keep the 6 to X move as simple as possible but so far it has been anything but that. I have many instances of using Pan 6 View-As-List forms which multiplies the difficulty.
I am therefore very appreciative of ideas such as yours. I never expected to have to go to such lengths for an upgrade and keep thinking that maybe I just don’t get it. Anyway,
thanks again,
Jack
I also found that converting from Pan6 to PanX took a long time, more than I had expected. But I took the original PanX class with Jim and learned far more about PanX than I ever knew about Pan6. And PanX is far more polished now that it was then, so I had to create a lot of workarounds. However, I found some much better ways to do things. But the Pan6 forms I had now look terrible to me, so I re-did all of them and improved many things from the earlier databases.
One photographer used to say on his podcast that restricting your options will frequently force you to get more creative; so, for example, go out with one lens only. It was the same thing with PanX at that time. Like giving up View-As-List forms.
I would be glad to help you with any of your databases if you like.
Thanks for your comments and your support Tom. I am very grateful to you for your help.
This issue has been going on for a while Tom. I have been using Panorama since the days of Overvue, it’s predecessor, Jim and I have become good friends over that time and he, also, has been, and remains, very helpful and supportive.
My problem is that over those 30 years I have developed 57 Panorama “tools” for myself and my family most of which contain loads of personal info which I depend upon. Most of them use “View As List” forms, window positions which cannot be saved by a “save” command, various commands which have been deprecated, etc. It looks to me like a massive job to convert all of this over to “X” and it had never occurred to me that I might be confronted with it.
The tools which I have developed all work great in Pan 6 and suit me well because I spent years evolving them. Therefore I am looking at all options ranging from running Pan 6 on a legacy OS emulator forever, a generic worksheet, (which retains data but loses all functionality), a competing database manager, (with a steep learning curve), or whatever. My only inviolate rule is the data must be preserved and accessible.
I have just spent most of 2 full weeks working on a 6 to X conversion of just one db system and have made little progress. My wife is becoming very critical of the ROI and she may be correct. (Didn’t mean to write a book here but want to show you the reason for some of my apparent caution on proceeding.)
Thanks again Tom - more later. I’m going to experiment with some of your procedures.
Jack
If I wanted to open a set of databases with programmed windows and locations that weren’t affected by the window configuration when the databases were saved, I would create an additional database, perhaps called “Launch”. In this database I would have one form, and one procedure, .Initialize, with code something like this:
if info("databasename") <> "Launch" return endif // if we later want to edit this code, rename the database and launch it
opensecret "Database 1"
opensecret "Database 2"
opensecret "Database 3"
setactivedatabase "Launch" // not sure if this is needed
closefile // get rid of Launch database
openform "Main Form","Database","Database 1","Rectangle",rectanglesize(20,20,250,600)
openform "Another Form","Database","Database 2","Rectangle",rectanglesize(400,20,300,300)
openform "Another Form","Database","Database 3","Rectangle",rectanglesize(400,350,300,300)
When you open this launch database, it will automatically load the other three databases with windows in specific locations. I’ve shown only one form per database but there’s no reason you couldn’t open more than one per database. You could also open off screen forms, and you can specify whether each window has toolbars, scroll bars, etc.
I agree with her. You say that these “tools” are for your personal use, yet it sounds like you are engineering them for distribution to a mass audience. For example, worrying about closing windows. Since you are the only one using the databases – just don’t close a window! If you do, then just re-open the database, not the end of the world.
If a system is going to have a lot of users then you have to worry about polishing all the details, training materials, etc., it can be worth it to invest a lot in making a perfect system. But if it’s just you, it’s probably not worth it to go to all that effort. (Note that Tom Cooper is developing a system for heavy daily use by over a dozen other users, so it’s worth a lot of effort to round off as many rough edges as possible.)
This is not going to happen. This was a feature that was triggered accidentally more often than it was used intentionally, so it was mostly a source of confusion and tech support, i.e. “why aren’t my windows saving??? this program is broken!!!”
In fact, it was used so rarely that in the six years since Panorama X became available as a beta, and 4 years since it was officially released, I think you are the first person to ask about it. I’m not going to intentionally spend limited resources to add a feature that is proven to cause confusion and tech support costs for the benefit of a single customer (or at most, a handful).
over those 30 years
it had never occurred to me that I might be confronted
As far as I know, there is no tool you could have used to build a complex database application in the early 1990’s that you could still use unmodified on modern hardware in 2021. Most tools available in those days are long gone now. The few that have remained actively developed have all had massive changes that have required significant rework on the part of customers.
Panorama was rather unusual in that I prioritized absolute compatibility with previous versions for 25 years. From Panorama 1 to 6 there was complete compatibility so that almost no coding or form changes were ever required. In retrospect, I think that was a mistake – it held Panorama back and by the end of that period it was an archaic program that potential new users shunned.
1 Like
Thanks a lot for your comments and code help Jim.
Your suggestion on how to initialize my multi-db system is exactly what I have had working in Pan 6 for many years, with different code of course. When I imported it to Pan X, it was a complete disaster for me. It, literally, was just a horrible mess when I tried to run the import. Windows all over the place, procedures which wouldn’t run, and lots of lost form graphics. I’m sure it is all fixable but the amount of time to make the repairs is still questionable.
Quick question which I have about secret files is; Can I Procedurally open forms in a secret file without having to perform an “opensecret” or “activate” first?
The answer to the ROI matter is one upon which we all agree. However a small handful of my databases do have as many as 6 users and I want them to be solid. To make matters worse, I was brought up in the school of “If it’s worth doing, it’s worth doing right”.
My objective right now Jim is to develop a process which I can repeatedly use for all of my Pan 6 databases. If I can’t figure that out, then I don’t know what I am going to do.
You and Tom have given me some great tips/code which I hope will put me over top.
• I am undecided on how to deal with the View As List problem.
• How to best solve the saving/not saving/using of window positions along with content changes is very unclear to me. How I understand it should work and how it seems to work are different. e.g. Forms don’t open consistently in the same window position.
You’ve given me a lot to think about.
Thanks again Jim,
Jack