Does anyone know how to detect the Layout mode in script?
The funny is when you try to use the function Get(WindowMode)
FileMaker goes to Browse mode and this function returns Browse mode
state.

To run a script succesfully the file switches from layout to browse mode, so
FMP goes to there even when there are no active steps in the script itself.
You would have found this if you had consulted the help-file.

Perhaps you can clarify what you want to do?

Keep well, Ursus

"DataApex" <hruby (AT) dataapex (DOT) com> schreef in bericht
news:1170161076.929000.100980 (AT) v33g2000cwv (DOT) googlegroups.com...

In article <1170161076.929000.100980 (AT) v33g2000cwv (DOT) googlegroups.com>,
"DataApex" <hruby (AT) dataapex (DOT) com> wrote:

It's not the Get(WindowMode) command. You simply can't run scripts in
Layout mode. Obviously buttons won't work in Layout mode, but as soon
as you run a script via the keyboard shortcut or menu FileMaker
switches back to Browse mode - even a simple script that simply has
just the Beep command.

I can't think of any real reason you would want to. There's not even
any script commands for manipulating layouts or layout objects.

Helpful Harry
Hopefully helping harassed humans happily handle handiwork hardships ;o)

On Jan 31, 1:36 am, Helpful Harry <helpful_ha... (AT) nom (DOT) de.plume.com>
wrote:
There is one reason I think. We use FM DB as company Information
System and we continously modify their functions "under run" which is
interrupt every time a automatic script is recalled.

We would like to periodically call special scripts by means of SFire
plugin (Dacons).
For instance:
- Logout script every 10 minutes to keep DB protected when operator
leave computer and forget to logout manually
- Commit script every let say 1-2 minutes to release record modified
somebody who forget to release it manualy.
- Periodically update exchange ratio provided by internet connection
- Periodically synchronise with other IS

and simultaneuosly we need to develop, modify and correct layouts (our
system consists of apx. 20 files, 60 tables and 100 layouts).
So we need to detect Layout mode and block automatic scripts not
disturb a developer by automatic switching to Browse mode.

Probably our approach is not perfect and probably some of these
requirements might be solved by different approach, however we
consider this one as the easiest.
Anyway I would appreciate any advise.
Thank you
Jan Hruby
DataApex

I would strongly recommend not having your developers work on a open
and shared solution. You're opening yourself up for a host (pun
intended) of issues, including scripts not functioning correctly,
users being locked out of records, changes not being saved, etc.

But that's not the question you asked. Your automatic scripts could
include an "Enter Browse Mode" forcing the developer to stop their
work while the script ran, but they wouldn't lose it. Or you could
force developers to log in to a Developer Account that will supress
the scripts until they log into their User account.

G

On Jan 31, 12:32 am, "DataApex" <h... (AT) dataapex (DOT) com> wrote:

On Jan 31, 1:50 pm, "Grip" <g... (AT) cybermesa (DOT) com> wrote:
To offer another view, I can strongly recommend working on an open and
shared solution. I have built my company's solution as an in-house
developer. I started in 1998 not even knowing if FM could handle
everything I needed. Now I have an assistant, and we both work on the
system live every single day without issue.

A minimum amount of care is required and testing is done a little
differently, but it has been a dream working on this system all these
years, every day, live. Of course, this method is not optimal without
on-site developers, but in my situation, a user can call me up with a
request, I can gather the info, implement the change immediately after
my testing and see how it goes. It goes well.

Taking down a file or the whole system, making a change, then bringing
it back up? What a waste, especially in the case of simple layout
changes or simple script work. And the alternate method of working on
my own dev copy, then painstakingly exporting and importing all the
data once my changes are done? I would rather die.

I am about to upgrade to FM 8 from 5.5 and thank god I will be able to
modify field definitions live at that time instead of kicking all my
users out of a file. That will be awesome.

As for running scripts in layout mode, I think you are barking up the
wrong tree. I think you should look at other ways to solve the
problems you listed.

· Automatic logout? Isn't there a built in FM method of doing that?
And every 10 minutes? I wouldn't want to work for you as a user! Even
PayPal gives you longer than that!

· Commit record step for those users who can't commit -- you can solve
this by only letting users modify records by using an "edit record
script" with a special "edit records layout". In the script, enter
pause mode with a set time for auto-continue. This allows much better
control over error checking, etc. too.

· As for your periodic items, I'm not sure what you mean, but those
should run on a dedicated computer I would think where your plugin can
activate them regardless of what a user might be doing that would
interfere. I have carefully re-read your posts, and I am not sure
exactly what you have there...it sounds like you are the developer,
but yet the company has internal people doing development work, and
you are monitoring them? I probably don't completely understand your
situation, but it sounds odd. Typically a developer of a system of the
size you describe would already know all the tricks.

In article <1170228739.801418.217700 (AT) a75g2000cwd (DOT) googlegroups.com>,
"DataApex" <hruby (AT) dataapex (DOT) com> wrote:

Since the scripts are being called via a plug-in and not FileMaker
itself, then it is a possibility that FileMaker doesn't automatically
go into Browse Mode until you hit that Get(WindowMode) function, as you
said ... although I wouldn't like to bet on it.

Assuming that's true, you could try using the Get(CurrentUserName)
function instead.

In the developer's copy of FileMaker go to the Preferences and set the
User Name to be a custom one of "Developer" (for example). Then your
scripts could start by testing for that user and only continue if it's
not the developer.
ie.
If (Get(CurrentUserName) = "Developer")
Exit Script
End If
{continue with normal script}


Helpful Harry
Hopefully helping harassed humans happily handle handiwork hardships ;o)

On Jan 31, 9:22 pm, Helpful Harry <helpful_ha... (AT) nom (DOT) de.plume.com>
wrote:
Thanks a lot to all for suggestions and different opinions!
Briefly my comments:

To Harry:
It seems that the only possible solution is to have a "Pause"
button to interrupt automatic recalled scripts, because your
suggestion can be a part of FM script only.

To Paul:
Yes you are right the possibility to work on a open and shared
solution is a fantastic advantage balancing a lot of FM weak points.
As in-house developer (and company co-owner) for more than 10 years
I'm tottaly satisfied with so flexible style of work. As SW company
with 20 employees we need to react to changes of company structure,
current projects and new technologies quickly, flexibly without
downtime.
Users (I mean me and my colleagues) have to login to DB to
temporarly access private records or items (passwords, account
accesses, management information) only. So the automatic logout
woudln't disturb them I guess.
A special edit layout (similarly to a special find layout)
represents 2 (3) times more work when you need to change any item in
layout and definitelly it causes inconsistency.
Periodic items mean for instance displaying current date, and
current exchange ratio. These items are actualized everytime when the
DB is initialized during start, however our PCs (surprisingly, except
programmers of coarse) don't shut down for weeks. Yes there are other
posibility how to hook them on some other event however a timer would
be simplest and reliable solution....

To Grip:
Everything has pros and cons, after 10 years experience I'm sure
the possibility to modify a live system is one of the biggest
advantage of our IS based on FM. Of coarse I wouldn't suggest such
approach everywhere to everybody...

Jan Hruby

On Feb 1, 3:20 am, "DataApex" <h... (AT) dataapex (DOT) com> wrote:

then welcome to my (small) club! You will find we are in the minority
around here

I agree completely, but if you want to force people to exit records I
think such a thing will be required.

Current date is easy enough...it shouldn't require any special
updating. Regarding timers for the other stuff, yes, I too wish FM had
a built in handler for timer-driven events.

I pick up on the fly the sentence :
think such a thing will be required.
1) people in a team are pretty reliable : if someone blocks everybody because of a wrong behaviour, the others will soon tell him not to do so. It a is a kind of self controlled environment.
2) in the design stage one can avoid almost completely using globals to show any of the 'actual' records, except for some 'hard to get into' layouts or buttons that people would know they are reserved for managers.
My 2 cents.
Remi-Noel