A few miscellaneous thoughts... and thanks

[booboo]

This has to be the greatest forum. It really is great to be a member of a forum where people like Cobalt Sky - with a seemingly inexhaustible supply of knowledge and enthusiasm - jumps to the rescue of confused FileMakers, beginners and advanced alike.

So there had been 'pressure' put on FileMaker Inc. to make FM7 a front end for SQL? If that's true, then pressure has to have come from the mother-ship? Mr J, with his recent embrace of Open-source also has the vision to realize that FileMaker is an old program and that FileMaker Inc. haven't exactly bust a gut getting much-needed improvements out the door. If anyone could instill the terror that leads to quantum jumps in design and performance (or just plain terror) then it's probably Mr Jobs. (He probably threatened to dump the Windows version, fold the company back into Apple, dump the Mac version, and have the 2 remaining, gibbering, quaking programmers instead concentrate their efforts 24/7 into a Mac-friendly front end for MySQL.)

I've been a semi-pro FileMaker developer for about 3 years, and I admit I have almost zero knowledge of other database applications. (I'm always amused by the titles of books like Teach Yourself FileMaker in 24 Hours. It's been 3 years for me and I'm still learning, and sometimes coming up with the right calculation or script can still be a major headache.) Learning FileMaker, for me, has been as much about learning to think in a certain way - often quite laterally, as anything else. And a lot of headache pills.

In one solution for an Actors and Extras Casting Agency, I wanted to show the dates for the currently selected role on the currently selected job in the most-used related file. I wanted it to show horizontally in a small area at the top of each layout in the Actors and Extras database, which is where the users spend most of their time.

A horizontal portal would have done. except that the format I wanted to show it in was: Sep 18 19 22 and when the months ran over, thus: Sep 22 23 28 Oct 2 3. My solution was to use a calculation from ValueListItems(StatusCurrentFileName,ValueList) but the calculation being necessarily unstored, caused a performance hit. (Users want to switch from record to record as quickly as possible) The solution was to store the results of this calculation in a text field which was triggered by changing either the selected Job or the selected Role fields. For a while I couldn't get this to work because these fields were globals, and changing a global does not seem to allow triggering of a lookup. Then I realized that I could replace on of these globals by a non-global text field in a related record, and that's what I did. Now the trigger works fine, and there's no delay waiting for a (fairly) complex calculation when switching records. Phew!

There is some satisfaction in finally clawing your way to a solution, but sometimes it feels like FileMaker development is one workaround after another. Kludge city. (And mainly workarounds for not being able to run a script on exiting a field at that...)

Are other systems like this? Or maybe these aren't workarounds, maybe this is the nature of all 'programming'? I don't know.

As many FileMaker solution end up like mini-app's, I do wonder how something like RealBasic tied to a database compares. or even Servoy? I'd imagine getting instant gratification would be harder, but that maybe the more complex solutions would actually be more straightforwardly logical? Also, most of the instant things in FM, like Pop-up menus from ValueLists, and checkboxes, lend themselves to bad habits that probably shield the user from understanding proper relational design in the first place.

I have to say that I didn't really get to grips with FM itself - if I have at all - until I read a little about general relational database theory.

Don't get me wrong, I think FileMaker is great, 'deep', and the possibilities are enormous, but I truly hope that FileMaker X, which seems to have withstood the SQL pressures, really does bring a whole new level of programmability. And at least some script-triggering from field exiting...

Plus some of the most annoying aspects are those that could be fixed so easily - almost hacked fixed - like the fact that some windows can't be re-sized, and column widths (in Define Fields/Define Relationships) aren't remembered.

Or no Copy and Paste inside ScriptMaker... grrr!

I've already ordered Rich Coulombre/Jonathan Price Special Edition Using FileMaker Pro X - hoping it will be as amusing as the version for FMP5 - it's apparently due Oct 31st. This means that either some developers have had FileMaker X in their hands long enough to write a book about, or Amazon are lying (or just being optimistic.)

I can't plug that book without also mentioning Chris Moyer and Bob bowers Advanced FileMaker Pro Techniques For Developers. If you internalise the concepts in this book, then you're really on your way to being an advanced FileMaker developer, imho.

I did look at Scriptology, and it does seem like a wealth of (slightly less advanced) information and tips, but at nearly 50% more than the combined cost of both these truly excellent books (in the UK at least) I decided against it.

If FMX is out there (somewhere) I'm shocked that there haven't been more rumours or even leaked builds (I mean versions of Jaguar 10.3 are all over the place...;-)) Perhaps FM developers are more 'business minded' and less 'open source' than other application users at large, although personally I wish FileMaker Inc would put some early betas out there for everyone, not only to maximize the number of people bug testing, but also to give us non-pro developers a glimpse of where we might be able to take our projects with the new functions available.

[Ugo DI LUCA]

There is some satisfaction in finally clawing your way to a solution, but sometimes it feels like FileMaker development is one workaround after another. Kludge city. (And mainly workarounds for not being able to run a script on exiting a field at that...)

Are other systems like this? Or maybe these aren't workarounds, maybe this is the nature of all 'programming'? I don't know.

Programmers are designing an application that will allow a developer to use as many workarounds he needs to by-pass the limits of the "Programme".

Once the programmer converts some developer "wishes" in a solution, there are chances that the developer will be quickly watching 2 steps ahead for another improvement.

Besides, developers are here to "develop" and integrate some workarounds, that would render their apps somehow "unique", or at least different than the neighbor's.

The number of work-around will grew up, in rythm with the number of solutions provides by the "programmer".

So Kludge City will still evolve.