John Sindelar

  • Content count

  • Joined

  • Last visited

  • Days Won


John Sindelar last won the day on September 18 2016

John Sindelar had the most liked content!

Community Reputation

3 Neutral

About John Sindelar

  • Rank
  • Birthday

Profile Information

  • Gender
  • Location
    Seattle, WA

Contact Methods

  • Website URL

FIleMaker Profile

  • FM Application
    14 Advanced
  • Platform
    Cross Platform
  • Skill Level
  • Certification
  • Membership
    FileMaker Business Alliance
    FIleMaker Platinum Member
  1. Help us empower FileMaker developers to build great things. Interested to hear from beginners through intermediate developers. Details here: Thanks. - John
  2. All SeedCode add-ons and templates are on sale for 25% off throughDec 31st. And upgrades are on sale for up to 25% off. The Award-Winning DayBack Calendar The sale includes DayBack Calendar which just got gantt charts and support for cascading date changes ( <-- very cool video). SeedCode Complete Starter Solution Complete is also on sale and now includes a tightly integrated version of DayBack Calendar so balancing your workload is even easier. Balance your workload and make your FileMaker development go a little faster in the new year by getting a head start at a great price.
  3. New In-App Update for DayBack Calendar

    We just posted a new update of DayBack with a sweet little enhancement to the Resources tab: you can now change the number of resource columns on the fly. This short movie shows how that works and how to download the update into your copy of the calendar. If you’re new to DayBack, learn more [...] The post New In-App Update for DayBack Calendar appeared first on SeedCode.
  4. Speed Up ProMaps on Windows – A Simple Mod

    Folks using ProMaps on Windows may be seeing slower performance on some versions of Internet Explorer. Fortunately there is a super-easy mod to speed up the map on these Windows machines. A huge thanks to JohnAustin Lamprecht of Soliant for finding this! Instructions for making this change in your copy of ProMaps follow: (If you’re new to ProMaps you can learn more about this add-on here: ProMaps for FileMaker.) The post Speed Up ProMaps on Windows – A Simple Mod appeared first on SeedCode. Source
  5. Update: What’s New In DayBack Calendar 9.41

    We’ve just released a new free update to DayBack Calendar. This version adds a couple of hooks (new FileMaker scripts) so you can go to an event from outside the calendar; check out how it works in the movie below. We’ve also fixed some bugs and paved the way for a couple of future features. The movie offers a short overview of what’s new along with how to find instructions for updating your copy of the calendar. If you’re new to DayBack, you can learn more about the calendar, and download a 30-day trial here: DayBack Calendar for FileMaker. Enjoy! (A detailed list of changes in this update can be found here.) The post Update: What’s New In DayBack Calendar 9.41 appeared first on SeedCode. Source
  6. Design Patterns: “Cards” in SeedCode Complete

    SeedCode Complete 13 Our newest version of SeedCode Complete has been out for about 3 months and we’ve now had an opportunity to see how people are using and modifying it for themselves and their customers. Happily, one of our customers’ favorite design patterns is the one I’m personally the proudest of: we think of them as “Cards”. It’s essentially an updated take on the Selection Portal or Master Detail design patterns you may have seen. However, the new UI elements introduced in FileMaker 13 (Pop-Overs and Sliders), combined with the new Selector-Connector data model, really make Cards shine in Complete. The Contact Card In designing Complete We wanted to make the design patterns consistent throughout the entire solution. For example, when looking at a Contact–whether on the Contact layout or as a related contact on another layout–we wanted that presentation to be the same. The pattern we established in the main Contact layout would therefore be replicated throughout the solution so users could always recognize the interface for “Contacts”. Before FileMaker 13, this would be a challenge because there would typically not be enough real estate to show detailed Contact information in other contexts–on a Project layout, for example–without intruding on the Project information or seeming out of place. With 13, pop-overs and slide panels give us a lot more flexibility. For the Contact layout we now display the basic information of the Contact with their thumbnail. We then use pop-overs as an easy to drill down to more information like additional e-mails, etc. Since we use a modal edit mode, all these fields are clickable, resulting in the appropriate action, e.g. open address in Google Maps in browser, open e-mail with selected address, etc. Contact Layout. This upper left section of the Contact layout, shown in red above, now becomes the “Contact Card.” When looking at related contacts, our original thought would be to access these Cards with Pop-Overs, however, we wanted the additional e-mails, etc. to be included and you can’t put a pop-over in another pop-over! After some experimenting we came up with the pattern of “sliding” to the card using a slide panel. This actually turned out better than the pop-over, particularly on OSX and iOS where we have animation making this feel like a modern mobile app. You click on the portal, and the whole portal slides to reveal the detail of the clicked row, very much like clicking on a Contact in iOS. Contact Portal In Projects Clicking on the portal row slides the portal to reveal the “Card” Pop-Overs showing related info in Cards So now the user can “slide” to a Project Contact, access a summary of their information, send them an e-mail, or look up their address. If more Contact information is needed, or an edit needs to be made, then one more click takes you to the actual Contact record. It really smooths out the users’ navigation experience to have the Card as an intermediary between the current layout and the related records anchor layout. The Selector-Connector Pattern As pleased as we are about the Card design, we’re even more pleased about the way it was implemented. By using the Selector-Connector model, the Cards are all in the same context, so we can literally paste them from layout to layout and not have to change their fields to work in the new context. When we slide to a card, all we need to do is to set the Global Contact ID in the Selector table occurrence. If our “Card’s” fields all reference the SelectedContact table occurrence then they will work from any of our anchor layouts! This means when our customers need to add a Contact Card to a layout, they can copy it from any other instance of the card, and if the new layout is set up with the Selector-Connector pattern, they can paste the Card layout objects in without modification. The Selector and SelectedContact Table Occurrences in Complete For more on the Selector-Connector model check out our original article as well as this post from our friend and colleague Todd Geist. Best of Both Worlds It can be challenging to build something that gives the user a great experience, while making that same pattern easy for developers to carry into their own additions to SeedCode Complete. We love this Card pattern and probably would have implemented it even without Selector-Connector, but being able to provide it AND make it easy to work with has been very gratifying! The post Design Patterns: “Cards” in SeedCode Complete appeared first on SeedCode. Source
  7. Mods: Multi-Point Google Maps

    We’ve recently seen some great examples of modding multi-point Google Maps in FileMaker Layouts. Here are two very slick mods based on our ProMaps template… Filtering (and Color Coding) Based on Found Sets. This first mod was done by Lisette Wilson of Informing Designs; she’s linked ProMaps to SeedCode Calendar so that the contents of the map change as users navigate the calendar. That alone is pretty cool, but she’s also letting users change the way the appointments on the map are color coded. In the first screenshot they’re color coding by the customer’s tank capacity: While in this one they’re color coding by the day of the week the appointment is scheduled for. This lets users scan their map for appointments that are physically close to each other but aren’t scheduled for the same day: Note that the pins also have the trick number assigned to that job (or “U” if a truck hasn’t been assigned yet). Lisette is using the Google Charts API to create those pins on the fly since there could be any combination of pin color and truck number. Very cool trick. For more information about this kind of deep integration between maps and calendars, and other interesting mapping mods, please get in touch with Lisette. Creating a Found Set by Circling Pins on the Map The mod below was done by David McCulloch and represents a really cool workflow. He looks at his customers on the map–having filtered them down by zone and account type–and then draws a polygon around the ones he’s interested in. His scripts then gather the selected pins into a found set to which he assigns a sales rep and a date to visit them (in step “3” of the screenshot below). While we added the polygon thing to ProMaps for him, David did the rest of the scripting here and has embedded little maps like this all over his solution to help his users keep their customers in context. Really nice work. If you’re interested in adding drawing tools like this to the multi-point Google maps in ProMaps for FileMaker, please let us know. More Inspiration: Beautiful Icons for your Maps If you’re building your own maps, or making your own mods to our ProMaps template, you’ll want to check out these map icons from Nicolas Mollet has been maintaining a great resource of free map icons but his site is currently down for maintenance (?). We hope it comes back soon but you can see the kinds of icons he offers in another one of our customers mods here. Enjoy! The post Mods: Multi-Point Google Maps appeared first on SeedCode. Source
  8. A Custom Sidebar for DayBack Calendar

    Adding a FileMaker Portal next to DayBack’s WebViewer Recently Arie Covrigaru of PlanOmatic ( ) hired us to add some custom features to his DayBack calendar. His main request was to be able to filter the calendar by resource(s) by selecting from a searchable, scrolling list. And he wanted that in the main calendar window, beside his calendar, not in the “advanced filters” popup window where this is usually done. The solution was to nudge the webviewer object 300 pixels to the right to make room for a tab-control object with a filtered portal on each tab. The new sidebar in layout mode. Arie’s resources are photographers, and each is associated with a “service area” (geographical location). The first tab in the side bar shows all the service areas, with a “search” field at the top to filter the portal. To filter the calendar by one or more resources, you can manually select them from the “Photogs” list, or you can click on a service area to select all photographers in that service area. Browsing services areas and the number of photographers in each. The custom sidebar has been styled to match the stock DayBack webviewer sidebar, which is hidden by default. The “Delivery” tab behaves the same as the “Status Filters” tab on the stock sidebar. Photographers for the selected service area. Arie loves it! If you’re interested in mods like this, get in touch or purchase one of our implementation packages. The post A Custom Sidebar for DayBack Calendar appeared first on SeedCode. Source
  9. FileMaker Data Modeling with Selector Connector

    Overview The Selector-Connector is a data model for organizing your FileMaker table occurrence graph. It is something we’ve been loosely collaborating on with our friend and colleague Todd Geist. I say loosely, because during the evolution of the model, we never really reviewed each others work, but talked in very general terms about our progress. The fact that we ended up with something so functionally similar makes me think that we’re actually onto something! Todd has a great post and video on his approach here. The new SeedCode Complete Template We’re also using Selector-Connector as the data model for the new SeedCode Complete and it is one of the primary reasons we feel Complete is working so well; seeing how Selector-Connector is letting folks extend and modify Complete also tells us this approach is being validated. The most important thing to me about the Selector-Connector model is that the techniques themselves are not new new at all. It uses powerful, native techniques that have been around since FileMaker 7–like global keys and cross-joins–but it organizes them as a pattern that we can describe, much like we can describe the Anchor-Buoy pattern. FileMaker Data Models: Extending Anchor-Buoy The Selector-Connector should be seen as an extension of the currently predominant data model, Anchor-Buoy. Anchor-Buoy is arguably the most widely adopted FileMaker standard in the development community, and there are two very good reasons for that. It organizes the graph very clearly with a small set of rules It has a great name that is very visually descriptive. We want to make sure we don’t lose either of those things if we’re going to tinker with the model. In general terms, Selector-Connector keeps the current Anchor-Buoy model but builds “on top of it.” We’re just going to “bend” its rules a little bit. A very basic interpretation of the Anchor-Buoy rules would be: All layouts must reference Anchor Table Occurrences Interacting with Buoys is only done from the context of their Anchor Anchor Table Occurrences cannot be related to each other. By sticking to these rules, the Anchor-Buoy model forces us to be aware of context and it also limits the chance of us doing an operation out of context, like picking the wrong table occurrence for a portal; very important things in FileMaker and generally these benefits have outweighed the draw-backs of Anchor-Buoy, and that’s why it’s the standard. Typical Anchor-Buoy model in action The Pop-Over Cometh As I mentioned above, there’s nothing technically new to the Selector-Connector model. So what changed to start us down this road? For me, it was the introduction of the Pop-Over in FileMaker 13. Here was a great new object that would be a light weight alternative to pop-up windows and dialogs. It would be great for picking records from a portal, and for editing and creating records. And, using the new slide panels, selecting, creating, and editing, could be done all in one place! FileMaker Inc. seemed to have a similar thing in mind as the demo files that came with 13 had a nice example of this “all in one place” behavior: bring up a pop-over with a portal and filter for the record you’re looking for. If you can’t find it, then hit new and “slide” to a new record form right in the same pop-over…very slick! We were starting to work on the new SeedCode Complete and I saw a great design pattern taking shape. A simple Pop-Over with Picker Panel and then a New Contact Panel However, when I started exploring this, I realized (obviously) that these pop-overs would have to be done as single purpose objects: even though both Projects and Invoices would need to pick Contacts, I wouldn’t be able to use the same pop-over as it would be bound to the context of the Project or Invoice layout. Even if I was using a virtual list for my Contact Picker, the portals would each still need their own buoys attached to Projects and Invoices. This suddenly seemed like madness, and I was determined to find a way to copy and paste my pop-overs from Anchor to Anchor and have them work with very little modification. Universal Context If we wanted the pop-overs to work universally, then there was no way around it, we would need to have a context for them to work in, and the idea of Universal Context was born. For a long time, Todd and I were both using this description of the model as the Selector itself hadn’t taken form. Here’s a representation of our first pass. Early Connector Model, aka Universal Context Model We decided to “compromise” on the Anchor-Buoy rule of Anchors being related to each other. We still don’t want them directly related to each other, or even interacting directly with each other. However, we do want them all to be able to access the Universal Context table occurrences of Home and Virtual List Rows. This way, any Anchor layout can all use the same portal on our Pop-Over Selector. Not only can they use the same portal, but the scripts that reference the portal can also be generic: and we’re a little closer to having the portable pop-over we’re after! What about Record Locking? The idea of the above graph is that I can set the RowsToShowGlob global field in Home and control the contents of my virtual list (setting a list of contacts to select from, for example). But what if another user is trying to do the same thing? This isn’t a Session Model, and we don’t want to have to manage multiple records in Home to prevent record locking, so how can we get around that? It turns out that if the Home table only has global fields in it, you’ve, in essence, made it a global table that multiple people can interact with without locking. This was really a critical milestone in the process. By having a central/single TO that we could connect through, we could enforce a similar, although slightly looser, model as Anchor-Buoy. Create From Anywhere The model above solved my problem of being able to use a Contact Picker Pop-Over from any of my layouts, but I also wanted to be able to create new contacts right from my pop-over. Since we’ve already extended the Anchor-Buoy model for our Virtual List, we’ll extend it a little bit further and create a dedicated TO for contact creation. So now you’ll see a table occcurence called CreateContacts hanging off our Home table occurrence below. Adding a Table Occurrence for creating contacts We can create new Contacts through this relationship. If the relationship between Home and CreateContacts is a creation relationship and the ContactIdGlob in home is empty, we can create a new Contact simply by typing into a field in the CreateContacts table occurrence. The Contact id is an auto-generate field and this value for the new record will be pushed back into the global. This behavior may seem a little strange, but has existed for as long as I can remember in FileMaker and is referred to as the “pop-back” or “magic key.” For us it allows us to create a new Contact from anywhere by creating a temporary “parent” in Home, and we no longer need to go to a Contact layout to do this. We can use our Pop-Over Contact Picker on any layout to both pick and create contacts! Problem Solved and our graph is not a mess. The Selector Soon after we got this part working, we began to realize that there was more we could do with this model. If we’re using this Universal Context to create records from anywhere, then we can also very easily use this same model to view and edit records from anywhere. Master Detail or Selection Portals are very common in FileMaker, and we soon realized that the Universal Context would work great for them. Typically an Anchor would need two Buoys to a related table to do a proper Master Detail view. Normally we’d click on a portal row of our first Buoy to get the id of the record we clicked. We would then set that id to a global to set up a relationship to the second Buoy where we would see additional data about the selected record. With Selector-Connector we can now set that global in our central Home Table Occurrence and use the relationship to CreateContact for our detail view. This means we can get rid of that second Buoy for the detail, and more importantly, any Anchor that wants to see Contact details can use that same Table Occurrence. This is really the birth of the Selector. The central table is now no longer called Home, but the “Selector”. The table occurrences to its right are the “Selected”, and they’re also the relationships that let us create new records. We’ve now consolidated, pickers, creation and master-detail into a single “component” of the graph instead of a bunch of similar Buoys attached to each of your Anchors. The Selector Model Takes Shape The Connector As we started working with this new model, there was this great sense of relief that we weren’t “fighting” with FileMaker like we have in the past. Context and Layouts were still tied to the Anchors, and it was living up to the promise of being the best of both worlds! In addition, we started to see some residual benefits. For one, since most of the global keys were being moved to the Selector, we didn’t need them in actual data tables anymore. In SeedCode Complete, we were able to remove virtually all global fields from our the data tables. This keeps them much easier to work with, particularly if integrating with another data source or doing imports as you don’t need to wade through all the globals. This led to the idea of the Connector. For me, the Connector is about modeling the graph to not just symbolize what’s a layout and what isn’t, but the different logical components of the graph. Initially we were thinking we had just two components, the Anchor-Buoy component and the Selector component, but once you adopt that model, it can be taken a little further. Really, the Selector is different than the Virtual List, so we decided to make our graph represent that. We also now have a place where we can keep indexed values available to all Anchors as well. Things like settings or graphics can also be cross-joined to our central Connector and accessed from anywhere. These things working together is the full Selector-Connector model. The Selector Connector In conclusion, I’d like to remind you of this great Picasso quote my mother recited to me for as long as I can remember, and how I think it applies here. “Learn the rules like a pro, so you can break them like an artist.” -Pablo Picasso After going through this exercise, I believe that Anchor Buoy was not necessarily what the developers of the graph had in mind, but it was an absolutely critical step in our collective development. The idea of approaching something like the Selector-Connector without a complete and thorough understanding of FileMaker Context would be daunting and probably fruitless. The only reason we can use, or even talk about, a model like this is because of what Anchor-Buoy has taught us, and I want to re-emphasize the idea that the Selector-Connector (as I see it) is an extension and/or continuation of Anchor-Buoy. We’ve worked hard to learn and honor its rules, so we might be ready for a little artistry. The post FileMaker Data Modeling with Selector Connector appeared first on SeedCode. Source
  10. Mapping Found Sets

    ProMaps, our Google Maps add-on for FileMaker, lets you use filters to constrain which locations show up in the map. But sometimes you want to go beyond filters and show the results of an ad hoc find request. Using the new List Of function in FileMaker 13 this is now a simple mod and we’ve written up instructions to add this to your copy of ProMaps. Learn more about ProMaps and checkout some movies of it in action here: ProMaps for FileMaker The post Mapping Found Sets appeared first on SeedCode. Source
  11. This is the beginning of a new, open source project to create a lightweight wrapper for FileMaker Custom Web Publishing designed for use in JavaScript applications. Background: DayBack DayBack running in a FileMaker layout. The release of DayBack for FileMaker last month has started a very exciting time for us here at SeedCode! Bringing the Calendar to a new code base and seeing it successfully deployed in the real world has been nothing short of thrilling. We’ve recently added mobile support and are looking forward to the future enhancements of DayBack for Pro and Go. However, now that we have this great JavaScript code base, it’s time to get going on DayBack for the browser, and starting with FileMaker Server as our first data source is the logical next step. Assumptions One of the goals for DayBack is to do as much of the data work as we can in JavaScript. This is based on two big assumptions, and seeing how these bare out will be an interesting part of this project: FileMaker Server is a powerful tool, and it can do a lot. However, this ability to multi-task tends to lead to deployments where it’s simply trying to do too much. On the web publishing side things like portals on target layouts, server side scripting, huge data sets, etc. often put a considerable load on the server. Can we architect DayBack to do this kind of work in the browser and therefore put a lighter load on our FileMaker Server? Supporting server side processes requires a different level and type of support than client side ones. This is not just the case for FileMaker Server, but any server based application. Supporting the server often requires working on a specific machine with specific issues that extend well beyond your app, web servers, permissions, program versions, etc. can all affect how things run. By minimizing our server side footprint we hope to minimize the need for this kind of support. fmxj.js With these assumption in mind we’ve built a preliminary JavaScript library for building and posting queries to FileMaker Server and converting the results to JavaScript objects in a JSON format. We have some working demos here. We’ve also decided to make this part of the project open source (MIT License), so you can download (or fork) the library and demos from GitHub for free! fmxj.js – working examples Here is what fmxj lets you accomplish: Build complex queries and perform HTPP POSTs to your FileMaker Server. Return FileMaker parent and child records as JavaScript Objects/JSON. Create, edit and delete FileMaker records with JavaScript objects. Filter and sort Javascript objects locally with complex criteria. Query strings are created from JavaScript Objects and then sent as an HTTP POST to FileMaker’s XML Web Publishing Engine. An XML FMPXMLRESULT is returned and converted into JavaScript Objects/JSON by fmxj. HTTP POSTS can be done directly to the FileMaker Server’s XML WPE or a simple PHP relay can be used to get around cross-domain issues and provide more authentication options. As always, we love to take any opportunity we have to share our code, and I’m personally looking forward to keeping you posted on our progress. Cheers! Follow @seedcode The post A JavaScript Approach to FileMaker Custom Web Publishing appeared first on SeedCode. Source
  12. Sudoku for FileMaker

    Travis Spangle has posted a great example file showing Sudoku in FileMaker. It includes a couple example screens for those of us who didn’t grow up playing Brain Age (guilty). Dowload the unlocked file here: filemaker-sudoku. Thanks for this, Travis! Travis is a member of FileMaker Seattle where he’s also presented some great stuff comparing the speed trade-off of different architectures in his reporting solutions. If you’re in Seattle, our next meeting is this Tuesday where Cosma from will be speaking about deployment options on Amazon Web Services. Feel free to stop in. The post Sudoku for FileMaker appeared first on SeedCode. Source
  13. Coming full circle with JavaScript and SQLexplorer Having the opportunity to work on a project like SQLExplorer has been a highpoint in my FileMaker career. It was a great way to participate in the collective learning of the ExecuteSQL function by the community when it first hit the scene. But, it’s also been a great way to get a handle on the increasingly popular interaction of FileMaker Pro and JavaScript. The Idea: JavaScript Portals for FileMaker SQLexplorer has always displayed your query results in a “JavaScript Portal” in a web viewer , and this was born from a pretty simple requirement. Since you can choose different columns for your SQL query, having pre-formatted fields in a traditional portal often didn’t “look right.” We thought that with a “simple” JavaScript grid we’d be able to dynamically set column widths as well as apply some basic formatting, i.e. text floats left and numbers float right. We settled on using jQuery and the jQGrid plug-in for this. They’re easy to set up, and being able to use Theme Roller provided us an easy way to keep the “portal”‘s theme matching the layout’s theme. With this, we were able to get a great looking grid that not only met are original requirements, but also had some great additional features that came with the jQGrid plug-in; notably, column sorting, changing the column order via drag and drop and a filtering tool. The end result ended up very polished, and to our great delight, several developers have re-engineered this technique for their own solutions. The Limitation As exciting as the JavaScript portal was, it made the limitations glaringly obvious. At this point in history, the FMP URL protocol was new (a byproduct of FMGo) and we didn’t have the ability to initiate action from our web viewer on local files. For SQLExplorer, this was OK: it was designed to display data, and it did that beautifully. However, for the developer trying to take this technique to the next level in a production FileMaker solution, this limitation made the portal pretty limited. This all changed when FileMaker 13v2 came out, which gave us consistent behavior for the FMP URL protocol across all deployments. Now we could write our JavaScript so it can actually fire FileMaker scripts, and we’ve seen an increasing number of web viewer based solutions hitting the scene. New SQLexplorer With this in mind, we decided to revisit SQLExplorer and release a version that demonstrates firing a script from the jQGrid plug-in, so hopefully folks will be able to take this technique to the next level. onSelectRow Event This actually turned out to be a pretty easy modification, because in the original JavaScript I had set up on onSelectRow event in the jQGrid plug-in. I had done this simply to give the ability to deselect/unhighlight a row. The natural jQGrid behavior is for a row to highlight when you click it, and stay highlighted until you click another row. I ALWAYS write my FileMaker routines to deselect/unhighlight the row if you click it again, and it was bugging me that the jQGrid wasn’t doing this, so I added: onSelectRow: function (id, status, e) { if(status===false){ $("#list4").jqGrid('resetSelection');} } to the Configure jQGrid script, which is the API for the jQGrid settings. This is a simple event that simply checks if the current row is selected, and if so, we reset it. With this in place I just needed to add some code for my script. I left my deselection in place, but if you are selecting, we add: onSelectRow: function (id, status, e) { if(status===false){ $("#list4").jqGrid('resetSelection');} } else{ var firstColumn = $(this).getCell(id,0); var p = encodeURIComponent(firstColumn); var url = "fmp://$/"&Get(FileName)&script=RowOnClick&param=" + p window.location = url; } } The id represents the row id and is passed from the event itself, you can then use the jQGrid method .getCell(rowId,columnIndex) to get the contents of a particular column/cell. Remember, JavaScript uses 0 based indexing, so a column index of 0 is the first column. Once we have that value, we encode it and create a url that will call a script with our cell value as the parameter. Once we have that url, we just call it using window.location. The script itself is just a simple dialog that shows the parameter, but once you’ve got the circle completing in a script, the possibilities are endless. It’s important to note that onSelectRow is just one of many trigger events set up in the jQGrid plug-in, so this basic model can extend to all sorts of different triggers. Check out the jQGrid docs on this to see all it can do. But I Need the ID! It’s great to be able to pass the information in a row column back to FileMaker, but is FileMaker going to be able to do anything with it? My JavaScript portal doesn’t show the primary key, just the data I want to show, so returning the first column doesn’t really do me any good! What I need is the primary key, but I don’t want to show that in the portal. What we came up with is an option to “Hide The First Column” checkbox in the query, so you can add a column with your id to the “front” so you can reference it, but not see it. We’re already dynamically defining the columns in the script Test Query, so we just added a little routine to see if we’re the first column, and if we are and the checkbox is checked, the first column will have it’s hidden property set to True. Then you can set the id as the first column and return it to your script without messing up your display. First column with the id is hidden, but can be referenced by jQGrid. And that’s it! We hope you’ll take some time to download the newest version of SQLExplorer and that it will be a useful tool for not just continuing to strengthen your SQL chops, but your JavaScript ones too! The post JavaScript Portals for FileMaker: Clicking on Rows appeared first on SeedCode. Source
  14. FileMaker Templates On Sale

    SeedCode’s year-end sale continues through Dec 31st. And we’re thrilled to have finished both the new SeedCode Complete template and the new calendar, DayBack, in time for the sale: the last mile of shipping a product–the wish-list features, sample data, and documentation–can seem to stretch on forever. We’ve rarely taken so long to work on a new release, but they’re done! So now you can save up to 25% off on upgrades to our newest calendar, on GoZync and additional GoZync licenses, and on upgrades to the new SeedCode Complete template for FileMaker 13 and WebDirect. In fact, all products are on sale, so grab something to make your development easier. Get in touch with questions; we’re here to help. =) The post FileMaker Templates On Sale appeared first on SeedCode. Source
  15. Printing PDFs in FileMaker WebDirect

    FileMaker’s WebDirect offers some exciting deployment opportunities. However, not being able to create PDFs or print like we can with Pro and Go is a big limitation. For many of us, an invoice may exist in a database, but until it’s represented as a printable document, it’s just not a real invoice. Finding a solution to this for the new SeedCode Complete was a high priority for us. We looked at some plug-ins out there that allow FileMaker Server to generate PDFs: MonkeyBread and 360Works’ Scribe are two that come to mind. These work fine, but Filemaker Server is headless; this means it can’t read layouts like the client can as far as object positions, etc. so these PDFs made by these plugins can’t be based on FileMaker layouts like we’re used to doing in Pro. We’d need to have the server use templates independent from FileMaker layouts to create these PDFs. Our friend and colleague John Renfrew has been doing some very impressive work bridging this gap between server PDF generation and FileMaker layouts. We’re looking forward to the final results of his work here, set to be released early 2015 as we think basing PDFs on FileMaker layouts is an important part of the platform for all deployments. For SeedCode Complete, we’re recommending that folks go with the tried and true approach of setting up robot station of FileMaker Pro to generate the PDFs for the WebDirect clients. In the past we could have done this with a plug-in or have the station run on a continuous loop looking for PDF requests coming from WebDirect clients and generating them as needed, but this year at DevCon (2014) we learned of a great technique from the folks at ClickWorks, so the robot client can do this natively with no continuous loops. The general idea is that by deleting a record (something I can do from WebDirect), I will change a found set on another client’s machine, which in turn causes the OnRecordLoad script trigger to fire! Basically I can trigger a script on another client natively. Here’s the ClickWorks blog post on this really clever technique.! And here’s a video of the SeedCode Complete PDF Robot in action. The post Printing PDFs in FileMaker WebDirect appeared first on SeedCode. Source