Just a basic sketch with (almost) no frills.

Compare previous implementations:

Excelisys Hierarchical Portals:

http://www.excelisys.com/tips-tricks-filemaker-downloads.php

Mikhail Edoshin:

http://edoshin.skeletonkey.com/

HierarchicalPortal11.zip

elegant as usual comment! :)

Nice one indeed!

--sd

One word: WOW!

Here are some modifications provided by mr_vodka

• the global field has been replaced by a variable (though this requires a screen refresh when expanding/collapsing items);

• the item label is a layout variable instead of a calculation field;

• the disclosure triangle is now a part of the item label, so it too indents according to the item's level;

• indent uses a tab character instead of spaces, allowing control of the desired indent on layout level.

HierarchicalPortal11Mod.zip

Edited June 28, 201015 yr by Guest
added * #4

Well, I've been playing with this and even praising it to others but it's time I said so here ... the techniques presented by you and John (Mr_Vodka) are incredibly exciting and powerful. Using conditional format to declare (and update) variables absolutely ROCKS.

I want to thank you both for your contribution and for sharing the ideas!!!

I was trying to replicate the hierarchy (I am new to merge variables) but still failed to do so. What is the issue here?

Rgds

SY Lim

Hypercube_Sales_Management_System_3_.zip

"put me behind the portal" should be read as "behind the top row of the portal".

Hi Comment,

This is very cool! just been trying to understand it...Where the heck does the <<$display>> variable get set?? I am sure I will go 'doh' when I find out :

Thanks,

Lance

Conditional formatting of the "I declare variables..." text object.

doh! It was right in front of me! Thanks Comment

Thank you, Comment, for this file. It is very nice. I like sorting the hierarchy on a number field (cSortfield) rather than a text field as it is not necessary to pad IDs with "0"s. (Nonetheless, I still appreciate Andrew Persons file and especially the accompanying white paper.)

A couple of questions come to mind:

1. Comment, how many records and levels can your version support? This is a theoretical question as I'm sure that a user would not want to click through a lot of levels. Persons' version can support a million records at 15 levels or 100 million records at 12 levels (White Paper: Hierarchical Portals in FileMaker Pro 7 - 10 by Andrew Persons, p. 1).

2. Persons' record/levels is based on FileMaker's indexing. He writes, "FileMaker indexes up to 110 characters of each line of a text field..." (p. 1). I am a bit confused by this. According to FileMaker, in FMP 11, a text field "index is based on the first 100 characters of each word or value". This is also true for FMP 7 .

Does this mean that an individual id can have 100 characters (e.g. 99 "0"s and a "1")? With a capacity for 1 billion characters per field ("limited by available memory), this would certainly make the record/level higher than 1m/15 levels or 100m/12 levels, would it not? Or, am I misunderstanding FileMaker text indexing and/or records/levels in hierarchical portals?

Ahm... in the Persons' file, what do you see when you click into the field used for sorting and select Insert > From Index… ?

Thank you for your reply, Comment.

The field used for sorting in Persons' file is PathID. When I enter this field I am unable to choose Insert>From Index... However, when I click into the ParentPathID I am able to choose Insert>From Index... and this is what I see (sometimes I have trouble uploading .png and .zip files; not sure why).

Ahm...

As soon as I read this I thought, "Well, I must have missed something obvious." So, I did a little more research. I created a FMP file and tried to hit the index limit but failed - perhaps due to the small size of the file (only a handful of records). In the TextID field I expected the Insert from Index to only insert the first 100 characters of a word (digits, in this case). Yet, I was able to paste in 2,448 characters.

I also created a .pdf to help me visualize my question. The .pdf and the .fp7 (zipped) are attached.

So, after several hours of testing, I'm still a bit perplexed - perhaps more so now. I'm still curious about the number of records and levels that Comments version supports. If I understand FMP text indexing correctly (bit of an assumption here) at 100 characters per word with no expressed limit on the number of words, than it seems like the number of records and levels would be very, very large.

FMIndexing.pdf

IndexingTest.fp7.zip

Well, the point is that unstored calculations are not indexed - so I am not sure why my method should be affected by the indexing limitation.

In practical terms, the file uses unstored calculations for both sorting and filtering, so I would expect that with a large number of records it would slow down to unacceptable speeds long before reaching the kind of numbers you mention.

Well, the point is that unstored calculations are not indexed...

Ah, that's the obvious thing that I missed.

Thanks for the reply, comment.

Developers really are the main thing keeping FileMaker advancing.

FileMaker Inc is lucky people like you and other's share moments of ingenuity like this.

Powerful technique - thanks Comment and Mr_Vodka.

Just a basic sketch with (almost) no frills.

Compare previous implementations:

Excelisys Hierarchical Portals:

http://www.excelisys...r-downloads.php

Mikhail Edoshin:

http://edoshin.skeletonkey.com/

I know it has been a long time, but can you explain this Comment?

Case ( ParentID ;

Substitute ( 10^ValueCount ( cAncestorIDs ) - 1 ; "9" ; " " ) ) & ItemName

thanks,

*Looks to me like it is finding the 1st name ( occurence on the portal) , no matter what i change in calc, i get

"Africa"

Am i correct ?

-ian

Edited March 8, 201213 yr by imoree

It indents the ItemName by putting spaces in front of it. The number of spaces is given by the number of previous "generations".

This file has been so Simple, but so darn awesome. What an easy way to do a hierarchical List using a portal! i have looked at other files, which have boatloads of TO's and Custom Functions,etc So convoluted.

How on Earth do you do it? i am in amazement by You, Comment.. Simplicity is elegance!

thanks for sharing this again...

-ian

the update of the list gets much more smoother if you replace the "refresh window - flush cache" script-step by a simple setField(Viewer::SerialID, Viewer::SerialID+1) script-step.

thanks from me too,

markus

the update of the list gets much more smoother if you replace the "refresh window - flush cache" script-step by a simple setField(Viewer::SerialID, Viewer::SerialID+1) script-step.

thanks from me too,

markus

That does not work for me at all..

Ian, it is a valid technique and actually a valuable basic method for triggering refreshes.

So if you were not able to make it work, you might state exactly how you have used the technique or explore what you have done incorrectly while attempting to implement it.

So if you were not able to make it work, you might state exactly how you have used the technique or explore what you have done incorrectly while attempting to implement it.

You are correct> changed my SerialID from AutoEnter serial to INDexed and it works beautifully now.

thank you

That is not the issue. It was already auto-enter Serial, indexed in the original example. But it can even be a global field. The relationship from Viewer to Items is a cartesian (X) relation so the index doesn't matter.

Hierarchy_test.fp7.zip

That is not the issue. It was already auto-enter Serial, indexed in the original example. But it can even be a global field. The relationship from Viewer to Items is a cartesian (X) relation so the index doesn't matter.

I have attached a file that does not iterate the SerialID field in the Viewer. If you change it to indexed only OR CREATE a new record while in Viewer Table, it won't expand the list. The file attached shows no movement like it should.

-i

Your file contains two basic errors which you introduced and illustrates that the original tip is correct if the simple instructions are followed.

First of all, your script does not actually set the SerialID field.

Secondly, the relationship is broken.

Apparently you may have deleted and then re-created the serialID field; but did not change the script and relation to use the new field.

Your file contains two basic errors which you introduced and illustrates that the original tip is correct if the simple instructions are followed.

First of all, your script does not actually set the SerialID field.

Secondly, the relationship is broken.

Apparently you may have deleted and then re-created the serialID field; but did not change the script and relation to use the new field.

Yep.. I feel like a real dummy now.. thanks for that..

Can the list be made to sort by more criteria than the key fields in cSortField?

For example: I have a price list table where there are menu records and item records and this works fine. I would like to be able to also sort on a "position" field in the event that an item needs to change position in the price list.

I have added a field that holds the position value of each menu and item record but I'm not able to get the sorting to work properly; I keep running around in circles. Can someone nudge me in the right direction?

Thanks!

- Brian

It's not exactly trivial. If you have a unique position value for each item, you could probably use that instead of ItemID in the cSortfield calculation.

Hallo to everybody

I'm new to FM, and maybe done somthing wrong, but:

I tried to implement this solution in test file, but encounted problem with performance - tried to put about 450 records to the hierarchi and every folder is started to open within about 5-10 seconds depending on the amount of records inside. I'm afraid that if the amount of records will be about 1-10K it will load for hours...

Did anybody else experiance the same problem? Maybe there is a solution of the performance problem in portal?

Plz help!)

P.S. Sory for my English)

As discussed earlier, filtered portals - in general, not just this technique - are not suitable for a large amount of records. IMHO, finding one record out of a thousand or more in a hierarchical portal is not so convenient for the user anyway.

As discussed earlier, filtered portals - in general, not just this technique - are not suitable for a large amount of records. IMHO, finding one record out of a thousand or more in a hierarchical portal is not so convenient for the user anyway.

So you say that there is no "good working" way to build a hierarchical navigation in FM? I dont agree with you about "is not so convenient for the user anyway", because at this time we use SQL build database with about 10 000 records in it and it structured the way it is very easy to find...something like: category>sybcategory>10-20 goods...

I realy want to use FM in our company, but hierarchi is the main problem for now...need to find solution)

So you say that there is no "good working" way to build a hierarchical navigation in FM?

No, that's certainly NOT what I am saying; I am saying that in order to build a hierarchical display with this amount of records, the solution needs to be based on relationships - i.e. working at the data level - instead of filtered portals that work on the layout level.

This is true no matter what method you choose to display the hierarchy: it could be a hierarchical portal, or a set of 3 side-by-side portals, or conditional value lists or something else altogether.

we use SQL build database with about 10 000 records in it

Let's say you have 10 categories with 10 subcategories each, and each subcategory holds 20 items; that's only 2,000 items. In order to select an item, the hierarchical portal needs to display 40 rows in total: 10 categories, 10 subcategories and 20 items. Speaking as a user, I don't think I would find such arrangement convenient. But that's just my opinion.

No, that's certainly NOT what I am saying; I am saying that in order to build a hierarchical display with this amount of records, the solution needs to be based on relationships - i.e. working at the data level - instead of filtered portals that work on the layout level.

This is true no matter what method you choose to display the hierarchy: it could be a hierarchical portal, or a set of 3 side-by-side portals, or conditional value lists or something else altogether.

I see your experiance is much reacher than mine) Maybe you can give some advice where i can see example of the "best solution" or read something so i can try to use the right way of doing that? I already read tons of forums and found only two solutions - this one and the one of excelisys dot com...didn't try the second one so far, but as I understand the algorithm is the same)

found only two solutions - this one and the one of excelisys dot com...didn't try the second one so far, but as I understand the algorithm is the same)

Perhaps you are not aware of the true context of this thread: filtered portals are a new feature of version 11. My demo shows how to use them to produce a hierarchical portal. Previous techniques are by necessity based on radically different methods. IMHO, the filtered-portal method is significantly simpler - however, it is limited in the number of records it can accommodate. That said, I haven't tested how the other methods perform with a large amount of records.

There is no such thing as the "best solution"; it all depends on what are you trying to accomplish and how you plan the users workflow.

could I bother you to repost the modified version of this technique that uses global variables rather than a global field?  The file in the original post won't download for me.

 

Thanks,

 

Dana

This is weird, because the attachment is there and can be downloaded by going to the URL directly:

http://fmforums.com/forum/index.php?app=core&module=attach&section=attach&attach_id=14596

Thanks!

One more question kind of related to this.  I'd really like a way to get the positioning of container field graphics to follow along with the indent of the text.  I'm thinking maybe a calculated repeating container field where the repetition populated depends on the hierarchy level.  Has anyone else extended this "tree" to allow icons to follow the hierarchy?

 

I don't see why not - provided you are willing to prepare a graphic for each indent level.

Thanks very much for this method! I never would have thought of this way of doing a hierarchy.

 

I have an enhancement.

 

If you have more than 20 records or so the display performance becomes . . . ghastly. The culprit is the cAncestorIDs field definition.

 

if you change the field definition from:

List ( 
Parent::cAncestorIDs ;
ParentID
)

to:

if (ParentID ≠ "";

List ( 
Parent::cAncestorIDs ;
ParentID
);
ParentID)

You will get a colossal speed increase: Importing 300 records with the original definition was more than 5 minutes; after the change, 10 seconds or so. Display performance is now really quite acceptable.  %^)   Before, the list function was executing every time the record was touched and list functions are expensive.

 

Thanks again for the method!

 

Dave

 

Reviving this old thread!

I am struggling to understand how I can implement this in a two table format,

whereas the parent table holds the country and childs table holds the states.

Any ideas, am I just missing something simple?

9 minutes ago, shredded said:

how I can implement this in a two table format,

A portal can only show records from one table, so this particular technique will not work for you.

Moreover, this was designed for infinite hierarchy (continent -< country -< state -<city etc. ). If you have only two levels, you can probably use something simpler.

 

7 minutes ago, comment said:

A portal can only show records from one table, so this particular technique will not work for you.

Moreover, this was designed for infinite hierarchy (continent -< country -< state -<city etc. ). If you have only two levels, you can probably use something simpler.

 

Thanks for the reply... Any suggestions on something similar? I was really hoping for a portal of parents, that could open related children, similar to file system.

Parent1

----Child 1

Parent2

----Child 2

----Child 3

----Child 4

Parent 3

----Child 5

----Child 6

I suggest you start a new thread.