booboo

I'd agree with BobWeaver, the Advanced FMP Techniques For Developers is a very good book, and one that goes beyond every other FMP book I've ever read. I found the general theory interesting, and found it helpful to look at FileMaker from the perspective of general database theory. I also note that its excellent secure log-in files have been adapted and posted by users on this forum. Not sure whether that would please its authors . . . also, as has already been mentioned, the Rich Coulombre and Jonathan Price "Special Edition Using Filemaker Pro 5" is the only other FMP book that is worth its salt, imho. This book is geared more to the idiosyncrasies of FileMaker, and perhaps doesn't do attempt to do everything in accordance with true relational design, but is geared to finding workarounds for some of the more esoteric things you will want to do. It is also very entertainingly written and worth every penny. I can't comment on The Book of FileMaker 6" by Chris Kubica, because I haven't seen a copy yet, but on the whole I've been very disappointed with most FM books, including the FM Bible and the various Teach Yourself . . . guides for being little more than FM's own manual rewritten in a slightly different order.

In other words the field name itself is a field - a calculation . . . . does that help? But if we're talking about an unfixed number of results, I'm wondering if you'd be better off having your results show up in a portal - and in this way you'd get the number part for free - i.e. number of portal rows = number of results . . .

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.

If you were thinking of moving to OS X, then this might be a clincher. You can script the Print functions to Save As pdf and have FileMaker automatically attach these to an email.... JaseFace, are your sure the Adobe pdf printer driver can't be automated directly from FM (in Mac OS9)? Adobe pdf printer driver here: ftp://ftp.adobe.com/pub/adobe/printerdrivers/mac/8.x/plugins/pdfen.sea.hqx

If the files do not have a .fp5 suffix, you might want to add them on the Mac before opening them on Windows... also you may need to refix your print scripts, but apart from that, you should be OK.

The first 10 scripts are automatically assigned to the number keys (Command 1 to 0 on the Mac) It would be nice to involve the F Keys, and this may be possible with a plug-in, I'd guess. And now off your topic a little, but on key commands in general: I generally assign scripts to these keys (and by some strange coincidence it's the same order as the buttons I place across the top of my windows...) Command 1 - go to first record Command 2 - go to previous record Command 3 - go to next record Command 4 - go to last record Command 5 - New Record Command 6 - Edit Record Command 7 - Find Command 8 - Modify Find Command 9 - Show omitted Command 0 - Show All Obviously, you can do exactly what you want! I just offer my own personal 'standard' as something that is quite useful and almost universally applicable... If a function is not available of a particular layout, I either show a message or leave the key command unassigned. The worst thing I could imagine is having a key command do one thing on one layout and another on another - but then it is a Windows world .... ;-)

It's a little difficult to know exactly what you're doing but I think a portal is probably going to work for you. A portal will automatically display a list of all records which meet criteria (according to the 'relationship' you specify) e.g.. everyone who worked a certain shift, or who was absent, etc.

This will be one worth getting http://www.amazon.co.uk/exec/obidos/ASIN/0789730286/qid=1063064880/sr=1-32/ref=sr_1_0_32/202-4300346-9811851

I think the best 'wow' comes from the quality of your printouts, and the ergonomics of the database in day to day use. Built-in help and unambiguous functionality. Sometimes a little frivolity like a Tip For The Day can be fun, but please let the user turn them off! As far as the appearance is concerned, I personally recommend staying as close as possible to the OS functionality and layout. This minimizes the learning curve and also makes your database look like a proper shipping application. In practice, this means tabbed displays - which work well for navigation, buttons that look like buttons, and dialogue boxes in plain English - or whatever your native tongue happens to be - but not in FileMaker dev-speak. This means intercepting many of FileMaker's own generic dialogues and error messages, and replacing them with something more easily understandable to the user, and specific to what they actually did to invoke the message. Steal graphics and dialogues from the OS, conform to the user's expectations, don't confound them. Yellow buttons on blue backgrounds might look fun this week, but they're more than likely next week's headache. FileMaker themselves have gone for an Aqua-esque look in their recent templates, but I seriously question the current fashion for light-grey text on an only slightly lighter background. Apple's guidelines on UI are probably worth a read as they inevitably (eventually) apply to Windows too. If you're stuck, you could always post one of your layouts and see what people come up with...

Stored calc's?

I was quite disturbed to hear the advice given in the MacAcademy/Windows Academy FMP 6.0 CD ROM tutorial: use a Windows box for FM development. The reason given that FM Win apparently can't natively read some Mac graphics formats (true) and attempting to do so will corrupt the FM file. (I don't know about this???) Doesn't 'Store Compatible Graphics' resolve these issues? Anyway, worrying advice from a company that has the Mac market to thank for its survival thus far. Worse, if it happens to be true. (I've seen Win XP, and the gaudy blue, and out-of-place buttons remind me of a FM layout done by someone with no interest in aesthetics. I'm currently developing on Mac OS X, and that's where I want to stay.

Am I safe using dates in 11/8/03 text format when using these dates as part of a key to relate to other files? Is it robust? I feel a bit uncomfortable about it, and wonder whether it would be better to convert it to a number (as FileMaker does when the field calculation result is set to Number.) Am I worrying needlessly? Thanks!

Hello everyone. It took a while. (Like 2 years) but I finally found you all. And what a great forum! A wealth of information and resources. So we've only just met and already I'm on the scrounge . . . I'm probably the messiest FM developer in the world. I try a script. I try it another way. I think of something different, and try it another way. Now I have 5 versions. Then I come at it from a different angle, try to use some Status function I haven't used before. Try that 5 ways. In half a dozen different relationships. And that's just breakfast. OK. You may say this reflects a lack of forward planning. Maybe true. All right, it is true. However, along the way I have managed to stumble across things I never would have been able to actually work out in my somewhat over-taxed brain. Maybe. Cut to the chase. This database I've been working on, off an on, on and off, for a couple of years, is just about ready to go. Problem is I have 240 fields, 30 relationships, and close to 200 scripts in just one of the files. I'd estimate only a third is actually being used. And it's a total nightmare trying to work out which. Also some fields are just begging to be more eloquently renamed, but may be being referenced by some Status function, or used by some Script . . . and of course FM doesn't inform you of that. Is there any simple easy way to tell which fields/scripts/relationships are unused (including by related files)?? Does the Developer version do this? In Cubase you can 'purge unused audio' which is a great function . . . and almost entirely irrelevant. Thanks!