I want to have a new window open up to a specific layout (easy to do) and I want the new window to be static. I don't want the user to be able to change the record that they are in or the window size. They do however need to be able to change the field values in said record. I can hinder record navigation by hiding the status area, but navigation is still possible using keyboard commands.

If you hide the status area AND lock it, navigation is disabled. This also takes care of the onerous Windows mouse scroll wheel problem. And/or, you could GTRR to the single desired record when you open the new window.

Locking the window size is unfortunately not possible. You can lock down the close and zoom boxes with a plugin such as SecureFM, however.

"Lock" window? How does one do that? I found the "freeze" but that only works when the script is running. Should I open the window, go to the record that I want, freeze the window, and then pause the script? But then, if the window is frozen, isn't data entry impossible?

Merlyn:

You can select "lock" in your Hide Status Area script step. Freezing the window is a way to hide other script steps (layout changes, etc) from the user while a script runs; you can still enter data as normal, so it's not really necessary in this case.

-Stanley

There is no way to stop users from resizing windows, at least no native way.

I try to design so that if the user does change window size nothing gets broken. Maybe they have good reason to resize the window. It is their computer after all. Let them move windows around to suit their needs.

It is their computer after all.

What a quaint notion! THEY are allowed to use it only if they behave.

Seriously, I find the main reason for locking things is to avoid users' accidentally changing things and then having difficulty getting back.

Two completely different points of view.

One believes that the user own their machine, and should be able to move things around if they want, and the other believes that users will mess up their design, and get lost if they are allowed to do this.

To which group do you design for?

I think you misread me, Lee. I do not believe many developers belong in your second group. If users can get into trouble then the design is crook; hence the need to lock some things so users cannot get into trouble.

Sorry if I misread your response, it wouldn't be the first time I've done that.

Lee