Toby B

We are looking for multiple developers of varying degrees of experience to join our expanding team working on a large and complex inhouse database. So if you know a little or a lot about filemaker please contact me via this post and we can discuss it further. P.S. These positions are for onsite developers only ... unfortunately we can not accommodate remote developers on the projects at hand.

Hi Lee, The reason I did not post a valid email string up on the web is because spam crawlers would be able to extract my email and start sending me spam. I formatted my email address the way I did because only humans can read it as an email address. Would you mind removing your post so that my inbox doesn't start to get hundreds of emails asking me to increase the size of my manhood or send money to Nigeria? Thanks.

We are looking for genius Filemaker Developers to join a small team of other genius developers for a specific project. You should apply if, your past experience has forged you into an evangelist of such development methodologies as the Data-Separation model, anchor-buoy relational mapping, strict naming conventions, and in-code documentation. You should be familiar with the Filemaker Development Standards Document, and have fully embraced many of the modern features released over recent revisions of the software like Triggers, Custom Functions, Custom Formatting and Local/Global Variables. You should be able to work within an open team environment, where you are willing to share and learn from others. You should see the value and expediency in sourcing solutions to problems faced during development, through online communities like this one FMForums and others like BrianDunning.com, Matt Petrowsky's FilemakerMagazine.com, SixFriedRice.com, and SeedCode.com to name just a few. However you should also be able to take ownership of a task and work autonomously when required. We are also looking for people with a sense of style when it comes to User Interface design … we are not happy to settle for the aesthetics of a 80's windows application. Essential Skills: • Filemaker 10 • Normalised Data Modelling • Data Separation Method • Anchor-Bouy Relational Mapping • XML • XSLT • Mac OS X Desirable Skills: • Adobe CS4 Suite • Applescript • Experience in the Publishing Industry Bonus Skills: • PHP • CSS We would prefer to find on-site developers, but will be willing to consider remote development for the right candidate. If this sounds like you … please send us you CV along with your expected hourly rate. Please send all correspondence to tbeedell [at] localdirectories [dot] com [dot] au

Just to set the story straight ... Comment is right ... there are three tables ... my Filters table (which is the layout context) "Parent", looking at my Timesheets Table "Child" through a portal which in turn had related Timesheet Items "Grand-children". The sum of the Items determined if the Timesheet was complete or not. Therefore was an unstored calc. If you wanted to see just those Timesheets that are not complete you need some way to filter the timesheets based on this calc. Ugo's Method worked perfectly. Thanks Comment for pointing out another way of approaching it ... and thanks also to Ugo for coming up with it. I now simply have a calc in the Timesheet Table that checks to see if the sum total of its Items equal or exceed the weekly quota, and if so, result in the primary key of the record. I then in the Filters table have another calc that List all the values from the Timesheet calc and relate this back to the Primary Key of the Timesheet table to form my relationship. Quite simple in the end. Thanks again ... Comment

I have a portal that can be filtered. Outside of this portal on the same layout I have three fields: Record Number, Found Set, and Total Records. So far I can calculate the last two numbers but can not work out how to calculate the first. Basically when a user clicks on a portal row I want the record number field to instantly display which record number in the found set is currently selected. I do not want to do this by attaching a script to the portal row because there are already other buttons in the portal row (namely GTRR) attached to certain icons. Does anyone know of a simple way to achieve this?

Delta Tango, Thanks for your reply. I was under the impression that a Let statement offers the same "triggering" functionality that the "Evaluate" function does. So I think that would be doubling up or swapping one orange for another. Comment, I thought this topic might have raised a response from you. I have seen some of your other posts regarding this very issue and thought that some clever developer might of stumbled onto a method that was unintentional. I saw that Matt Petrowsky published an article regarding using the web viewer to constantly evaluate a statement ... but he was still having to use zippScript to fire off a script. I'll look into "Ugo's Method" thanks for the tip. Toby

I imagine this is an age old problem that every FM developer has hit their heads against at some point since the beginning ... but I thought maybe some of the more "brainy" amongst us might have discovered a workaround to the limitations filemaker has provided us with its "out-of-the-box" set of tools. Let me preface this discussion by saying I am aware that there are a range of Plug-ins out there that would solve this problem with little effort, but I am a purist and abstain from any temptation of an easy path that leads me to develop a solution that requires a third-party add-on, forcing me to ensure every client has the required software installed before for my DB functions properly, and in some situations you have no control over what the clients have installed. So can we agree not to suggest a plugin approach? My problem is this: I want a field in the current record (Parent Table) to evaluate it's auto-enter calculation whenever certain fields from one of the items in its portal (child table) is edited. To give you my example: I have a Timesheet (Parent) and its Timesheet Items (Child Table). I have a boolean field "_kaln__Flag_Complete" in the timesheet table. This field's purpose is to signify whether the sum of all the child items' time add up to or exceed a weekly required total. If so it's value is 1 otherwise the timesheet is incomplete and therefore gets a value of 0 (zero). I can do this with a calculated field, no problem, but I need this boolean field to be used as a right-side key in a relationship (the many side of a 1 to Many) that will allow managers to quickly filter a list of all timesheets to just those that are incomplete (ie. boolean filed = false). I have avoided trying to update the field via a script due to the fact that the user would then have to click a button for this script to execute and I can not assume the user will do this. So I have resorted to trying to utilize the Auto-Enter calculation. My Auto-Enter calc utilizes a Let statement combined with references to the related child fields and the Get ( ActiveFieldName ) function ... a trick learned from examples provided by Mikhail Edoshin. But I can not get the Auto-Enter to evaluate when the portal is edited. Does anyone have some tricks on getting the parent record to trigger the Auto-Enter calculation whenever one of the child records are altered?

I haven't received my FM9 box in the mail yet so I haven't had a chance to investigate properly but reading about the new features sparked an idea ... Will FM9 now allow us to use the contacts and address tables of MacOS X Server's Open Directory (LDAP) as an external data source? If so, would this then mean that we could use these LDAP tables in a separation model ... giving us a way to centralise all Contact data into a single repository that all office systems could integrate with. It exciting to think that any desktop app that uses the AddressBook services for contact info (ie. Mail, etc) would instantly have access to the same contacts data held in my FM DB without the need for additional plugins or third-party software. Has anyone had experience in implementing this sort of integration or can tell me if I'm just pipe-dreaming?

Just thought others might like to know about this BUG I came across. If you save a PDF of a Filemaker Layout that uses Postscript Type 1 or OpenType fonts you will most likely get unwanted character substitutions in the resulting PDF, even though the characters look fine on screen in either Browse or Preview modes. However if you only use TrueType fonts ... 99% of the time (depends on the font in question) the PDF will be generated correctly. I encountered this when trying to export a PDF that contained Bullet Points "•" (keystroke Opt-8 under MacOS). My bullet points were showing up as inch marks in the PDF. After running some tests on a range of different fonts I found that some fonts worked fine whilst others outputted the inch marks, and others still would output blank spaces. With some more investigation all the fonts that worked perfectly turned out to be TrueType fonts. None of the Postscript Type 1 or OpenType fonts worked. I have not tested whether printing directly to the PDF Distiller engine that comes with Acrobat Professional instead of using the PDF Library that Filemaker uses internally would fix this (I don't have a copy of Acrobat Pro) maybe somone out there could test this and reply to this topic with their findings. I would not be surprised if this indeed turns out to fix the issue as even Indesign's inbuilt "save as PDF" function (which I believe uses an embedded copy of the same PDF Lib licenced to Filemaker) creates "dirty" PDFs. By "dirty" I mean, it is not as good as printing to the Distiller engine when it comes to creating clean print production files.

Mark, Thanks for the link. Are you saying that sliding up based on "Only Directly Above" WILL or WILL NOT slide beyond the part boundary of the part the field is contained in? Do I need to trick it by placing the top edges of all the text boxes running down the left-hand side in the header part? Does this mean I need to create a calculation for each sidebar text block to work out how many paragraph returns need to be added in front to get them to line up in the correct spot. Does this also mean that I no longer need the first 4 leading sub-summary parts as the previous fields that used to be in them are now tied to the header part? Thanks for your assistance, Toby

I am not sure if this is possible but I am trying to achieve the layout in the Sample Invoice PDF attached. I have been trying to use the "Only Directly Above" sliding option but am not able to get my line items to move beyond the bottom of the text that sits on the left-hand side. I have put the Logo and the yellow text at the top into a Header part and then placed 5 leading sub summary parts below that ... one each for the blocks of text running down the left hand side plus the label strap lines that precede each block of line items. The line items are in their own body part with a trailing sub summary part that holds the sub-total / total fields and a footer part to hold the registered address details. Is this even possible to get the body to slide up past some of the leading sub-summary parts (in effect causing a sort of overlapping of parts). I have looked into turning on the 2 column option in the layout setup but this does not allow you to have uneven column widths. Also I have made sure my body fields are set to top and left text alignment so that sliding will work. BTW, any dotted lines you see in the PDF are handled by a container field as FM's line style options leave a lot to be desired. Any strategies or suggestions will be greatly appreciated. Toby ExampleInvoice.pdf

Stuart, I like your labour saving technique here but am just wondering why there are additional empty tab controls placed over the the right-hand ends of your "Label_" and "Tab_" tab controls? Is this to block a user accidentally clicking in the exact position of one of the 1 point tab labels and getting unintended UI changes? Toby

Thanks for the reply Mikhail, From what I have seen from Wendy and Colleen I am not meant to have anything in the interface file except Layouts and Scripts. However I am not using the value lists in this solution as I have opted to store these types of lists as tables in the data layer. The reason I am looking into this "Separation Model" is because I now have to deploy my "under-development" single file solution to the second client (two companies sharing a studio space split the cost of development) as they want what the other has been using for a month or so now. My ultimate goal here is to modularize the solution so that I can develop the remaining parts of solution whilst the clients are working on each of their slimmed down versions. I want to avoid having to do double the work (once for each of them). I really want to send the new interface file to both of them (and obviously pointing each one to the corresponding data file) and simply get them to replace their old one. I think I may need a second data file that holds my developer data that I never want the client to ever change or delete. This is another of my "ideals" ... try never to hard code something ... use a table instead. Toby

I'm sorry Vaughan but I am a little confused as to why I would have to perform an import cycle on my Logic layer. Are you referring to the "synchronisation" of the IDs with the data tables? I was planning on including that process in a startup script that may incorporate the List function and some custom functions I have seen that compare two lists adding any missing IDs to the logic table. My understanding was that I should be placing all data in the data layer, and that the logic layer should be there for derived data that I can write back into the data layer. This brings me to another point which is related to Unstored vs Stored calculations ... is it better in the long run if I try and avoid Unstored calcs at all costs and instead use the Evalute function in combination with a stored calc so that changes to the trigger fields will update the stored calc? Thanks for your advice, Toby

I just watch the two part series of video on ISO Filemaker Magazine's website that discusses the Separation Model. See link below: http://www.filemakermagazine.com/videos/the-separation-model-breaking-up-your-data-and-interface.html My question is ... is his advice still valid. In particular his warnings on the difficulties in displaying calculated data in portals? The only reason I am questioning it is because these video were released back in Oct 2004 which presumably meant he was talking about how difficult it was under v7. Has version 8.5 made his concerns redundant? I am considering using a three tier separation model ( Data / Logic / Interface ) due to the fact that I can more easily send an updated interface file to all my customers using the solution (ie. bug fixes, additional features, etc) and re-purpose / tailor the logic layer for each new customer if need be. All with out ever having to run an export/import cycle. From what I have researched on this topic I think I can combine the reporting layouts and derived data calculations into the logic layer. Which would make this the only customer-specific part of the entire solution. Does anyone who has seen his videos and has had experience in implementing separation-model solutions have an opinion? Toby