In one of my Pan X systems I am at a complete loss as to how to know where my next form window will go or what size it will be. I have a db whose forms can be opened in any of 3-4 different ways. i.e. The View menu; a button in Form A, an .initialize script; or a button in Form B Each method puts the window in a different location and different size for no obvious reason. A behavior which I sure don’t want! I have no idea how to prevent this. (The “setwindowrectangle” statement seems to work sometimes and not other times - almost randomly.) After 2 days of trying to control it I give up which is catastrophic for my future Pan X efforts.
The View menu will open the form to whatever it’s last position was.
Can’t tell you what your scripts and buttons do, that’s up to your code.
As it says in the documentation, the setwindowrectangle statement controls the position of the next window to be opened. So usually you would immediately follow this statement with openform, opensheet or openprocedure, something like this:
setwindowrectangle rectanglesize(200,300,400,600) openform "My Form"
But if I was working on this code, I would rip the setwindowrectangle statement out, since in Panorama X the rectangle can now be specified as a parameter to the openform statement.
openform "My Form","rectangle", rectanglesize(200,300,400,600)
Isn’t that a lot simpler and nicer?
Can rectanglesize resolve variables or must the dimensions be hard data?
Please refresh my memory: I seem to recall that Permanent Variables in Pan6 were attached to the Panorama application and not db specific. A Permanent Variable would work with any db which happened to be open in Pan6??!!??
You can use any expression you want, and any expression can contain a variable (or simply be a variable). You could also store the rectangle in advance in a variable, then use that later, for example:
let myFormDimensions = rectanglesize(…
openform “My Form”,“rectangle”,myFormDimensions
You can do the same thing with setwindowrectangle.
- Your memory is incorrect. Permanent variables have always been associated with a database, not with the application. In fact, a permanent variable is just a fileglobal variable, but one that is saved when the database is saved, then reloaded into memory when the database is opened. You can only access a permanent variable when the database it is associated with is active. (Actually in Panorama X that assertion is no longer true, you can access a permanent variable in any open database by using the fileglobalvalue( function. There is no way to access permanent variables that belong to a database that is not currently open.)
In Panorama 6 there was no way to permanently store values not associated with a database, other than writing them to a file. Panorama X, however, allows you to write and read preferences using the Apple preference system, which is completely independent of any database.
When I run an.Initialize procedure which opens a form, I get the message "Cannot run because there is no open data window for this database. A data window is what I am trying to open.??!!?? What is a data window?
A data sheet or a form window in data mode.
You left out an important detail – clearly you are trying to test the .Initialize procedure by clicking on the Run tool in the toolbar, and don’t have any other windows open in the database. I know this because that is the only way that error message can be generated. You can’t use the Run tool if there are no other windows open for that database.
I’m suspecting that you want to open a database with no windows and then use .Initialize to open a window in a specific spot. I’m sorry, but this is impossible in Panorama X, at least using a single database. In another thread I mentioned that you could do this by using an extra database which could contain the code to open one or more other databases secretly, then open one or more forms. At some point it could close it’s own window (in fact it could do that first).
When a database is opened by double clicking on it, it will always re-open whatever windows were opened the last time it was saved. There’s no way around that.
I’m finding trouble shooting to be really tough/cumbersome in Pan X. No really good general approach to i that I can find. Don’t react I’m just blowing off steam.
You have a very nice surprise to look forward to in Panorama X 10.2. At least I hope you find it a nice surprise, it’s revolutionized trouble shooting for me, and for some beta testers.
That’s fine Jim but I need to get this stuff finished and get back to my life. For all I know 10.2 could be a very long time away, meanwhile I have lost my db functionality. Therefore I’m doing whatever I can figure out now. It’s causing me to think that I made a bad decision going to X because, as feared, it is taking major re-designs of stuff that has worked flawlessly in Pan 6 for years. I’m not attacking you good friend. I understand the situation and it is my problem it’s just that the enormity of the conversion process is very frustrating to me and consuming far too much time.
Enough dumping - I’ll try to shut up
You may know this already, but if not, one thing you can do to troubleshoot a procedure is to embed console statements. If you want to check what is the active database or check the value of a variable, varname for example, you would insert these statements
console "the active database is "+info("databasename") console "varname's value here is "+varname
Then have console running when you run this procedure and it will display the information you want. When running the console, it displays tons of information unless you filter the output, which you can do for PanX by setting the Library function to PanoramaX.
Thanks to Robert McGarey for teaching me this trick.
Thank you very much Cooper. Sound as if it could be quite useful. I will try it as soon as I can make time.