I guess I took the view that “gibberish<: …” is not a valid dictionary but, yes, I can see that it could be viewed otherwise.

cheers

Tom

I’m glad you enjoyed our stuff!

Your function works fine in the vast majority of cases and quite frankly is ridiculously cleaner. The only problem would be if there were gibberish in front of the dictionary information like this:

gibberish<:first_key:=

Your function wouldn’t be able to figure out the first key. It’s probably a safe assumption that this is an outlier or even that this shouldn’t be a valid dictionary. I figured I would cover the case if I could.

I love all these dictionary Cfs but it seems to me that the formula for DictFirst() is unnecessariiy complicated. Of course I may be missing something, but the following seems to do what’s necessary:

Let (
nameLength = Position ( dict ; “:=” ; 3 ; 1 ) - 3 ;
If ( Left ( dict ; 2 ) = “<:” ; Middle ( dict ; 3 ; nameLength ) )
)

Having said that, this is all awesome stuff

cheers

Tom

@Geoff - yes indeed # #P are the way to go, even speedier… ! love it! – i’m so glad to have the time to look around and clock these methods b4 even beginning to build my system [the wiki-basic is just a test db/documenting tool]

blessings, t

Thanks for the link. We’ll check it out. I agree that from a pure code standpoint, having a central function for escape and unescape would be better. But a design goal here was minimizing interdependencies. We copy these functions into existing files all the time, and since FileMaker still can’t copy/paste custom functions (grrr…) we wanted to make them as easy to move as possible.

As it is, you can get the meat of things with just #, #P and #R, which is only three bounces in to/out of the custom function dialog box. If we ever get the power to copy/paste CFs easily, we’ll almost certainly make these smarter along those lines.

As for DictAdd, I completely agree. I never use it because it is easy to just append using # instead. DictReplace is special though. It takes care to *remove* the existing value before appending, so you can change a value from one thing to another. This isn’t a super-common need, but I’ve found it useful a time or two.

I just realized, by the way, that I’m using our names for these functions and not the names in the article. For the sake of general interest, I’ll leave them there. In our systems, we use these names:

* DictSet is called #
* GetParameter is called #P

This just saves loads of typing since we use these functions in almost every script call. So to pass a “name” of “geoff” to a script, the param looks like this:

#("name", "geoff")

And to get that param in a script we do:

#P("name")

It looks a little crazy at first, but once you get used to it, it is nicely concise. I think when Jesse wrote this article he didn’t want to foist our wacky symbols on the world.

Anyway, all good stuff. At this point I’m rambling again

Geoff

Thank you for the correction, and for the compliment. I have fixed the article to use the “dict” function parameter correctly.

Thanks,

Geoff

Oh, and this blog is like totally awesome!

Am just playing about with FMP9 now, i figured i needed a file to help plan development for thegoodbook.co.uk’s systems. And that it would be good experience to build some sort of hierarchical documenting method to do so in FMP9. So done it. Good fun. Very underdeveloped, but will do the job. I have plans for it!! Anyway, if you want to see the implementation or borrow a pre-made simple hierarchy document structure file (only now suited to one hrchy) here it is: http://www.harmlesswise.com/download/wiki-basic.fp7

I didn’t bother with DictReplace/DictAdd - just one DictSet - this seems to be fine by your logic…? Maybe there is a subtle distinction i hadn’t seen?

Anyways many thanks for this stuff, i don’t think one could develop nearly as rapidly w/o such a system. FMP should include it in structure in future. Amongst other things!

gratefully, t