How about these features?

[SteveB]

Anybody know if they now support mouse-over help, a popup calendar, running a script on field exit, and definable menus like Menu Control?

Steve

Moderators: You need to add Developer v5.5 to the questionaire!

Version: Developer v6

Platform: Windows XP

[andygaunt]

No mouse over help, no pop up calendar, no running a script on field exit and no user defineable menus...............

AFAIK

You can use the enter key to leave a field though!!!!

[SteveB]

[RANT EDITED] ...spend all this time making changes and then leave out basic stuff that every modern system does. Gimme a break, no mouse over help? Basically, it seems that if a plugin developer does it, FMI won't. I'm all for tar and feathering Goupil already.

Steve (that felt good!)

[Wim Decorte]

Looking at the new product, it gives us a lot of goodies to build a better, more stable relational solution and do it faster.

The features you're listing are mainly GUI only. All of them available through plug-ins. While it would be nice to have all those natively, they are not crucial in my mind.

HTH

Wim

[Lee Smith]

Wim Decorte said:

The features you're listing are mainly GUI only. All of them available through plug-ins. While it would be nice to have all those natively, they are not crucial in my mind.

Hi Wim,

Maybe so, but they are also features that have been requested on Wish Lists, on every list I have been a member of, for as long as I can remember.

Lee

Version: v6.x

Platform: Mac OS 9

[SteveB]

And what is more, the GUI is what users rate software on. I use SimpleHelp from 24USoftware, but it has its own set of problems and is far from perfect. As Lee says, it has been requested since before version 5. It proves one thing: FMI does not listen to the developer community. I would sooner spend more on buying Filemaker, than on the 5 plugins that I now use (cost is in excess of $1200).

[Steven H. Blackwell]

Contrary to this vitriol, FMI has listened very closely to the development community. And FileMaker Pro 7 reflects that. The new relational model, the new security model, the new text processing engine, and many, many of the new calculation functions are a direct result of developer request and developer input.

Steven

[geod]

Steven, I would be very interested to hear your opinion as to why, for example: script triggering, did not rate as high on FileMaker's new feature list from the developers, as the others, you have mentioned. Which I feel are positive additions. If you care to comment. Thanks !

graham

Version: v6.x

Platform: Windows XP

[andygaunt]

Maybe the items listed above were not requested by the FileMaker "Partners"

We know where the majority of the security requests came from and hey, they made it in.

Script Triggering surely is highest on most developers minds, we see it talked about here time after time after time. I know it has been a requested feature since version 3. Yet still we have to revert to external plug-ins.

I have plenty of plug-ins that I have purchased and this is the one that I use the most.

It really would be nice to hear from FileMaker though on the choice of upgrades. After all, without this development community they have what?

[Vaughan]

I bet FMI asked the developers to rate the features they'd like to see added.

What would you rate higher: breaking the 64KB text field limit and 2GB file size limit; having multiple tables in a file; calculated text formatting... or introducing stuff that is already available through 3rd party plug-ins?

[SteveB]

Steven, you are hardly an unbiased observer for what FMI produces. You and I went around when FMI released v5.5 and again when it released v.6. I'll bet that virtually every developer on this forum will support the needs for mouse-over help, triggering scripts on field exit, etc.

All you seem to do is deny they ignore our needs.

Steve

[Steven H. Blackwell]

FMI conducted extensive meetings with customers and developers around the world in the process of determining what they would like to include in the new version. Based on that they produced specifications for the enginnering teams to work aginst. Given the nature of software development, not everything makes it to the final product.

Vaughan pretty much got it correct. I'll trade the new relational model, the new security model, the new Custom Functions, and the transaction model for event triggers. And remember they did add post processing for text, number, date, and time fields.

I make no apology for the nature of my relationship with the company as an FSA Partner. The same opportunity is open to any other developer who wishes it, as 24 other developer organizations in North America have chosen to do.

Steven

[SteveB]

You're certainly welcome to have any relationship with them that you desire. However, that leads me to believe that you lack a certain degree of objectivity. This site is probably the largest collection of FM developers in the world, but how often do we see anybody from FM here? They may lurk in the shadows, but they clearly don't care about our opinions. First it was, 'to add mouse-over help we would have to change the file structure'. Well, they changed the file structure and what did we get? Excuses from you.

I reiterate:

If a plugin maker has developed a plugin, FMI will stay away. Altho I haven't played with v7 yet, I'd bet that the dialog plugin makers will still have a ready made market, because FMI's attempt (if there is one) will be pathetic.

Steve

[Robert Schaub]

Just playing around a litle with the Custom Dialog. It appears the date validation is fixed.

Not sure I Get the Get functions, I looks like the Status functions are gone

Are these ther replacements?

[Oldfogey]

I'm in the process of developing a number of run-time solutions. There is NO WAY I would use a plug-in in a distributed solution. I've had enough trouble with FMP (or my CD burner, or the ether, or.... ) actually restoring a value in a Global after I'd changed it. Yep, I know that's impossible. I don't believe me either. But it happened - twice.

I do a bit of work in MS Access if I can't avoid it and the only significant function in Access that can't be done in FMP is launching a script on tabbing out of a field. (I know there are millions of other things but only 2% of solutions need them.)

[Henry]

There are many new features in Fm7, i think it will nearly become a programming tools. Just i can't found any new feature related to keyboard handling, just like capture keyboard action. I think last time i have suggested to enhance the Enter/Return key feature to FMI Australia, but not sure it can found in FM7 or not. (now on my wway to downloading the demo version)

The other things is now FmUlimited will combine with Fmserver and become FMServer Advance. FMServer Advance actually is add up the price of FMUnlimited and FMServer. For those customer just use 1 FMU as a web server , now they need to pay extra USD$1*** for the license. In Filemaker Pro 7, it support up to 5 simultaneous web user. But how about a company that just need about 10 web user, the license price will be big different, because they need to buy the FMserver Advance.

Regards,

Henry

[Steven H. Blackwell]

"if a plugin maker has developed a plugin, FMI will stay away."

I am sure that the developers of the various SQL plug-ins would be fascinated to hear that report. As a general rule the plugin developers go where FMI has not gone, not the other way around.

Steven

[Steven H. Blackwell]

"Not sure I Get the Get functions, I looks like the Status functions are gone

Are these ther replacements? "

Status Functions are gone. GET Functions replace and augment them. There are a number of new ones that are of particular usefulness.

Steven

[Ken Newell]

Steve give 7 a try and then I would like to hear what you think about it. It is very hard to take your criticisim of the product when you post that you have not tried it.

[SteveB]

I fully intend to switch to v7. My comments had to do with things I had hoped they would have had the brains to make internal: mouse-over help and script triggering, among others. The script triggering is probably adequately handled by a number of plugins. The mouse over is NOT. The only one I'm aware of is SimpleHelp, and it fails in a number of areas: it only works in the 1st portal row; it has a bug and works on layouts that have no assigned help, making it a pain to use (you have to remove the help thru script control before you leave the layout). This is a function that should be handled internally by FM, not by a plugin.

I know that they added a lot of stuff. But, like the last 2 upgrades that I'm familiar with, they left out what most of us would deem important. I'll grant you that my list of priorities is different from yours. How could they have left out being able to see a field's value in the debugger? Does v7 fix this omission?

Steve

[costello_ryan]

I am a bit suprised they didn't include running a script on field exit. If you're on Windows you can still use my free plug-in that will do this trick at

http://costello_ryan.tripod.com

I was mainly hoping for them to include a VBA engine like MS Word or Excel. That would have been cool.

I sure like the new file format though, with multiple tables in the same file.

[Fitch]

Oldfogey said:

...There is NO WAY I would use a plug-in in a distributed solution. ...

My company relies on a number of plugins for our product. There have been a few support issues with credit card plugins in particular, but all have been resolved. We also use SMTPit and several Troi plugins that I would say are very solid.

[Steven H. Blackwell]

I use plug-ins heavily. I have no problem with them. They added great functionality to FileMaker Pro 6 solutions. I expect they will do the same for FileMaker Pro 7 ones, especially the new Server side plug-ins.

Steven

[Mariano Peterson]

Ryan | Steven, using plug-ins to trigger scripts requires that you make calls to external functions from within field validations. This is a sub-par method of implementing script triggers, although the only one possible given FileMaker's weak plug-in API. While triggering field validations more or less handles the need for database triggers, it doesn't meet the need for application events. Since FileMaker is both a database and an integraged development environment, the use of application events is very important to building a rich user interface.

Sure, there are some ways in which you could munge the current script trigger plug-ins to trigger application events, but the munge introduces a lot of maintenance related headaches. What we really need are field level triggers, layout events (field: onEnter, onExit, onChange, etc), and table events (onNewRecord, onDeleteRecord, onFind, onRecordChange, etc).

These needs are not addressed by FileMaker 7, are not addressed by plug-in developers, and perhaps more importantly, cannot be addressed by plug-in developers until FileMaker implements a more robust plug-in architecture and releases a richer plug-in API.

We really ought to be able to write our own custom layout objects, similar to Access, VB, and Servoy developers can (just to name a few). While I respect FileMaker's goal of "keeping it simple" so as not to loose their entry level customers, FMI should really have implemented this functionality years ago for at least the Developer version of their product line.