The FileMaker Collective

Linked List/Tree in FileMaker 7

 

A preview of how to implement a linked-link/tree (hierachical list) in FileMaker 7. This is largely inspired by the excellent Mikhail Indoshin's FileMaker 4/5 techniques. This example isn't the most 'optimized' but it illustrates some of the strengths of FM7 and applies some of cooler features of FileMaker 7.

Excerpt from my post the FSA.Tech.Talk@filemaker.webcrossing.com in response to a thread on script recursion depth:

[BEGIN]

John et al,
Didn't mean to be esoteric about this thread. Your point is well taken, although contrary to your modesty, your 'handle' on this matter already appears to be quite thorough. That said, my question wasn't about memory-management per se; it was about how FileMaker 7 behaved when scripts called themselves.

Let me be absolutely clear here. I am talking about SCRIPTS, not about calculations or custom functions. Two completely separate problems.

You see, in FM6, has Jason pointed out, there was a limit to how many "layers" of nested scripts FileMaker can keep in its head before it'd would simply quit or die ungracefully (aka, crash). I think the number was 1170 or something like that. I simply wanted to make sure there weren't any 'hard' limits that FileMaker 7 set for itself.

Why?
Because, it is related to a problem I am working on:

I have implemented a way to store records that are 'linked' together like in a tree. You can imagine my data-structure looking like this:

+-A
|--B
|  |--I
|--C
|  |--D
|  +--H
|
+-E
|--F

Imagine an outliner program (like the excellent OmniOutliner) where you have nested 'lines' such that A is the parent of B and C; and C is the parent of D and so forth.

There are numerous reasons why I have chosen this linked-list/tree approach. I can explore this topic in further detail elsewhere. But for the sake of discussion, one of the things I needed was the ability to move an entire branch 'cheaply'. See, if I want to make A (and all its descendants) a sub-level of another node, say E, all I have to do make E the parent of A. Regardless of how many descendants A has, that 'move' is still just a single operation.

One of the things I want to do is 'walk' through EVERY descendant of A (children, grandchildren, etc.) and do something, say, copy the ID of that node to a list at each one.

We can use a recursive script to do this. Here's the English version of the script, WalkTheTree:

WalkTheTree (

    Add the record ID of this node to myList
            // What i want to do at each step

    If I have a Child
        Go to Child      
        Perform script "WalkTheTree"  // This is the recursive part, call itself before continuing on.
         // Return to Parent node
    If I have a Sibling
        Go to Sibling
        Perform script "WalkTheTree"
    End if

)
       
WARNING: THIS IS NOT WORKING CODE. I am merely illustrating the essential concepts of using a script to recursively walk a tree. See how I am going to each child or sibling and calling the same "WalkTheTree" script which then goes to its child or sibling and does the same thing until there are no more child or sibling nodes?

Every time "WalkTheTree" calls itself, FileMaker is adding the 'new' WalkTheTree' to its stack of scripts it keeps in its head. Each preceding "WalkTheTree" script is put on 'hold' (not terminated) until the next one and the next one after that until there is no more 'next' one is done. When it reaches the point where it can't go any further (no more child or sibling), it adds that node's ID to a list, terminates, and allows its referring script to continue.

The point of all of this is that I want to make sure FileMaker will dutifully walk 'deep' trees without giving up first.
Hence the original question.

[snip]

A point here: A stack is just a method and a place to keep stuff where you put one thing on top of each other as it gets larger. It is actually Last-In, First-Out. The last plate you push in is the first one you take out.

[snip]

Runaway recursions are bad for a variety of reasons including those you mentioned. The point for me was to make sure my scripts didn't prematurely quit leaving me with a tree half walked.

Anyway, you can see a preview (screen shot) of this linked-list/tree approach implemented as in a hierarchical list here: http://blinkerfish.blogs.com/digitalsoap/2005/02/linked_listtree.html

[END]

A Practical Guide to Good Discussions

So much of managing people is about how to run meetings and building trust. Trust is a fuzzy thing. In large groups, there is a level of trust between each individual and everyone else. Part of leadership is to grok the this matrix of trust capital AND to elevate it. That's beside the point for now:

I have put together some initial thoughts about how to hold discussions... this is a very early draft. Feel free to comment.

Political Compass

I was curious about my recent political orientation and retook the political compass.org survey:

Mar 2004: E -4.12, S -5.64
Nov,2004: E -2.50, S -5.54

Its questions are somewhat loaded but a useful site nonetheless. As you see, I seem to have crept right. Share your trends below. I'd love to take the time to rewrite those questions...but perhaps, others have done so.

A kind visitor also recommended this link: Games and Interactive Activities

Opera

I lamented the horridness of email organization in a previous email. A kind reader mentioned Opera as a possibility. What was intriguing was Opera's mail filtering functionality--kinda like gmail but a real, honest-to-goodness OS X client. My initial impression is that Opera has hit all the right functional requirements. Its iTunes-like smart filters and labels are brilliant but the implementation is weak and its interface so bewildering confusing at first glance that I found myself lost in a sea of buttons and links.

Usability: 1/4
Features & Functionality: 4/4
Overall: 2/4 (yea yea, its not a straight average, sue me)

On The Reason for War in Iraq

So, the reason for taking the war on Iraq, according to Prez Bush was to fight terrorism. The rationale goes that the best strategy for combatting terrorism is to create democracies. So, really, the real reason for the Iraq war was to create a "democracy".

As for WMDs and the imminent threats scenario, we know now that the administration, even in 2002, were skeptical about the strenght of the evidence. I guess selling the public on the notion of "imminent threat" was a heckalot easier than selling the public on the notion that the road to terrorism-free world is to induce "democracies" with U.S. military might.

A word about these "democracies". It would be profoundly arrogant to believe that we can impose our ideological experiments of laissez-faire free-market big-business-driven capitalistic "democracies" on any people. It is this very imposition that undermines the liberal and progressive movements of Islamic nations. It is this very arrogance that robs reformers of any credibility when they talk of authentic representative government.

Why doesn't Kerry call Bush on on this is beyond me. This is the sort of neo-con double talk that makes me wonder if the stuff of fiction has found a home in the 21st century.

The Conservative Irrationale

I am enraged. I am saddened, angry and hopelessly lost in the face of the barbarism of these beheadings. I don't know why I did, but I downloaded the Armstrong video. And, I felt like a witness to an inhumanity that up to now you only read about and intellectualize. This will leave an imprint of horror on my mind far greater that I have ever possibly imagined.

In my tired emptiness, I read some of the reactions on various blogs. I am still stunned by the rationalization of the war on Iraq that continues to be offered by conservative apologists.

Here's one from rightonred.net:

1. Saddam was in violation of over a dozen UN resolutions
2. He refused to fully cooperate with inspectors
3. He was known to fund terrorist activity in Israel
4. It was known that Zarqawi and other terrorists had been given shelter in Iraq
5. The Gulf War was never fully resolved (i.e., no-fly zones)
6. All the intelligence at the time, both Clinton-era and Bush-era, plus the intel from the world community (Britain, Russia, Israel, etc) all said that Saddam had WMD.

Given all that, I don’t know what other choice could be made. The UN was proven useless as a deterrent to regimes like Saddam’s, and were obviously stalling for him.

The "War on Terrorism" is a tragic fallacy of words. Why do we continue to equivocate the war on Islamic Fundamentalism manifested as terrorism with the war on state sponsored terrorism? They may be equal in moral depravity but certainly, to confuse the two is to confuse the right approaches to fighting them.

I am too angry to write....more later.

FileMaker: Migrating your solutions

Download the document from FileMaker's site.

I have a small contribution in the FileMaker Migration Methodologies paper. Lots of wonderful people including Colleen Hammersley, Wendy King, Molly Connolly, Bob Bowers, Todd Geist, Corn Walker, Danny Mack, Michael Thompson, and Steven Blackwell contributed to this.

A better IDE anyone?

I like a lot of things about FileMaker 7 but there are some design decisions that continue to bog my mind. For instance, this concept of 'Design Database'. If we are going to have a Design mode, why not go all out consolidate design tasks under the same functional domain. It would be great, I think, to have a design database view that gives you access to all objects and tasks pertinent to database design including value lists. See my little mock-up for an idea. Heck, make it a FileMaker Developer feature if you have to.

Groundwork for a better GUI

Every now and then, I sweep everything off my desktop into "The Rug". The Rug is whatever folder I have happened to create in a moment of desperation to make the clutter go away. There is a direct correlation between the clutter on my desktop and my state of mind. It breeds anxiety as things pile up. I currently have 37 items under The Rug. I am uncertain how to put them all away in an organized fashion...which leads me to some observations about the way I work.

I don't work on one project at a time. Or rather, things aren't linear. It is a bit like the pain of writing with organized paragraphs. Sentences spawn different dimensions of thoughts that require varying degrees of elucidation. The constructivistic approach to building sequentially linked quantas of information is frustratingly simplistic. In the place of the wonderful immediacy of comprehension that comes from grasping the entirely of a concept, we muddle through a single dimension--a flatland--in the hopes that we can reconstitute meaning from our imperfect model.

That's the way I feel about desktop objects.

I don't want to file them away. They are all important. I may not be working on this particular file now, but hell, I am just setting it aside as I go about putting some thoughts on a different, related document. Yes, it is multitasking but our paradigm of object manipulation in a GUI world does not support that. I have the same problem with email. I don't know what folder to file this message under. It's from a colleague, it is related to the Copenhagen project and is also pertinent to issues of Interface and Interaction among other things. I want it to belong everywhere that I want it to belong to. And I want it to fade away into the background until I ask for it. Yet I want it to gently and subtly hover within my visual awareness when I work on other things to which it is relevant.

I don't want to file. I want to push things back. And I want them in piles.

I want depth to represent chronology and size and luminosity to represent importance or priority or both.

I want everything linked together and the ability to link everything together in a natural way.

I want to spawn related objects, not just create new ones.

I want...an organic relationship between the object and the next.

FM7 Portal Row Edits and Commits

I ran into an odd problem while working on my project management application in FileMaker 7. In one of my views, I have a portal in which the fields are enterable and editable "inline". You'll see in my picture that I have included a button that pops up a small detail window that shows users more details about that portal row and allows them to edit and add additional data to that portal row.

The crux of the problem is this. If you are "sitting" in a field in a portal row and then click the button (the blue plus sign) which does a "GTRR" (go to related record) of displaying it in a new, smaller window, you'll run into a record lock that prevents you from editing the record in the detail view because the lock from the referring window hasn't been released. If, however, we release that lock by committing the record BEFORE we do our GTRR, we'll lose the focused portal row and wind up going to the wrong related record (actually, always the first related record).

Solution
The idea is to be able to commit our record but still return to our portal row before doing our GTRR script. This is where script parameters come to our rescue. Pass the Get ( PortalRowNumber ) function as script parameter with that button. We can now safely commit the record, return to the portal row by the value of the script parameter and happily do our GTRR.