So, what we really have is FileMaker Pro 7.5 not 8. What's your complaint?

They fixed a number of FM7 bugs that should have been fixed before 8. Late but great. BUT the big problem that I have with "8" is that it is still missing the ability to determine file paths via calculations! Can't believe this. They have an editable dialog box in which you can add File References to import or export files, but there isn't a way to script this without 3rd party plugins. Really Really Really ridiculous. I am so tired of complaining about this lack. What's the deal? Should be a breeze to add given the "File Reference" feature added in 7.

I think you are misinformed: it is possible to determine filepaths by calculation and there is, within windows at least, access to user specific paths Get(DesktopPath), Get(DocumentsPath).

I am so tired of complaining about this lack. What's the deal?

Reading some of the new basic info is the deal. You can use the new variables for it.

[ignore this post. I was oh so wrong. Read SlimJim's post.]

I agree with Bailey (mostly). There is still no way to script dynamic export/import paths. You cannot use those shiny new functions like Get (DesktopPath) in an export/import path (AFAIK). You still need a 3rd party tool to move the file there, from its fixed known location. The "known" part can be a problem, though there are locations that should be there on either platform. All 3rd party tools can dynamically return these locations; they don't need FileMaker functions to do so. What we need is a button to actually use those functions in the export/import file path dialog.

The fact that FileMaker is adding those functions seems to me a hint that they are moving in that direction. It must be more difficult that we think to enable scriptability for those file references. But Troi File has done it for quite a while. Also, David McKee (who I believe still works for FileMaker, but not in that capacity) did it quite a while ago, for free, with his free (awesome) FileToolbox plug-in; but that was pre-7.

When you do the export script step type the variable filepath into the Specify Output File Dialog.

For example, using a local variable $filepath

Set Variable[$filepath;Value:"file:" & Get(DesktopPath) & Company::Filename]

Export Records ["$filepath";Windows(ANSI)]

exports onto my desktop a file with the name given in the Filename field in the Company table.

In the Export records box you can as usual choose the fields you want to export etc.

Missing feature : More events. FM8 really ought to have events that trigger scripts for a bunch of situations -- field enter/leave/exit/value change/validation fail, window close, tab panel change...

SlimJim!! You are right!!! I would never have figured that you could do that with the new variables and File References!! Thanks. I take back half of my complaint about FM8. I still think that a SIMPLE way to add calculations to the File Reference would be more intuitive, but I will take whatever means other than a plugin. THANKS! THANKS! THANKS!

All I can say is I'll eat my hat :-) This is wonderful.

Yes...we need event triggers for audit trails, security logs, etc.

Double Click

I would love it if buttons (button setup…) had a double and single click script option - hell, throw in a right click option as well.

Right click option would be awesome. Especially if you could customize it.

FLASH SUPPORT: I can create buttons in flash that are hundred times better than in FileMaker. It would be nice if FM would load Flash files like web browser do ie. start playing once the record loads.

Quicktime Support: I want controls to automatically start playing a movie, sound, etc. when the record loads. It should just be checkbox that says start automatically.

Better relationships without join files. I don't know about everyone else, but (to me) join files are a pain in the but. Not to mention they litter the graph window making it cluttered.

GRAPH SUPORT: How many versions of FileMaker have we need graphing tools? Seriously, if FM can create a new (very cool) tab tool. A tool most didn't even know they needed. Why can't they go the extra step and create a graph tool? You know how awesome it would be to have native support for graphs without having to buy a plugin or fake it by filling up container fields with text?

Mobile support: There is a new version of FM Mobile to correspond with FM 8. I am hoping beyond all hope that they have fixed many of the thousands of complaints.

Double Click

The only purpose I see for a double click button is when the object must also be movable (like icons.) Are you suggesting this ability to move buttons is needed??

Better relationships without join files.

Join files are a basic part of relational design. Perhaps you don't understand what they're for. (Besides, it is possible to create many-to-many relationships without join files, it's just that it's usually better to use them.)

Not necessarily moveable, but selectable. So it could be nice to be able to click-select a record in a list or portal, and double-click to open it Form view. Not that it would be high on my priority list, though.

What about improving finds? You still can't do a complex find where you want to match one of several values in a field, or match on a field not equaling a value.

There's also basically two ways to do finds in a script. One that makes sense and is easy (perform find with restore), but is limited to pre-determined values, and another that requires many, many script steps and is inelegant (enter find mode, set field, etc). Why can't perform find take variables as values? Then I'd never have to use enter find mode.

I don't have many complaints but I do wish they would add the functionality to hide objects.

You should be able to hide any object based on a calculation.

match one of several values in a field

Not sure what you mean by that. You shouldn't have several values in a field anyway.

match on a field not equaling a value.

Match on a field equaling the value, wih omit checked.

Ok, maybe I should have said "boolean expressions" though FMers seems to recoil at the mention of boolean.

Let's say I want to find all records that have a type of 1 or 3, but don't have a origin of "China".

By "match one of several values in a field" I mean boolean "or". I'd like to type in "1, 3" or "1 or 3" or "1 | 3". By "match on a field not equaling a value" I mean entering "! China" or "!= China" or "<> China"

Why can't you do this with a "OR" find?

The Omit is the same as not equal and you have been able to OR finds since back in FMP 2 days.

It seems you would like to change the procedure (or syntax) to perform a certain kind of Find. That's different from "can't do".

I wish we could dynamically specify a name when using the following steps:

Perform Script, Set Field, Go to Field.

There are workarounds. For instance, the ZippScript plugin (or the MacExample/WinExample plugin on the developer CD) allows you to dynamically specify a script to perform, but with a caveat: the script won't execute until the current script is finished.

Regards,

Sean Mills

It seems you would like to change the procedure (or syntax) to perform a certain kind of Find. That's different from "can't do".

Well, you can obtain a complex find by doing several finds in a row, but it's unnecessarily complex and time consuming (both to implement and in processing time). The perform find script step has the potential to be a better find, but it's extremely limited by the fact that it can't handle calculations and do boolean operations.

My only complaint is still the inability to copy custom functions. They fixed this with tables and fields in the advanced version, but you still can't copy & paste custom functions.

I don't have a problem copying and pasting custom functions.

I mean from one file to another, or an import button on them like you can with regular scripts.

What's with the stringent Mac OS requirements? 10.3.9 minimum? Yikes! Windows goes back to Windows 2000 . . .

Has anyone tried this with a pre OS X 10.3.9 system?

Here's a biggie that everyone's missing:

Alarm Functionality.

You shouldn't have to purchase a pluging (ie. Troi Activator) just to make a contact management application really behave like a contact management application!

Better relationships without join files.

Join files are a basic part of relational design. Perhaps you don't understand what they're for. (Besides, it is possible to create many-to-many relationships without join files, it's just that it's usually better to use them.)

I'd like to be able to select an item in Layout Mode, then be able to edit the attached script - from either a right-click or from within button set up, rather than closing the button set up window, then manually finding the script within ScriptMaker . . .

Edited September 7, 200520 yr by Guest

ditto.

I just feel that, every join file that I've created has been almost identical. So why can't FileMaker have an auto generate join file?

How is FileMaker to know what fields to include in join files/tables? How is FileMaker to know how to join them? Are you suggesting it use some sort of Wizard to ask you, like the report creation thingy? No thanks! I say keep the process the same as it is for creating any other table, and join them explicitly, as needed.

Further more isn't the jointable required in every occurance of a many2many structure, I have once and a while been caught using either recursive functions (returndelimited lists) or even repeating fields acting as the jointable. It takes scripts to delete or create joins if a dedicated table is needed, while....

--sd

What about Printing to a default printer (in windows) without a dialog box

The current Print Setup step restores automatically the printer wich was default during the script creation.

It's a HUGE bug ...

This has been one my biggest complaints as well. Add to this item a way to better organize scripts into groups so I don't have to scroll through 200 scripts to find the one I am looking for.

I wish we could dynamically specify a name when using the following steps:

Perform Script, Set Field, Go to Field.

Yes, yes, yes. I don't find that scripts are as big an issue as they used to be, now that we have script params. I just refactor my scripts so that calling one does the trick.

But not having the ability to have a variable target for SetField is a pretty glaring hole.

I think it's somewhat amusing (and painful) that, in this day and age, if you want to variably assign a value to one (or more) of a number of fields, you still have to resort to tricks like putting them all on a layout and tabbing through.

I think it's somewhat crazy that FMP spends time on gizmos like PDF creation, and never gets around to basic scripting stuff like this.

I like the PDF creation feature. It saved my users lots of time as well as error reduction. -)

Also, I agree with you regarding dynamic target set fields.

The feature that would would be nice to have in a future release is printer selection. For example, Ii would be great for end users to be able to click a button and letters for their found records be printed to a color printer and the corresponding evelopes printed to a different B&W printer without them having them change the printer.

Also it would be great to have access to managing accounts without having to give 100% full Access so that layouts etc can not me modified, but accounts can be managed by a person with privileges to addd, change, and delete accounts.

Edited September 12, 200520 yr by Guest

There are a number of problems with the WinExample Plug-in. If you have a 'regular script' that exits the field that the plug-in is associated with, it will start to run in the middle of the other script. Since it's not run with a button, you can't halt the originally running script.

I've also had corruption on EVERY layout that the field was on.

Also, although I didn't take the time to verify it, a customer with FMP 8 reported to me that the plug-in didn't run and didn't appear in the plug-in list. Reviewing the details of the plug-in file in Windows Explorer showed that it actually was opened by FM.

In 7 you could select a field and then, using your mouse, scroll through records in Form view. You can no longer do this.

This is, I am assuming, because scroll wheel is now supported for fields with verticle scroll bars.

I think its better this way anyway. Users can still scroll through records with the wheel when not in a field.

I tried to use scroll in a portal with scroll bars but it did not work. Is that what you are referring to? Or do you mean edit boxes with scroll bars? I have never used them for those fields seeing how, without them, all text is displayed once you select the field.

If you have a portal with more records than the number of portal rows and you have on the verticle sroll bar, once you select a row the scroll wheel should move the portal.

As for the Edit boxes, it is good to have scroll support when you have large amounts of text in those text fields, such as notes sections, etc.

What I'd like to see is more definable short cut keys - at the moment it seems to be stuck on Ctrl-0 to Ctrl-9 to perform the top ten scripts and those scripts have to be displayed. How about being able to set eg. Ctrl-Alt-H to trigger a hidden script? "Define Short-Cuts" anyone?

(Only just got FM8 so sorry filemaker God if this has been implemented and I haven't noticed!)

What I'd like to see is more definable short cut keys - at the moment it seems to be stuck on Ctrl-0 to Ctrl-9 to perform the top ten scripts and those scripts have to be displayed. How about being able to set eg. Ctrl-Alt-H to trigger a hidden script? "Define Short-Cuts" anyone?

(Only just got FM8 so sorry filemaker God if this has been implemented and I haven't noticed!)

This is implemented in FMP8 Advanced as Custom Menus. You can create custom menus that run scripts and they can have any shortcut key you define.

Two people mentioned wanting the ability to go straight to a button's script without having to find it in scriptmaker.

This can be done by turning on Debug, clicking the button and then opening scriptmaker from the Debug window. The script you have run will be selected in the list.

Two features that would be good:

1) In the portal setup dialog an option to allow or disallow record creation would be great. I realize that this can be turned off in the relationship itself however many times I also need to have the relationship be able to create records (as in when my users clicks the Edit button I provide, other times I want a view only option. I hate having to create a new relationship just for this, creating more clutter in the relationship graph, and also having that automatic new line show up in the portal.

2) As a further extension of the new drop down list feature to not display the first field, it would be great if we had an option that said something like "place field field value in field X" where X would be for example your id field that you are trying to hide. This would allow us to not have to place the ID field on the layout at all, not having to make it invisible etc. As well the user woudl not be able to edit that field and erase the ID number.

I am having a serious problem with keyboard response delay in 8 vs 7. I have attached a file to show what I mean or else you can try this: Create a layout and drag the body down so that it is 7 pages long. Create a single text box (not a text field as I said in this post before editing, just a text box) that stretches the entire 7 pages. Then type some text into the field. The delay is unbearable. Now open this same file in 7 and type - NO DELAY! Is it me or is something really wrong here?

KeyDelay.zip

Edited November 23, 200520 yr by Guest

I agree with the comment that 8 is really 7.5. They did fix some bugs which were quite annoying. Here is my little wishlist...

1. The ability to create views like SQL, where I can show all records from a table that have field=fixed text or number. Right now, I have to create a unstored calculation field for the fixed text and create a relationship. It is cumbersome and slow.

2. Maximize window boxes for the scrips, variable list and define database windows.

3. The ability to import variable lists and layouts (combining 15 files with over 200 layouts was a major PIA without this)

4. The ability for server to manage preferences in client software (i.e. memory allocation, user names, etc.)

5. Heiharchial (sp?) menu lists

6. The ability to disable or remove functions from the main menu on top (not advanced since it can't support multiple users)

In 7 you could select a field and then, using your mouse, scroll through records in Form view. You can no longer do this.

OMG,

I threw a party when FM elimitaed this horrible behavior. Users expect their scroll wheel to scroll in the current view, not cause the record they are working on to suddenly change fo no obvious reason!

It's still not perfectly contextual, but it's a vast improvement.

My major wishes/needs:

"live" object/field handling, assign script triggers/hotkeys to specific layout object or field. on click, on doubleclick, on select, on hotkey , on exit.

I would like to see improvement of web compatibility such as printing. It is still not an option through web hosted databases other than to "Print Largest Frame."

I would also like to be able to create a new page on the Relationships Graph rather than scrolling all around making a cluttered mess.

And finally, fix the bug of disappearing records. I've seen some others complain about it and it happens on even the simplest solutions. There should also be more intuitive and easy export to other formats including ANSII, NSF-- (or maybe these are best left to third party programmers.)

Insufficient upgrades to qualify as a new version but I have to buy it anyway. Does this mean that a new, legitimate upgrade is far away or just around the corner?