jbante

Members
  • Content count

    591
  • Joined

  • Last visited

  • Days Won

    30

jbante last won the day on November 2 2016

jbante had the most liked content!

Community Reputation

137 Excellent

About jbante

Profile Information

  • Gender
    Not Telling
  • Location
    CA, USA

Contact Methods

  • Website URL
    fugue.bz

FIleMaker Profile

  • FM Application
    15 Advanced
  • Platform
    Cross Platform
  • Skill Level
    Expert
  • Certification
    7
    9
    10
    11
    12
    13
    14
  • Membership
    TechNet
  1. FileMaker 16 introduced a collection of built-in functions for manipulating data serialized as JSON. This makes it easier for FileMaker applications to interact with many web services. This will also make JSON the de facto standard format for scripts within FileMaker to pass parameters and results to each other, improving code sharing within the FileMaker community. JSON does not have a broad palette of scalar data types to choose from: text, number, boolean, and null. Even with those, FileMaker's JSONGetElement function always returns a text result, even when the serialized JSON value is a number or boolean. So I made a handful of custom functions and scripts for sending and receiving typed data with JSON. The module is hosted on GitHub, or you can download it directly.
  2. You definitely can make encapsulated or generalized logic in FileMaker. You can't do it the same way you would in Java or Haskell, but Java and Haskell can't encapsulate or generalize logic the same way the other does, either. FileMaker's abilities seem about on par with C in this respect. Every useful programming environment has its building blocks, such as in a standard library; and the contents of that standard library dictate much of how programs written for that environment operate, both internally and with the outside world. The operating environment or standard library is often a more significant contribution to the value of a programming language than the logical structures it uses. Java is popular because of the portable virtual machine, despite being awful as a language. JavaScript is another example. C(++) is popular because its operating environment is close to the silicon, despite that making it more difficult to encapsulate certain highly consequential concerns. FileMaker scripting starting with options available in the user interface is just one reasonable choice of building blocks to start with, and a pretty inspired choice, designed to minimize the learning curve for "citizen developers". In a Darwinian sense, FileMaker's choice is successful. (The script engine also includes many steps that have no counterpart in the user interface.) Every Turing machine has its tape, and failing to embrace the nature of that tape will doom a developer to never using that machine well.
  3. That's not a meaningful distinction. "Slow compared to other programming environments" doesn't make FileMaker slow in any absolute sense. "Slow compared to user needs for a particular application" is much more meaningful, and once an application is fast enough to exceed user needs, pursuing additional speed may be wasted effort. FileMaker passes this threshold for many applications, including applications working with millions of records. Working with large data sets efficiently with FileMaker may take additional work, which makes it no different from any other programming environment, and achieving the best possible performance from FileMaker often takes less effort than achieving the best possible performance from other tools. At least FileMaker doesn't claim that processing speed is an absolute top priority, then make design decisions contradicting that every step of the way — just look at what the HPC community has to say about Hadoop.
  4. Show me a programming language that doesn't have dozens of the same kind of rant written about it, and I'll show you a programming language no one really uses for professional purposes. One note on execution speed, though, since this was in the context of rendering QR Codes in a web viewer: JavaScript rendering a large QR Code in a web viewer isn't particularly fast, either. If FileMaker scripts aren't good enough in that respect, neither is JavaScript (or at least not JavaScript in a web viewer). A plug-in or a web service (with a low-latency connection) would be a stronger comparison.
  5. I'm not sure what you mean by "true code". Can you elaborate? What makes code "true" that FileMaker scripting does not satisfy, as you understand it? As an abstract-computer-science-minded kind of person, any series of instructions that a computer will execute is "code" enough for me — maybe I'll throw in Turing completeness if I'm being really picky, but FileMaker scripts satisfy that criterion, too.
  6. Nice! Yes, Barcode Creator uses a similar approach: building base 64 that can be converted to container data. The details are more complicated for different image file types and barcode symbologies, but that's the gist of it. I'd suggest you try EPS next if FileMaker's support for EPS in containers weren't deprecated. Other folks have used existing JavaScript libraries to render a QR Code in a web viewer. There are some challenges with that, though: The JavaScript QR Code libraries are mostly designed to draw the QR Code. I haven't seen one that actually makes a separate image file, but I haven't really been looking. In case you opt to display a QR Code in a web viewer, printing web viewers looked pretty awful on Windows last time I checked (on-screen resolution instead of print-quality). This might be worth someone checking again. Images in container fields print much better. Web viewers don't work in server-side scripts, if you ever want to move barcode creation from clients to the server. All the JavaScript libraries I've seen that generate QR Codes don't do it well. I have yet to see a JavaScript QR Code library that both supports all the basic encoding modes and optimizes the size of the encoded data.
  7. TriggersDisable is designed to be called by a script. It won't disable triggers without a script running to help developers avoid shooting themselves in the foot. What you're seeing in the Data Viewer is how it's designed to work.
  8. Others have commented on the usage of the functions, so I won't repeat that. The behavior of the Triggers* functions you describe sounds like a bug, but I can't reproduce it. Can you post the script where you saw that behavior?
  9. How different is the export process for each layout? In other words, how much of the single-long-script version would live inside the If...Else If...Else branches vs. how much would be the same steps (configured the same way) running outside the If[] block? The more steps in common, the more sense it makes to have the one long script. The more different steps there are, the more it makes sense to have separate smaller scripts. There's also another option for how to break up the logic which might be worth considering: one script for each layout, and each of those scripts calls common sub-scripts for substantial chunks of steps that are exactly the same. I lean towards this approach when there are both large chunks of logic different between contexts, AND large chunks of logic in common.
  10. See https://san-diego-workforce-partnership-1.workable.com/jobs/431628.
  11. If you're driver is already looking at the information on a smart phone, it's better to hand-off each destination to a navigation app than to generate the directions in FileMaker. This blog post describes how (at least on an iOS device). FileMaker can still maintain the order of destinations, and the Google and MapQuest APIs both include solutions to the traveling salesman problem that you can use in FileMaker to determine what the order of destinations should be.
  12. A solution to the original problem! Huzzah! And I really like a more thorough enumeration of the difficulties getting FileMaker to work with the null character. However, null-terminated strings are generally avoided whenever possible these days. Despite the other awkward handling of the null character, FileMaker is probably not using null-terminated strings under the hood, either in the calculation engine or in field storage: Let ( [ _null = Base64Decode ( "AA==" ) ; _string = "a" & _null & "a" ] ; Position ( _string ; _null ; 1 ; 1 ) // = 2 )
  13. You do not need a computer science degree to be hired as a FileMaker developer. Most FileMaker developers don't have any computer science training, in fact, so having one is a competitive advantage for an entry-level position. Be aware, though, that knowledge and skills unique to computer science (as distinct from general computer programming and IT) are often not what makes the biggest difference between a good and a great FileMaker application. A lot of computer science doesn't go as far as a little computer science combined with a little design.
  14. I'm way late to the thread here, but another way to make a (perfectly valid!) null character in FileMaker is Base64Decode ( "AA==" ). While this is a perfectly valid character both in UTF-8 and in Unicode more generally, it is disappointing that it doesn't get escaped in export formats like XML where it is not.
  15. Let ( [ #error = Get ( LastError ) ; #newError = If ( #error ≠ 0 ; Trim ( #error & " " & scriptStep ) ) ; It sure looks to me like the function is trying to ignore error code 0, even if there are previously recorded errors. It looks like FileMaker 15 is successfully setting $Error to empty until the first error, and successfully not appending new lines for error code 0. So FileMaker 15 isn't crashing. Great!