Hi all,

Looking for an easy-to-develop but robust developer database for
Windows AND Mac.

I've returned to Mac after many years and, of course, love coming back
to a computer that makes sense.

I am planning to do some pretty easy (accounting) database application
work and just before I went to evaluate 4D I saw the wonderful news of
Filemaker Pro 7 - multiple tables in a single file and so on.

Just how customisable are the forms and just how robust is the
scripting language?

I would like to hide the standard Filemaker Pro navigation methods and
so on to basically make a fully customised solution - is such a thing
such as script-based record navigation (top, bottom, previous, next)
available?

Can I hide Filemaker Pro menus and add my own customisable menus?

Are the form status bars and navigation frames and windows resizing
absolutely controllable (i.e. prevent the user from ever used
Filemaker underneath my application)?

Is the Developer version of 7 available in Australia - all I can see
is Pro and Server for sale in the store - I take it that Pro cannot
compile a database to run as its own application.

If anyone wants to point me in the direction of a Filemaker Pro 7
script language guide then I'd be much appreciative.

Come on FMP nuts - evangelise!

David Turnedge

In article <cb2a7710.0410240001.41122dae (AT) posting (DOT) google.com>,
turnedge (AT) screentime (DOT) com.au (David Turnedge) wrote:

I've no idea about 4D's abilities these days, but FileMaker Pro is NOT
a fully fledged "application development environment" and never has
been (despite what FileMaker like to claim). What FileMaker Pro is
really a "database development package".

NOTE: This is all based on my work with FileMaker versions 1 to 6 and
what I've read about version 7 - I haven't used FileMaker 7, but this
all seems to still fit Developer 7.

Many of the things you list below can not be done in standard FileMaker
Pro, although some can be done by using (usually over expensive)
third-party plug-ins.

Having said that, FileMaker Pro IS an extremely good and powerful
product for producing custom database systems quickly, efficiently and
in an easy to use way - as with anything, it's easy to create a
disaster that nobody would want to use. There are even FileMaker
databases around that have been created to play games like Mastermind,
Yahtzee and even multi-user Monopoly. )




FileMaker Pro bascially has a simple DTP-style environment for creating
layouts, so the "forms" are very highly customisable.

The scripting language is NOT a programming language as such. It is
only point 'n' click commands (with the ability to type in the If tests
and calculations, etc.). The scripting language is very powerful for
controlling the data / records and performing the normal duties of
printing, etc., but is not designed for creating hugely customised
applications in the same sense as something like REALBasic or C. There
are VERY simple abilities to control window size and lock/unlock window
gadgets like the Zoom gadgets.




You can easily hide FileMaker's side 'Status' bar and button bar and
create your own buttons/scripts to perform those functions.



Yes and no.

"Kiosk Mode" lets you hide Filemaker's menu bar AND the desktop / other
applications - it takes over the whole screen and runs the database as
though it was an information kiosk.

In "normal mode" you can't hide the menu bar, but you can disable some
commands for users by defining passwords (ie. one for you with full
access and one everyone else with limited access - that one can be
blank so that users do not have to enter it every time they open the
files).

You can't customise the menus. but there are third-party plug-ins that
can do this for FileMaker Pro.



Basically, no.

Using passwords you can block and limit access to various abilities
(ie. not letting users access or change layouts and scripts), but you
can't stop the user changing the size of windows. You also can't change
the size of a window dynamically (ie. to a specific pixel size).




You probably won't find Develop on the shelves of most shops since it's
aimed at a "Developer" and not the average user.

There's actually little difference between Developer and normal
FileMaker. Developer adds a few (sometimes) handy tools that aren't
strictly necessary to develop FileMaker databases. As such you can
download the demo version of Filemaker and "play" with that to see what
can and can't be done before spending any money.

Developer also has the ability to create 'Runtime' files, but it does
not create a single application. What you get is an application which
is really a cut-down version of FileMaker (without the script making
and layout abilities) and some slightly modified versions of your
database files (which can still be opened in normal FileMaker too). Any
installer for you custom "application" would also need to install
various extras into the appropriates places (eg. any fonts or third
party plug-ins you've used, assuming you've paid for the right to
distribute those).

You can create the database files on any OS (with the usual font and
graphic hassles), but you do have to create the runtime application on
the appropriate OS (ie. create the Mac application on a Mac and the
Windows application on a Windows computer). The runtime can use
different codes so that you can have double-clickable files that run
the appropriate application rather than FileMaker itself, so if you
create multiple custom databases you may or may not want to create
multiple runtime applications. Technically thes runtime applications
(per OS) are ALWAYS the same application file (with the exception of
the codes), so once created you can simply edit the data files in
normal FileMaker without bothering to recreate the runtime itself.



No idea I'm afraid, I simply taught myself through "playing" (since
version 1 of FileMaker), but as said above, the scripting language
isn't that complex and since you choose the commands, fields and
functions from displayed lists it shouldn't take long to work out the
"beginner" to "mid" level bits.



Basically, if you've got access to a fast Internet connection (or
enough spare online time) you should probably download the FileMaker
demo and simply "play".
http://www.filemaker.com.au/products/try_filemaker.html

It's not the Developer version, but as above there's little difference
really and it should help you to soon see the basics of what FileMaker
can and can't do. )




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

Hmmm, thanks for these helpful tips, Harry.

I've played with the demo and, from what I've seen, I like the
simplicity.

It's a pity the company hasn't incorporated a more robust scripting
language and more customisable features (windows and field control and
menus to name three I'd need) because it seems to me most of it would
be easy and FMP is a straight forward easy-to-use tool.

I don't want to write a program from scratch in BASIC and I absolutely
hate the 'we do our version of UI' of 4D - I've seen a few
commercially available 4D developed apps and they're not up to par.

FMP is nice... no, it's real nice... maybe version 8 will do the job -
there's not much to do to make it twice as attractive as it already
is!

Can anyone suggest a good source of add-ins that might do what I'm
looking for - specifically more control of the UI?

David

David Turnedge <turnedge (AT) screentime (DOT) com.au> wrote:

Forms (layouts in FM) are extremely customizeable. Some of the most
elegant interfaces I know of are Filemaker. (See
http://www.smallco.net/tools.html
and
http://www.alchemy-group.com/careminder_screens.html

for work from two of the best designers using FM today, Albert
Harum-Alvarez & Bob Shockey)

Mostly interface depends on YOUR talents as a designer and developer.
Let VB and Access try to do THAT.

You won't have ALL the fine control of objects you would in actual
development environments, but you should be able to do almost everything
you COULD in those environments, quicker, more easily (in most cases)
and more economically for your clients.

I won't lie and say there aren't moments we wish there weren't QUITE so
many work-arounds, but as a developer in FM since the FIRST FM Pro, and
now having used 7 since the beta program, I have to say I love 7. Even
faster to develop, even easier to maintain than 6. Fewer work-arounds
as FMI has really heard developers on this last release. End users
aren't going to notice much difference, but the dramatic changes and
improvements are tremendous.

I've deployed my first custom solution in 7, and working with a data
separation model has been elegant, easy and substantially problem free.
Other developers are reporting some problems, but FM has already
released 2 substantial bug fixes and others are on the way.
Yes, and yes. Kiosk mode hides ALL FM menus and nav frames, there are
plugins such as MenuMagic and SecureFM (bundled from newmillennium.com)
that will hide/change menus when not in kiosk mode, including disabling
the close box, minimizing, window sizing, and contextual rightclick
menus.
Mostly. In fact, I have to specifically ALLOW my users to minimize or
open other files when I deploy SecureFM with solutions so that they can
use their other FM files. While not in kiosk mode, navigation frames
are always visible, but status bars are hideable by scripting, in 7
windows are totally controllable, with size, placement, and naming all
contingent on either hard-coding or results of calculations.
See the FM Australia (or Asia) site for availability. Developer is not
sold in stores, you have to purchase directly. Joining the FSA gets you
free software, including testing copies of FM Server and FM Server
Advanced. This is in the US, your region may vary.

Developer 7 will bind runtimes, but only for OS X, Win2000 & greater. If
your clients still use OS 9 or Win98, this will not work for you. Older
versions of FM still support those OSs. Runtimes are not networkable.
However, the new Instant Web Publishing is supposed to knock your socks
off.
The new "Special Edition Using Filemaker Pro 7" by Steve Lane, et al,
gets the best reviews in the FSA. It's a complete reference. Scripting
may SEEM a little crude, and there are certainly things we'd like to
change about the interface, but in the hands of experience, it can be
really powerful.
Most small to largish businesses have data needs that fit FM's profile
perfectly. If the data sets are large or the transactions crunched are
major, looking into using Servoy with SQL backends. However, the
deployment, development and maintenance needs and costs of FM are much
less than any SQL project, taken in total.

FM's flexibility, once deployed, is a major selling point. Our firm won
a project away from Great Plains, because we could promise continuing
development and customization for reasonable cost, and swift response to
client needs. When asked about some of the requirements, the GP folks
said "uhhhh, yeah, but it'll cost $20,000" when talking about simple
reporting requirements. On others, they just said it couldn't be done.
We do it, in FM. Quickly.

We interact FM with SQL dbs, XML post responses, Quickbooks, SQL
accounting systems, HTML and Excel exports, email systems, fax servers,
and more. It's an ideal "middleware" when you have a lot of different
apps that need to talk to one another.

We don't do accounting itself in FM, we tend to link to actual
accounting software. However, doing sales orders, purchase orders and
invoicing is very easy, then we push the data into the accounting
software. Business logic is sooo much easier to enforce in FM.

Plus, FM is fun, we have kick-butt developer's conferences, and we have
a much better sense of humor than those Access geeks. Download the
free demo version of 7 from the FM site and take a look.

Lynn Allen
---
www.semiotics.com
562.938.7890

Dear Lynn,

Many thanks for your note.

This is exactly the post I was looking (hoping) for!

I've already discovered two plugins that do what I want regarding
menus and windows - all I'm looking for now is an ability to lock
individual fields and then I'm in demo heaven - with the outstanding
new database specs in FMP7 (multiple tables in a single file, large
databases, etc.) I'm all but sold on the product.

To think I was struggling with Visual FoxPro for all those years.

The production is truely an example of how things *should* be done -
don't worry about the programming, just worry about developing
solutions!

If you've ever used Great Plains Dexterity you will see that the
developer tool used to build Great Plains is a lot like FMP - just
concentrate on solutions, solutions, solutions!

Many thanks,
David

In article <cb2a7710.0410250312.53552d75 (AT) posting (DOT) google.com>,
turnedge (AT) screentime (DOT) com.au (David Turnedge) wrote:

You might want to download a few example applications (see the links at
the end).

There's a couple more things I forget to mention about FileMaker
runtime applications.

Runtime applications always display the FileMaker splash window when
opening. This can not be removed and can not be legally altered. I
don't think this has been changed for FileMaker 7, but it was optional
under FileMaker 4. (

On the plus side FileMaker runtime applications do let you change the
About and Help menu items to run your own script to do whatever you
want (within FileMaker's limits of course).

I'm not certain if it's been fixed (some people have said yes, and some
say no), but older versions of FileMaker were printer driver driven
rather than driving the printer themselves, but then that's the same
for many applications. This meant that if you set a script to store a
page setup of 'A4 landscape' for your Epson it would work fine, but if
you changed printers / computers / OSes then the page setup would
revert to 'US Letter portrait'. You can have a script store multiple
page setups for different printers, but you have to "train" (or
re-store) the page set-up while the specific printer driver is active.
Obviously this is impossible if you're planning to produce a shareware
application where the unknown end-user can have any of many hundreds of
printers.




You do have to remember that FileMaker is a database development tool,
not an application development environment - the best proof of this is
that because the runtime application is just a cut down version of
FileMaker itself, it weighs in at around 3+meg, plus your data files,
plug-ins, etc. (Then again, the same happens with some things that ARE
marketed as 'application development environments', eg. REALBasic and
Runtime Revolution. The only way to get an efficient custom application
is to use C, Java or similar.)

But when taken as such is is very flexible and powerful, although like
any piece of software it does have a few annoying features too. Most
can be worked around or fixed by adding a plug-in.




I doubt it and I hope not. Trying to make an application do everything
makes it over-bloated with stuff most people simply don't need - that's
partly why FileMaker encourages third-party people to create plug-ins.

Personally, form what I've been reading I think FileMaker 7 has already
started down a path of getting too complex for it's own good, but we'll
have to see what happens. The whole point of FileMaker was that is was
very easy to use and quick to produce a good product (especially when
compared to the likes of competitors like 4D, Omnis or Access) even if
in some ways it was under-powered. Maybe there needs to be a "FileMaker
Lite" (although do we really need a "9th" FileMaker in the product
line-up) or they upgrade the database component of AppleWorks to be
what FileMaker 4 or 5 was. )




It really depends on what you want to be able to do and how much you
want to spend. Plug-ins come in all shapes and sizes, from free ones to
over-expensive ones that do almost nothing useful.

Some good places to look for plug-ins and example files are:
http://www.geocities.com/SiliconVall...7/plPLUGs.html
http://www.digfm.org/plugs.html
http://www.fmplugins.com/
http://www.fmfiles.com/dev7.html
http://www.filemakerworld.com/
http://databasepros.com/resources.html

among many others.




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

David Turnedge <turnedge (AT) screentime (DOT) com.au> wrote:

David:

It depends on what you mean by "Lock" as to how it's accomplished. FM7
has new "field behavior" settings that let you determine whether users
can enter the field in Browse mode, Find mode, or neither, on a per
field/per layout basis.

Alternatively, you can set field validation rules that let you determine
whether initial entry or editing can take place based on a value in
another field, either a "lock flag" or a particular field or set of
fields on the record, or in a related file. The new "Evaluate" function
is extremely powerful, allowing validations that only trigger when
certain other fields are modified.

The new behavior of auto-enter calculations, alone or when combined with
the above, also offer opportunities to manage data input. Privilege set
editing can give very fine control per table or per file regarding who
can access, view or edit fields based on the security schema.

And there are always interface designs that manage user interaction so
that they see or edit fields only when the developer wants them to.

If you have more exotic locking needs....see your local dominatrix.

Lynn Allen
---
www.semiotics.com
562.938.7890