I have an application in which I script almost everything from navigation to searching and sorting to record creation, and I have found that a huge scripting problem arises due to the windowing features of FM7. Many of my scripts are used in combination to achieve my ends, and I have found it difficult to keep track of which window is currently active and which layout is displayed in that window.

This gets particularly problematic when creating or deleting records in a script; if the window gets changed for reasons I haven't accounted for, the action will take place on the wrong table. OUCH!

One way I had been working around this was to have each script establish its own context (usually by opening a new window), but this resulted in a lot of flashy screens.

I am now considering implementing a practice of checking the current layout before doing any of these steps. Before I begin the arduous process of locating all the places I add or delete records and installing the tests, I am wondering whether anyone else has worked out a nifty solution to the problem.

TIA,

David

The ability to have multiple windows is both a blessing and a curse. I ran into this very quickly.

For me, I set up to have one window for only one layout. In other words, each window only had the ability to "view" only one layout at any time. I named each window title according to the layout it's going to display. This adds more windows than may be desired, but at least I know what is what.

I also use a generic script to open new windows and go to the specified layout. It needs to have a parameter passed from the calling script. The parameter is the name of the layout desired. It checks to see if the window is aready opened by PatternCount ( WindowNames; Get (ScriptParameter) ). If so, goto that window. If not, open a new window and Go to Layout [Get (Scriptparameter)].

Thanks for the tip on checking whether a window's already open; I'll look into how I might apply that. I have a similar generic Set Window script, but it doesn't check for whether the window is already open.

I've actually taken to naming my windows for the script that opens them, when the window is opened for that script's needs. That way I have a clue when I'm debugging what it's there for.

David

I just posted a sample file that demonstrated what I previously described. You might be able to use some of the ideas behind it. Check out Post # 186360.