MightyData

FileMaker and WordPress Consultants

  • Company
    • About
    • Contact
    • Team
    • Artists
  • Services
    • Consulting
    • Development
    • Our Process
    • Coaching
    • Training
  • Results
    • Customers
    • Success Stories
    • Testimonials
  • Blog

The Price of FileMaker 13

April 29, 2014 by Kirk Bowman 61 Comments

The Price of FileMaker 13

In a recent post, The State of FileMaker 13, a couple of readers wrote comments expressing  frustration with the licensing costs of FileMaker 13, especially FileMaker Go. Since it seems to be a controversial topic, here are my thoughts.

The Price of FileMaker 13

A History Lesson

Before FileMaker Go, the FileMaker family consisted of FileMaker Pro (client) and FileMaker Server. FileMaker Pro was sold (and still is) by the number of installs, starting around $300 per computer. FileMaker Server was sold for a fixed price of  $1,000.

Then in 2010 (circa FileMaker Pro 11), FileMaker, Inc., (FMI) released FileMaker Go. It was originally two separate apps, one for the iPhone and another for the iPad. The price of the iPhone app was $20 and the iPad app was $40. Each app was a one-time purchase for unlimited use.

$20/$40 is considered expensive for apps in the App Store. Although there are other apps with premium prices, these prices did deter some customers from using FileMaker Go. It also made it challenging for companies to submit payment and then install the app on multiple devices through iTunes.

The Next Step

When FileMaker 12 was released, FMI made FileMaker Go 12 a free app. Anyone could download it from the App Store. This was a great marketing move because it removed two significant barriers:

  1. You did not have to pay for it to test it, and
  2. Anyone could and install it through the App Store.

During the FileMaker 12 product life cycle, customers got used to using FileMaker Go for free. In fact, if  your database was uploaded to a hosting provider, you could deploy a FileMaker solution to iOS devices for as little as $29/month. This was great for users because anyone could get up and running for almost nothing. And, it was good for FMI, for a while.

The market penetration that FMI received from making FileMaker Go 12 was good for the company and the community. However, if you know anything about pricing (one of my favorite topics), a penetration strategy is not financially stable indefinitely. At some point, the company must pivot and make a return on the investment (ROI). And that is what FMI did with FileMaker Go 13.

FileMaker Go Today

At the 2013 FileMaker Developer Conference, FMI showed a preview of the FileMaker 13 product line. Many of the new features were designed to help developers and users create more effective mobile solutions. There was also an “Under the Hood” where Dominique Goupil, president of FMI, suggested the licensing model for FileMaker 13 would evolve. Although he did not give specifics, it was a heads up that a change was coming.

When FileMaker 13 shipped, the licensing for FileMaker Pro (per install) and FileMaker Server (fixed price) remained the same. FileMaker Go remained a free app to download. So, users could continue to use it for a stand-alone solution at no cost. The change was the price to connect to FileMaker Server.

The new licensing model uses concurrent connections. If you have an average of 5 users connecting to FileMaker Server with FileMaker Go, then you need to purchase 5 connection licenses. If you have an average of 10, you need 10 licenses. The cost per  license starts at $180 per connection depending on the total number of licenses. If you need more connections, you can purchase them directly in the FileMaker Server admin console. (FMI is also using the same licensing model for WebDirect.)

Is It Fair?

This is the real question people are asking. On the surface, moving from paid to free, back to paid seems like bait-and-switch. However, you can also view it as FMI experimenting with how to price a new product. Think about your own business. How do you learn to price something? You experiment, or at least you should. FMI had to try different strategies to find the right one. Also, it is completely fair for FMI to recoup its investment in FileMaker Go.

If it is fair, then the next question is, “Does the new licensing model work for you?” First, realize there are a couple of different ways to buy licenses. The $180 per concurrent license is for a volume license (one-time fee). FMI also offers annual licensing which gives you the ability to pay a reduced price each year. The annual cost for a concurrent license starts at $60. If price is your objection, then consider annual licensing.

Second, what is the value you receive from using FileMaker Go? Does using your solution on the iPhone or iPad create more revenue than the cost of the volume or annual license? I would suggest you are probably making at least 10 times (or greater) the revenue vs. the cost. What is the benefit to your gross revenue, gross profit, cost savings, productivity, customer service, quality of life, etc., from your mobile solution? If you do the math, I think you will see things in a different light.

Do you agree or disagree? Do you think FMI is right or wrong with the pricing of FileMaker 13? You can leave a comment using the form below.

Filed Under: Pricing Tagged With: FileMaker 13, FileMaker Go, Licensing

The State of FileMaker 13

April 17, 2014 by Kirk Bowman 14 Comments

FileMaker Pro 13

If you are a customer or developer using FileMaker Pro, you probably know the latest version, FileMaker 13 was released in December 2013. I have not written about this release yet, because I wanted to reserve my comments until I had time to work with it. Now I have. So, what is the state of FileMaker 13?

FileMaker Pro 13

First, let’s talk about what FileMaker is at the core. It is a client-server database platform for making custom business applications. For years, FileMaker has had a desktop application (FMPro) and a server application (FMS). Then recently, FMI added an iOS application (FMGo). So, now the “client” part of client-server includes the iPhone and iPad.

Web Publishing

Of course, FileMaker also has a web publishing component in the server application. Instant Web Publishing (retired in FileMaker 13), was designed to help a FileMaker developer with minimal web experience create web access to a FileMaker solution. Custom Web Publishing was intended for the traditional web developer who knows HTML, CSS, PHP, etc. to create custom web apps for a FileMaker backend.

In FileMaker 13, Instant Web Publishing was replaced with WebDirect. WebDirect is intended to bring the desktop experience of FileMaker Pro to the browser. WebDirect is a new technology, a 1.0 release. In some ways, it is similar to when FileMaker Go released. It is a new type of “client” except it does not require installing any software because it runs in the browser. As with FMGo, will require some time to mature and for developers to figure out best practices.

Client-Server

So, where does this leave us? I go back to what I said earlier. FileMaker is a client-server database platform for making custom business applications. Currently it has two rock-solid clients, desktop (FMPro) and iOS (FMGo). You could also consider Custom Web Publishing a third client except that it requires development skills outside the normal FileMaker toolbox.

FileMaker is not a true SaaS application. It requires a client on the local device. You can put the server application on a cloud server (hosting provider, AWS, Rackspace, etc.). Then, if you have a well-designed solution, you can access the application “in the cloud” using the client on the local device. Is this a web-based app? No. But not every business needs one.

What is my point? Let’s be honest, and not ashamed, of what FileMaker really is and is not. Be honest with yourself and your customers about whether FileMaker is the right fit. If it is, use it. If it is not, have other options to offer the customer. Do not try to fit a square peg into a round hole. It is a disservice to the FileMaker platform and the customer.

Wrapping Up

Back to FileMaker 13, the latest advancements in the platform — including the layout theme/style engine, the new layout objects (popover and slide control), the improvement in iOS functionality, and the server enhancements like Perform Script on Server — are significant steps forward. However, these do not change what FileMaker currently is: a client-server database for custom applications on desktops and iOS.

Learn how to determine whether FileMaker is a good fit for your project. Use it for its strengths and work around its weaknesses. (BTW, all development platforms have weaknesses.) If you are not sure how to do this, get help. The worst thing you can do is declare “if it cannot be done in FileMaker, it is not worth doing.”

That is my take on the state of FileMaker 13. What do you think? You can leave a comment using the form below.

Filed Under: Web Development Tagged With: FileMaker 13, FileMaker Go, WebDirect

Barcode Scanning in FileMaker 13

December 3, 2013 by Anders Monsen 22 Comments

iPhone scanning barcode

A few months ago I wrote a series of articles (Part 1, Part 2, and Part 3) about barcode scanning in FileMaker Go 12. With the release of FileMaker 13, barcode scanning is now a native feature. There is no longer any need for the FileMaker Pro URL protocol and extra iOS applications.

In FileMaker 13, there is a new “Insert from Device” script step. The action is simple. Select the target field, a container, and from which device you want to insert (music library, photo library, camera, video camera, microphone, and signature).

Insert From Device script step

Once you insert the barcode, you can get information about the barcode using the GetAsText( ) and GetContainerAttribute( ) functions. The former gets only the contents; the latter gets the contents and type of barcode.

There are currently 16 supported barcode types including QR Codes.

Barcode types in FileMaker`

With barcode scanning now natively supported in FileMaker 13, there are more reasons to use FileMaker Go for inventory tracking and management.

Filed Under: Barcodes Tagged With: FileMaker 13, FileMaker Go, Insert From Device

FileMaker Go in the Wild

October 28, 2013 by Darren Burgess 1 Comment

iPads in a charging station

This just in: Our intrepid team of MightyData mobile iPad solution hunters has successfully observed a FileMaker Go mobile database grazing among the sports apparel production machines of long-time MightyData customer and unparalleled sports apparel manufacturer, Lettermen Sports. Our camera traps were ideally placed to observe a spectacular herd of no less than 18 iPads roaming the shop floor, stationed at embroidering machines, screen printing presses and collecting data at multiple work stations.

iPads in a charging station

The behavior of this mobile solution is simply astounding. The native indigenous employees were observed interacting with the beasts, using them to clock in and out of dozens of individual garments of sports apparel orders.  Data was observed streaming to the FileMaker Server, where tribal leader Amy Schumacher was observed running a report summarizing the profitability of individual orders, machines, departments and employees. Rumor has it that this comprehensive and dynamic report is run from a single FileMaker layout and will provide Lettermen with comprehensive productivity and profitability metrics heretofore impossible to obtain.

Embroidery machine with iPad terminal

Customer Feedback

Despite the risks associated with close proximity to the wildly thrashing embroidery machines, we were able to get a brief interview with Schumacher and her chief Production Floor Game Reserve Guide, Eric Milner.  According to Schumacher:

Wow. We are all just so excited to start using this. Well, except for the folks that are afraid of the iPads – they’re not so excited. But everyone else can’t wait to begin working and interacting with this spectacular population of mobile devices and its accompanying FileMaker Go application!

Mr Milner added:

Hey Man. This new mobile beast thing is awesome. But there seems to be a small infestation of software bugs inhabiting the FileMaker Go app-beast. Like it seems that the first contact login procedure for accessing the database is all goofy. The indigenous employees can’t see their orders on the iPad.

Hard Work Pays Off

Emboldened by the excitement of the safari guides at Lettermen, seasoned programmer and MightyData’s Maestro of Metamorphosis, Darren Burgess, was seen in the early dawn hours rapidly eliminating over 10 of these bugs. Preliminary reports from the production reserve have shown that the natives have embraced their new relationship with the wild iPads, helping them to create nearly 300 time clock records in just 2 days.

The MightyData team, in partnership with the Lettermen safari leaders, is excited to see the results of this spectacular FileMaker Go Mobile Application ecosystem. The result of months of planning, preparation and development, this new mobile application promises to deliver high-value results in a dynamic and busy manufacturing environment. Lettermen is looking forward to coming to a dramatically new understanding of its production costs and profits.

Thank you Eric, Amy and Lettermen Sports for embracing new technology in such a creative way, and trusting MightyData to deliver.  Great database software comes from partnership with customers committed to the challenging process of planning, designing and developing solutions. Now, that is what is really spectacular.

Filed Under: MightyData Culture Tagged With: Case study, FileMaker Go, Productivity

The GoZync 4 Migration Experience

September 26, 2013 by Anders Monsen Leave a Comment

ZyncMigration

I have developed a few FileMaker Go solutions which use SeedCode’s GoZync tool to sync mobile and server data. One mobile solution required a dozen tables, which GoZync 3 handled fairly well, but took a few minutes to sync. When SeedCode released GoZync 4, they boasted a significant speed increase. Naturally, that made this particular solution a prime candidate to update. Aside from speed changes, GoZync 4 also eliminated dedicated syncing layouts on the mobile and hosted files, moving these to the GoZyncMobile file instead. This made for cleaner customer files. However, migrating a solution built around the architecture of v3 to a brand new architecture seemed daunting.

The SeedCode crew informed me that migration was not that complicated, and an hour or less might be all that was needed to migrate from v3 to v4. While that might be case for smaller mobile files, reconfiguring my mobile file for a dozen or so tables took a little longer. Overall, the process went smoothly, as advertised. Rather than a step by step walk through of migration, which SeedCode already has created, here are some thoughts on the process.

Having a backup of all files is crucial. Don’t just back up the mobile file, but also your hosted file (or mothership files, as SeedCode calls them). Once you’ve completed your migration, you can clean out your old syncing layouts in both files. With backups you can revert to good copies if anything goes wrong.

Migration is almost like a brand new integration. With GoZync you deal with at least five (5) files:

  • GoZyncHosted (GZH)
  • GoZyncLicence
  • GoZyncMobile (GZM)
  • Your hosted file
  • Your mobile file

However, all connections to the mobile and hosted files are made in GoZyncMobile, and integration then takes place in GoZyncHosted as before. In GZM, setting up the connections in the Relationships Graphs is simple. With the GoZync TO in the middle, you add hosted files on one side, and mobile files on the other. (See diagram 1.)

Relationships to mobile and hosted files

Diagram 1: Relationships to mobile and hosted files

Next, you create your syncing layouts. Follow SeedCode’s format and group your syncing layouts in mobile and hosted folders. (See Diagram 2.) Then you can bring up multiple windows side by side and check that the fields are present for syncing. No field, no data sync. Caveat: calculation fields are tricky, but visually I didn’t get feedback about a calculation field on the layout, only when syncing. This might be due to the ability now to sync a calculation field to a non-calculation field, which is a nice bonus.

Take advantage of hosted and mobile layout folders

Diagram 2: Layout folders for mobile and hosted layouts

Once your mobile file is set up, the next item is to configure your hosted file. The interface has changed since  v3. You still sync each table, but the process makes it easy to get an overview of all tables being synced. You also can set certain tables to either push, pull, or both. (See Diagram 3.) Some of my tables were for reference only, and so I ended up pulling down half the tables, and both pushing and pulling the other half.

Diagram 3: Interface to sync each table

Diagram 3: Interface to sync each table

Then, it’s just a matter of replacing the scripts in your mobile file with the new scripts from the sample mobile file, hooking up the buttons, and syncing to test. I found that GoZync 4 is significantly faster than v3.

Filed Under: Scripting Tagged With: Data conversion, FileMaker Go, GoZync

Using a Web Service to Generate Barcodes

September 4, 2013 by Anders Monsen 4 Comments

Recently I came across a web service over at ProgammableWeb that generates barcodes. This might be useful if you scan barcodes, and want an alternate method to create barcodes in your FileMaker solution.

The web service, Barcodes4.me, is a RESTful service and requires no API or fee. It supports a handful of barcodes types, as well as QR codes, and requires a simple URL call. Using FileMaker 12’s Insert from URL you can send a query to this web services and insert a barcode image into a container field.

Given that this is a free service, there is no guarantee how long it will remain available or a free service. The types of barcodes available also are limited. This is still a good option to keep in mind when developing and testing a mobile solution with barcodes. I have included a small demo file to show this in action.

WebServicesDEMO.fmp12

Filed Under: Barcodes Tagged With: Demo file, FileMaker Go, Insert From URL, Web service

Creating Your First iPad Application: Layout Design

August 9, 2013 by Darren Burgess Leave a Comment

Layout design for portrait and landscape

I am deep in the middle of developing an iPad FileMaker Go application for an entertainment labor management company. Thought this would be a great time to share some of what I have learned about designing a mobile database solution.

Layout Design

In designing my iPad layouts I wanted the user to never have to scroll a form view layout. In other words, the layout would fit perfectly both in landscape and portrait mode on the device. This was accomplished by setting the width of the layout to fit the device width while in portrait mode and height of the layout to fit the device height while in landscape mode.

Layout design for portrait and landscape

So, I set the right margin to 768 and the total layout height (header + body + footer) to 686. In the case of this application, I am hiding and locking the status toolbar that shows at the bottom of the iPad screen, giving me a bit more room for screen display. (To force the Inspector to display the layout width and right margin location, click anywhere on blank layout space.)

In hindsight, I would not have designed this layout with a header and footer. They are not really serving a purpose with respect to functionality or design, other than that I can apply gradient fill independently in those layout parts.

Tab Panels

My next goal was to provide additional data display and functionality while the user was in landscape mode. I originally learned about this technique at the 2012 DevCon. To accomplish this, I placed the additional elements in the right margin, with the left edge of these elements at 768. The width of these elements is 256, bringing the total width to 1024, a perfect fit in landscape. The effect of this on the iPad display is that the elements in the margin will hide in portrait and display in landscape. Here are a few things to keep in mind.

  • Field in Right Margin – A field in the right margin will display in landscape mode, but cannot be interacted with unless it is touching the right margin. You can’t use the Go To Object or Go To Field script steps to get there either; it generates an error.
  • Grouped Objects – If objects are grouped, and the grouped object is touching the right margin, only the objects in the group that are touching the margin will display. See the screen shot below. The upper right icons (search, create, view) were originally a grouping of native FileMaker objects. What I found was that only the rectangle object would display in landscape; the icons would not appear. The simple solution to this was to take a screen shot of grouped objects and use the resulting PNG graphic file instead.
    Tab panels for iPad landscape mode
  • Tab Panels – The right margin area is made up of nested tab panels, allowing for additional data display and functionality. The main tab panel has 3 tabs, with the width of each tab set to 86. This puts the tab panels behind the icons in the graphic. I couldn’t use buttons here – remember they will not display unless they are touching the right margin. So I used a tab panel instead to simulate the buttons and provide the user with a visual indication (the small triangles) to indicate where they are. I also provided a second tab panel in the middle main tab panel that has 3 tabs, each providing a different kind of related record creation user interface.

And here is another hint to consider when overlaying objects on a tab panel, if you don’t want the object “stuck” to the panel: place the object first, then slide the panel to the object. This results in the object being independent of the panel. Don’t move that object though without first moving the tab panel to the side. Move the object, then the put the tab panel back. If you move the object first, it will get stuck to the panel.

So there you have it. With a bit of patience and trickery, you can create FileMaker Go mobile database applications that mimic some of the user interface behaviors that iOS users have come to expect. Stay tuned for Part 2 where I continue with some of my findings related to iPad field behavior, mobile database syncing, and more.

Filed Under: Layout Design Tagged With: FileMaker Go, Layout objects

FileMaker Go: Field Interaction Behavior

April 18, 2013 by Darren Burgess 5 Comments

Native behavior in FileMaker Go

Thought I would share a quick tip that I learned while working on a mobile database application for a customer.

Naturally there are many user interface behavioral differences between the desktop and mobile versions of FileMaker. This one involves the display of a field when the field has focus. Here are two screen shots of the same layout as displayed in FileMaker desktop vs. Go.

Text Field With Focus

Note, that when the field has focus in Go, it mysteriously expands.

Native behavior in FileMaker Go

There may be a legitimate purpose for this behavior, however it may also break the design of the layout on the mobile device. It also represents a departure from normally expected UI behavior on a mobile device. In my work with mobile FileMaker applications, I strive to have the database behave as closely as possible to what users normally expect from iOS apps.

A Simple Fix

Fortunately there is a simple fix for this. Simply apply a vertical scroll bar to the field using the layout inspector (data tab – “Include vertical scroll bar”). Then set the line characteristics for the field to “None”, to prevent the vertical scroll bar from displaying. Now, in FileMaker Go, the field no longer expands when it has focus.

Field with scroll bar enabled

Do you have any other simple FileMaker Go tips that help in development?  If so, share them in the comments!

Filed Under: Layout Design Tagged With: FileMaker Go, Layout objects

Scanning Barcodes with FileMaker Go – Part 3

January 17, 2013 by Anders Monsen 7 Comments

iMag Pro card reader for iOS

In this third and last post (see Part 1 and Part 2) we look at pulling data into FileMaker Go using magnetic stripe readers. In principle this is very similar to the barcode method. A button in the FileMaker database calls an Open URL script step. This Open URL step calls the iOS app – in this case CardSwipe – and includes a callback function to the FileMaker database to run a script. The script then receives the input from the card.

iMag Pro card reader for iOS

"ccqfm://?" & GetAsURLEncoded ( "fmp://$/" & Get ( FileName ) & "?script=swipe¶m=" )

With the swipe action, instead of URL encoding each character, we tried using FileMaker’s native function – GetAsURLEncoded(), and this seemed to have no ill effects. Once the button is pressed, the iPhone (or iPad) switches over to CardSwipe, which is then ready for you to swipe the card.

Cardswipe app for magnetic stripes

Once the card is read by the iMag device, it immediately switches back to FileMaker and runs the “swipe” script, which reads the data. Each card that is read encodes its data differently, so extracting information is a matter of trial and error, and the text parsing process must be coded specifically to each card. Characters like “^” often separate key pieces of information. Credit Card numbers get picked up, so security becomes an issue once you read these, as storing the numbers is never recommended. Once again we split the scripts into three separate pieces to assist with any troubleshooting.

  1. A button calls the first script, which has one purpose: Perform script #2
  2. This script opens the iOS app using the Open URL script step, which has a callback to script #3
  3. The script that receives the data, using a script parameter in step #2

Issues that arose in this process centered around getting the proper URL. Luckily CardSwipe has great developer documentation. However, in the example, the one that referred to a local file (vs. one on the server) used the tilde sign instead of the $ sign, which looks for a file on the device, rather than an already open file. This sometimes caused issues with locating the right file, but when switched to the $ sign the callback worked seamlessly.

The iMag Pro hardware is attached to the iPhone through the USB connectors at the bottom. I found that this connection doesn’t remain firmly seated in the iPhone 4, but works well with an iPad. The iMag came with an adapter that is supposed to allow it to stick more firmly on the iPhone, but this didn’t work with the 4 model. If the card reader doesn’t separate from the iPhone or iPad, this method is perfect for quickly reading data from a card with a magnetic stripe.

Conclusions

Getting data quickly into an iPhone/iPad by scanning barcodes or reading cards with magnetic stripes makes your process mobile. This method can be used to not just for credit card actions, but any card that can be swiped, such as ID cards. Once the data is in your app, the next question is, “what’s next?” Some time back I wrote about building a real world FileMaker app using barcode scanning and Insert from URL to reach out to external databases and pull book information using just the barcode. You also could use this process to scan people for admission to events, read student information during school lunches, or attendees at a conference. Card readers might offer ways to get data about employees, build a POS device, and check drivers licenses or insurance card for medical offices. With a small investment (or in the case of pic2shop – no cost whatsoever) your business can be set up to read data using iPhones without having to type in data, speeding up the process and eliminating typos.

Filed Under: Barcodes Tagged With: FileMaker 12, FileMaker Go, Magnetic stripe

Scanning Barcodes with FileMaker Go – Part 2

November 8, 2012 by Anders Monsen 35 Comments

Mobile app to scan or swipe data with iPhone

This is part 2 in a 3-part series.

In Part 1 of this 3-part post examining bar codes, magnetic strip readers, and FileMaker Go, we looked at the tools necessary to integrate all the components into one FileMaker Go solution. We will focus on just the bar code and FileMaker portion here. The necessary resources are listed in part 1, and the card reader portion will appear in part 3.

To create the FileMaker Go app, we create the database up in FileMaker, and then place the app on the iPhone or iPad (via iTunes or web page, for example). Since the device is mobile and connection to a networked file can get iffy, there are advantages to having all the action local on the device, at least initially. Later, you can sync the data with the server though a variety of methods (GoZync, MirrorSync, etc). We created a simple test database (see demo file below). This file contains both the scanning and bar code reading capabilities.

The Interface

The database front end is fairly simple, and consists of a field that stores the data, plus three buttons. The Scan button handles a single scan, and could be set up for either pic2shop or CNS Barcode. The Swipe button opens the CardSwipe reader app, while the Multi-Scan button works only with CNS Barcode.

Mobile app to scan or swipe data with iPhone

Pic2Shop

The first app, Pic2Shop, scans a single barcode, or EAN number. (EANs are 13-digit barcodes, but pic2shop will still scan older ISBN10 numbers). A good starting point is to create a button that launches the script, such as “Scan”. This script in turn launches a script to open the barcode app. In the sample database we have both the pic2shop and CNS Barcode available, and you can comment out one or the other while testing each method. We have a parameter in place to handle the two different buttons, the individual
Scan”, and the “Scan Multiple”. The “Open barcode app” scrip contains the key line, which is the “Open URL” script step. Inside this step you build the URL scheme to send to the iOS app – pic2shop or CSN barcode. The callback requirements must have the EAN string in the url, and for FileMaker 12 this looks something like

pic2shop://scan?callback=fmp://$/GoInput?script=Scan¶m=EAN

This url breaks down as follows:

  • the app: pic2shop://scan?callback=
  • the callback app, in this case Filemaker: “fmp://” for FileMaker Pro 12
  • the location of the FileMaker app: $ for an application already open on the phone (~ to open a database on the device, and hostname if hosted remotely)
  • the file name: GoInput
  • the script: Scan
  • the parameter: EAN (the barcode read by the app)

The url needs to be encoded to handle certain characters, and so the URL would change to this:

pic2shop://scan?callback=fmp%3A//%24/"&Get(FileName)&"%3Fscript%3DScan%26param%3DEAN
Characters Encoded
Dollar $ %24
Space %20
Equals = %3D
Ampersand & %26
Colon : %3A
Question Mark ? %3F

The last piece, the “Scan” script, handles the data received from the device. Since the barcode resides in the parameter, your script simply needs to insert the data into a field. Before looking at this script, we’ll switch over to see how CNS Barcode behaves.

CNS Barcode

The only variation we used was to enable the multiple scanning option on CNS Barcode, and this was set up via the script parameter and a Case statement inside the URL. If you are scanning multiple barcodes, having to click the scan button each time can slow down the process. However, one caveat is that CNS Barcode in this mode appears very sensitive and will scan very quickly and often the same barcode multiple times, and in some cases scanning a portion of the barcode that you don’t want. Instead of the full EAN 13 you might end up with a five digit number. When scanning multiple barcodes, all the barcodes appear in one return-delimited list in the clipboard. This list then is pasted via the script into one field in FileMaker. To split out the items, you could either extract the unique values in the script or using a custom function, and then loop through the unique values to create your records in FileMaker. The CNS Barcode Open URL script step then looks like this:

"cnsbarcode://scan?" &
Case ( $param = "multiple" ; "scanmultiple=yes&" ) &
"launchurl=" &
GetAsURLEncoded ( "fmp://$/" &
Get ( FileName ) &
"?script=scan¶m=::barcode::" )

A simple Case statement checks whether we chose a single or multiple scan. Next, add the launchurl to the FileMaker database (the name of the file), and the ::bardode:: parameter (just like EAN for pic2shop). The Open URL calculation is broken down into respective parts, but really is one continuous URL.

The Scan script itself places the barcode into a text field. With multiple data you would loop through and create multiple records.

Set Error Capture [ On ]
Go to Layout [ “Input from Barcode” (zSystem) ]
If [ Get( TotalRecordCount ) = 0 ]
 New Record/Request
End If
Set Variable [ $code; Value:Get(ScriptParameter) ]
If [ not IsEmpty($code) ]
 #
 If [ PatternCount ( $code ; "Multiple" ) ]
   Paste [ zSystem::gScanData ]
 Else
   [ Select; No style ]
 Set Field [ zSystem::gScanData; $code ]
End If
Commit Records/Requests
#
End If
#
Go to Layout [ original layout ]
Set Variable [ $Barcode; Value:zSystem::gScanData ]
Loop
  Exit Loop If [ Let ( $i = $i + 1 ; $i > ValueCount( $Barcode) ) ]
  New Record/Request
  Set Field [ ScanInfo::inputText; GetValue( $Barcode ; $i ) ]
  Commit Records/Requests
End Loop
#

This script creates a new record for each scanned item. In theory once you have a valid barcode you can reach out to other databases and get additional information if required, or a custom barcode would be written to contain all the information that you need.

Scanning barcode with an iPhone

Note the number in the red circle at the bottom. When scanning multiple items you can see how many are currently in memory. You can view the details by clicking on this icon.

Data from multi-scan mode in CNS Barcode app

Note the first item in the list, which contains ALL the numbers from the barcode, including the smaller barcode section, whereas the others are all ISBN numbers. In your database if you are scanning books, you would need to validate the numbers before trying to pull additional information.

barcode-data-in-cns-app

Finally, when you click done, the app switches back to FileMaker via the callback section in the Open URL script step.

Data from barcode in FileMaker Go

CNS Barcode’s multi-scanning action seems to quickly scan the same number multiple times, and also sometimes scans barcode numbers other than the ISBN10 or 13. Possibly there are some settings that might limit such behavior. Otherwise the multi-scan mode significantly speeds up getting that barcode data into FileMaker without switching back and forth between the apps.

The sample file: GoInput.fmp12 applies also to the magnetic strip reading process in part 3.

GoInput.fmp12

Filed Under: Barcodes Tagged With: CNS Barcode, Demo file, FileMaker 12, FileMaker Go

  • 1
  • 2
  • Next Page »

Let’s get started on your project.

It will be more fun than you think.

Get in Touch

  • Company
  • Services
  • Results
  • Blog

Copyright © 2023 · Parallax Pro Theme on Genesis Framework · WordPress · Log in