(And oh so sorry if the "22111 should be silenced" fraction's not able to recognize specific 22111 threads from their specific titles...)


First, the intro for the self-declared "authors" fraction here; other readers can continue after the ___ ...

Yesterday, I happened to view, just by chance, some in parts and for some aspects at least, quite wonderful movie, Die Stropers, a 2017 Afrikaans movie to be looked up in imdb by "The Harvesters" (title à double entendre, mind you...), and whilst most of the imdb "comments" were sub-par - I read reviews after having made up my own mind, mind you -, it's on https://www.allocine.fr/film/fichefilm-264015/critiques/spectateurs/ that you will read some smart observations, and especially from "poet75" there, who not only confirmed my - yeah, obvious! - observation that there's lots of Malick's "Days of Heaven"'s photography and mood in this one, but who - him alone! - also confirmed my own observation that there's "Teorema" in it, from Terence Stamp to "Pieter" now, it's not only obvious but much more, and you should become aware of that indeed if ever - that's the conditione sine qua non - you will have viewed the Pasolini flick, even if that has been 50 years ago (as I did).

On the other hand, even "poet75" missed the Hanno-Janno "parallel", and then, I got curious if some "third party" "got" it, but no, my google searches just showed false hits, since "hanno" is an Italian term, and even my search "thomas mann harvesters" just brought another false hit, to an otherwise very commendable book and pdf (I'm not entirely sure that the pdf might be legit?!), named "1001 books you must read before you die", and which of course, for one, mentions Hanno re "Buddenbrooks", but then "The Harvesters" as Pavese's "Paesi tuoi", and the "top hit" for that title is of course Bruegel the elder's painting.

Whatever, you should know about "Buddenbrooks", we're not in elementary school here, and thus, you should know about Hanno...

and then, Etienne (or is it Étienne ?) Kallos mused, there's "something", i.e. some person, BEYOND, and that's my subject here, and yes, I've been writing for some time now upon some quite similar "thing", some idea of some, now "classic", author, and then thinking beyond, so Kallos hasn't given me that idea indeed, but it would have been, and was, a brilliant idea indeed, even I hadn't had the same idea on my own, for my own stuff... and btw, Die Stropers being from 2017, I obviously have developed my "Beyond" idea after he did it, and, be assured, mine's about something "totally different"...

But then, it's about developing your own ideas where others' had come to a halt, and Kallos even named his "primal hero" after Mann's... and though, even 5 years later, nobody cared...

This being said, Mann's novel is a masterpiece (which got him the Nobel Prize), and Kallos' work is breathtaking by at least some aspects, and yes, some situations / scenes make you think of their obvious (i.e. subliminal?) model, and make you thinking 'bout Kallos' not going beyond Pasolini in there, and I'm not speaking of sex scenes, but of denied outbreaks: you literally expect'em, but those en-têtes fall flat, and so, and for other reasons, reviewers summarize, "festival circuit", and they're obviously right, since the-numbers.com (to be searched over there by "Die Stropers" again) doesn't give any (i.e. box-office or other) "numbers").

Whatever, and whilst arrogant-elitist-not-worth-much Cahiers du Cinéma say, "Cahiers du Cinéma - par Quentin Papapietro - Baignant dans une lumière orangée, parcouru de nappes de sons entendues mille fois, ce pur produit de la (ré)écriture festivalière et de la coproduction internationale semble multiplier les pistes narratives sans jamais en privilégier une seule, pour accoucher d’un scénario doloriste et convenu." (citation by allocine.fr again), I'd rather say Mr. Papapietro's secretely crying he's got the right first name indeed, but then not also the right second one - weep, weep, or rather weep-n-hate? (cognoscienti cf. Feyder's "Visages d'enfants" (1923), imdb: "Mother"), now back to work, and let's have a look at OUTLINERS and the like, and of which most also ride the ME-TOO train (which Kallos, notwithstanding Mr. Papapietro's opinion, does not), and with just VERY minor variations. - My next post here then, very technical again.

(And yes, "The Harvesters" could have become a b.o. hit, with Oscars and all, since it's a thriller anyway - it's just another missed opportunity of real greatness -, and yes, Hollywood and Art, with a major "A", isn't a dichotomy, and there has been proof galore in our - in everybody's, even your toddlers' - lifetime.)

Thus, Pieter being the "function beyond" Hanno/Janno - and yes, some thriller's a tragedy, too, and at the end of the day, every good thriller will be also a tragedy and foremost indeed -, outliners all are ONE SINGLE outline, up to this day, and that's obviously nuts - it's just that technical, and even more so, conceptual difficulties (i.e. intellectual limitations) have prevented that "function beyond".

(NO politics here, just technical stuff:)

Here - https://www.outlinersoftware.com/messages/viewm/41841 ("Who are you? I'm next" - citation from the extended version of "Apocalypse Now") - I described somewhat my problems with multiple dimensions in an outliner, with the example of my Covid/Corona press clippings of all sorts, and I described, or rather implied, my personal problem that for some 15,000 press clippings, the number valid some months ago, I had not been able anymore to correctly "file" those clippings, but had "filed" most of them just by "country", not by "subject" (e.g. "disease", "possible origin", "vaccination, medical aspects", "vaccination as a measure", "other measures", etc., etc.) - I had been simply overwhelmed by sheer numbers, and by the difficulties, not only to apply multiple "copies' links" "in time", but then also, and especially, to stay "on top of things" while perusing my "savings" - I also described my "need" - which would be technically, but just technically, solvable - to have all of the other dimensions "available", for any originally "taxonomic" category; - and not even speaking of the fact that for those press clipping, or at the very least, for the most blatantly biased of them, I would have liked to also have entries in "Politics - Press"... whilst my "Politics" UR db is quite another UR db, with again more than 15,000 "items", and with again more than 1 GB of (squeezed) data, so (re-) combining the two DBs would not really help, since both DBs, even individually, clearly show signs of "SQLite (or then, is it "SQLite in its UR outlining flavor"?) not really being fit for big data"...

I then shared my observations with SQLite's FTS (see there), in "Tags, and Export" = https://www.outlinersoftware.com/topics/viewt/9828/0/tags-and-export-cave-canem-or-whatever-you-might-be-in-awe-of where I listed many of SQLite FTS's exceptions, whilst also listing four non-exceptions, i.e. °, §, ¦ and ¢, all four of them easily available on my keyboard, whilst not having checked all of similar "special chars" indeed.

This way, in UR at least, but very probably in some other "outliners", too, and which also rely on SQLite's FTS functionality, you'll be able to LEAVE OUT one of the - important, but troublesome - dimensions: out of your - just one-dimensional - "outline", whilst putting it back "into the game" by e.g. "°cd", or whatever your individual "tag" my be, written into, e.g., the very first line of the "content" of your "item", or even at the end of your "item"'s title, in order to get that important dimension which would otherwise much too much complicate your tree, "°cd" meaning, in the example above, "country: Germany", ditto for cc = China, cu = U.S., e = Spain, etc., etc., with, in the case of need, some "°cos" for "Countries - Other European countries - Sweden" or "°cas" for "Countries - Asia - South Corea" - you'll have gotten the denominational system, I suppose.

(And for press clippings, you could introduce a similar system for the origin of the press clipping in question, e.g. "°sf" for "Source country: France", and the like...)

Then, what will you get by that? You will be able to "filter" by that "tag" (i.e. in UR at least, and in several other "outliners"), i.e., if you will have set the "columns"-to-be-displayed (and their "order" order) accordingsly, you will get a "hit table", i.e. a list of research results, by "tree order", of all those "items" which will apply (°c...) to, or come from (°s...) some country, i.e. you will have a geographical filter set now, but you will get the tree as-it-is...

Except that your new "tree" will (and in "tree" order, but without the respective item indentations) be in some search results window, which is quite awful indeed (but better than "nothing"; in UR you then can even edit the "hits", without the "results lists" vanishing, IF you de-select "highlight the hits within the text"...)...

Some developers tried to do this better, among them the ones of "Maple" (by "Crystal Office", very different from the much more known "Maple" maths app), and which then, i.e. upon search / "filter", open another "tab" within the "tree" pane; unfortunately, with "Maple" 8, as well as with "MyInfo" 6, I got to crash the programs within minutes, and on very simple tasks, but then, "Maple" is currently in version 9 (and "MyInfo" in version 7), so I cannot pretend these respective deal breaker prevail (UR is perfectly stable though, and, ironically, MyInfo's (versions 5 and 6; as said, 7 is the current one) crashes systematically occurred when I tried to use, just some, and very basic, data within MI's "columns", which can (i.e. could, in 5 and 6, I don't have trialed 7) be systematically displayed there, as in a spreadsheet, which is not the case with UR, unfortunately).

Then, lately, I made a very important observation: In most fields, that "other, almost-tree-breaking, at the very least tree-(building-)highly-complicating", alternative view / dimension" isn't necessary but for just some items, in special situations, and thus, the above-described tagging seems "ideal" for it, albeit "filtering within the tree pane, instead of within some additional pane" should always be at the users' fingertips (i.e. by 1-key-toggle) indeed.

On the other hand, the above-mentioned Corona example, and also, in a broader sense, the "Politics" example (almost 20,000 items, classified by countries since otherwise I simply would not have been able "to do" it, within UR's, or then with any other current "outliner" of my knowledge) are core examples of "use cases", i.e. areas in which "just apply the additional dimension by tag" simply "isn't enough": There, you will need real "pivoting", as there is, for "data crunchers", available in MS Excel.

Then, obviously, the software developer will encounter a big problem: They will not know, beforehand, which sub-trees (i.e. parenting for their own sub-tree of multiple sub-trees, that is) the user will need to have "pivot(e)able", and where such functionality will not be asked for, so they will have to implement it everywhere, which will tend to multiply the tabular data to be maintained by the "outliner" software, even wherever the additional functionality will not be called for.

And that's obviously that "functionality beyond" in this thread's title: Nobody, to my knowledge, ever cared for implementing it...

except for, ironically, askSam's developers, before those, obviously, left the room, and thus left the owner, an old aviation hero at the time, and the marketing chief, some Mr. Goodman, but who obviously wasn't able to do the (necessary amount of re-) coding by himself, alone with their obvious "mess of code"; considering that they claim to have sold 350,000 (or more) of licenses (and most of them without intermediaries, obviously), that makes 50 million bucks, at the very least, probably much more and even about 100 million, of which I'd very much like to know the whereabouts, since I could change the (IT) world (at the very least), with 100 million...

Now, let's speak about a fallacy: Most "outliners" - whilst not all of them, but then, the ones that don't do it, don't take advantage of it, obviously - don't differentiate between "folders" and "items", and "correctly" so, since our file systems' differentiation between the two concepts more often than not seems arbitrary.

On the other hand, in our "outliners" - and I personally speak of about 350,000 or near 400,000 "items", spread over some 30 SQLite DBs - since SQLite isn't "good enough" to "hold it all in just one file" (and that may be, in part, UR's way of implementing it, but then, other SQLite-backed "outliners" also show quick, sometimes even very early, lack of means for administering large data sets, even way "before" UR stumbles somewhat, so 350,000 divided by 30 does NOT mean that UR just "takes" 10,000, but then, it doesn't "take" 350,000 either, and much, much less indeed, unfortunately...) - - in our "outliners" then, even most "parent" items are just that, parent items of some sub-items, "siblings", that would never ever have to be considered as some "pivoted group", whilst on the other hand, many such "groups" exist indeed, and even every single item might be considered within, not only multiple contexts, but multiple pivotal data representations.

The answer of this enigma - but not the solution to it, too - lies in, from our, nowaday's point of view now, "early" works of those, not only in their time, "brilliant", no: genial!, askSam developers' developments, and which didn't come thru b/o askSam's incredibly awful "forms" concept: any new "field" wasn't possible but within a form for new (sic!) items, and that's the "detail" that killed askSam.

In fact, as soon as you differentiate between an item's title's "field"'s (i.e. "column"'s) name (i.e. the name of the table column), the title of the record...

AND THEN ALSO THE CATEGORY NAME IN-BETWEEN THE TWO

- i.e. you just need, in any SQL system, another, intermediate table, with which you can render ANY sql "outliner" as "pivotable" as MS Excel is, for its cell data...

the same unfortunately not being also true for NTFS file system folders and files, since NTFS and other (but not necessarily all) file systems do not assign ID numbers to their elements, neither to their folders nor to their files (so that it lacks the necessary indexing facility).

HENCE

We need, in "outliners", a new category, call it "category" or whatever pleases you, and which may not necessarily be, but can be, in cases, a specially-formatted, intermediary tree entry, or just, that's just as good, a specially-formatted, otherwise ordinary, "parent" entry, but of which the special formatting indicates it's also (i.e. additionally) retrieved and indexed in the special "categories" table...

And then, you just need the necessary pre-sets (i.e. "stored views" for those sub-trees of the global (hopefully Postgres- instead of SQLite) tree, and the necessary pivotal code, and then, pivotal views are nothing more than pre-set views, as any common, today's "stored search" is, any current "filter" is.

"Outlining" is its own, inherent fallacy, by pretending, by having pretended to us, for some 40 years now, that "outlining" is ONE hierarchy (amended or not, i.e. with some sub-trees "cloned" elsewhere or not), and askSam's developments around 2000, or even at the expiry of the 20th Century, have amply proven that to every (sub-) "outline" there is, there may be multiple alternative (sub-) "outlines", you just pre-set, and store, preferably in short, abbreviational "codes", as I have amply described here in this forum, the respective hierarchy to be displayed.

It goes without saying that if you work in "folders", you can preserve some manual "order" (within the groups) wherever that makes sense, whilst if you apply such a system just with tags, you will just get (multiple possible) ways of automatic ordering of the elements, but the core message is, you "file", "work" in some - whichever! - "outline" representation... and next time, you pursue your "filing", your whatever "work" in whatever alternative "outline" "view", and then again, you'll "switch back" to any of the previous "outline views", or you create new ones which will fit into your "workflow" as well.

As for the "special formatting" mentioned above, and since I amply discussed the necessity of user-specific "tree entry formatting", I suggest, for "category formatting", a special symbol, so that "bolding", "coloring", "italicizing" and the like will remain available for the individual user's means (cf. my comments on the awful "factory formats" in Devonthink...).

Then, the user, wary of creating the necessary "categories" for tree-building - and even the term of "pivoting" would then be misleading, since it implies a "natural", "base" "outline-form", whilst there is none, taxonomies in themselves being the fundamental fallacy, see? Be it "natural phenomenons", be it "measures", be it "consequences", be it "actors" (in that "scene"), be "countries", be it "anything", any relevant dimension in any area:

Software, at the end of the day, should provide you with that functionality beyond, which opens up your range of doing things, by first viewing them differently.

So that you'll need "°somethingsomething" tags just for "special cases", in order then to better "weigh" possible FTS (see above) "search results", before AI steps in and takes over.

In practice, all "dividing", ("sub-)titling", "categorizing" "parent(ing)" items should be (more or less automatically, certainly by 1-key attribution in case) also become "categories" (in waiting), the secret here being that their "category name" is NOT also their title, but within your tree, you would have those entries (whenever the "category" is not distinct, as a pure "folder", and as implied above, that's not even necessary, whilst in NTFS, it currently is indeed), in the form
SpecialIcon space TitleAsFormattedByUserE.G.France space (and in () and in grey: Category, e.g. Country)
(= 1 line)

And then your preset "tree-building" would create, from "Categories" in/on ANY indentation-level, "totally mixed-up", "top-down", "bottom-up" and every which way of combining such concepts, category by category, ANY "outline", not only from any, alternative "global" pov (e.g. "geographical vs. systematic"), but then also with any "in-between" "alternative detailing / ordering" as you might need in any specific "use case" - those "use cases" differing by the individual "sub-trees"' requirements or by those of individual DBs... but then, believe me, here again: Some one-and-only Postgres db, even spread over several physical devices, would be oh so much more welcome than multiple SQLite DBs...

"Outlining"'s (and now 40 years') fallacy consisted in not distinguishing between the tree's sub-titles' NAMES and their possible CATEGORY NAMES, and that's why - whilst askSam should have been our teacher, in its final version 7's help file it's all written down IF you're able to read between the lines -, even today, we (? I!) know of no "outliner" with "alternative trees": with the (sub-) titles (and their IDs) you can't do it indeed, you can't do it indeed, but with their - "implied" category names, i.e. with ___which category's individual value then___ they represent, it'll all become easy, technically AND conceptually... including "cloning" of sub-trees, their "clones" just being included within those new "meta categories" or whatever we could call them, "here" and wherever they belong, too:

From the "taxonomy" pov, your car assurances belong within "assurances", but you will create the clone of that "group" or whatever we call it, in "our cars", which will in turn be a (cloned) sub-group (or whatever you call it) of ("natural", taxonomy-wise) "group" "transport(s)".

And yes, the above doesn't deal with ease-and-speed of "multiple-filing", and it's obvious that the latter problem should be resolved by - before AI takes over - "individualized" "selections to click" of allegedly appropriate secondary filing targets, individualized in the sense of you first, in your "general inbox", typing some char, e.g. "p" for "politics", you getting a list of countries, with your "standard" countries all 1-char = 1-key, and other countries 2-key, in the above-described "(en)coding", even multiple entries being allowed, e.g. df meaning "Germany" AND "France", and then you type a comma, which will aim your subsequent entries to another part of the displayed info list, and in which you will, again by 1-, 2- or 3-char "codes", either memorized, for your standard "filings", or then read from = looked up in the lists displayed, determine further, "systematic" filing targets (with commata in-between, for your kb entries), and another comma will get you to more filing tables, non-standard within your current situation, and any "return" will process your "filing" entries; for my UR filings and for "standard" filing situations, I have even realized, within AHK, such half-automated ways... (It's obvious though that any distribution of your filing targets upon more than just one db unnecessarily and awfully complicates things...)

Of course, "consumers" of this forum - to call them "contributors" would be a blatant lie for most of them - are free to shout, "Zettelkasten, Zettelkasten, Zettelkasten", just as totally incompetent politicians here all over Western Europe constantly claim their minimum of competence to political thingies, defending their 300,000 bucks-and-more p.a. emoluments, by uttering the "necessary" "key terms", but at the end of the day, software development should not be about facilitating paradigms of the past, considering that yes, searching for ID numbers's faster on a pc or a Mac than it was in the card box and drawers age, but be about delivering THAT FUNCTION BEYOND.

"Die Stropers" is a tragedy: It's about a human being which, with all toil, will never be able to cope with the expectations of some "environment", dying anyway, just not as quickly as their outcast, literally sacrified victim who gives up.

When I said, in the one link above, with "°something", you can (I left out, sorry: "in a way"), replace XML elements, that wasn't entirely correct, since both askSam "fields" (just not for outline building, as explained before: then just the very first one), and XML elements, allow you to then even search for one of several elements, whilst in UR and other SQLite-backed "outliners", you would have to write °ar, °av, for being then able to retrieve different, "r" OR "v", values for attribute "a", there's no "r or v in a" then...

But that's details; as for their "real possibilities", current software developers fail, the ones who dare charge "subscriptions" as well as the much more modest ones.

They lack inspiration, and that to the point of not even being able to steal the core from genial ancestors. They seriously think that me-too's good enough, even when it's sub-standard.

And, with all due respect, "standard" is, at any time, what exists, be it Twain or Faulkner quality for modern writing, or then askSam for "outlining" in the 21st Century: stepping behind, and wanting to be paid? Become honorable: open a fries stall!

(And then, Die Stropers is a tragedy because they discarded the wrong boy.)

Some better but concise explanations for both subjects:

The movie: Kallos gives credentials, Hanno>Janno, how better could he said it, he just didn't foresee the educational lacks of most contemporary critics. And the Boer family's "life expectancy", with the iron bars on their windows - the perfect (arson) fire trap, wouldn't you say? - is, by probability, less than Janno's individual life span would have been, even if he hadn't had any children, and why should he not have had any, with a little comfort from his family, and the same way "his" generation in that family (either predominantly or all of them) was put together ( - the movie suggests most of all of the kids, incl. Janno, were adopted) - instead, the replace him, in order to get, in Pieter, that function that Janno, in their eyes, will not be able to fulfill. That's not Christianity, that's bigotry, and prayings, even quite fervent forms of praying, are shown throughout the movie, going onto most reviewers' nerves (Bergman did that better, in "Fanny..."); btw, Pieter shooting his dog himself is, but exactly, Snyder's "Save the Cat", just turned white-to-black, i.e. into the negative. - oh, and speaking of Twain, just after writing here, I viewed, by chance, "Mud", another movie with some lengths, but one you'll be happy to have seen if you do - and so it worked at the box-office, too. Back to Pieter, 'course he tries to establish for himself some "position" in life, and he isn't even mean, just the "Cahiers du Cinéma" guy is, but then, the family situation being "now" as it is, by the mother's suconscious atrocity, Janno just PRECEDES the family's waiting stroll into fire. And there's misogyny in the parents, too: The three little sisters are young, but the parents are young, too, and will there not be any chance in any of these kids then, and without sacrificing their son, at that early age he isn't able yet to make "alternative plans" for his life, to some "stranger"? From a writer's perspective, Kallos' introducing Pieter as that "spin on", "beyond Hanno", is highly interesting, even when then some girl on imdb said, after viewing the film, she had to get a chocolate bar to regulate back her mood into normal.

The introduction of the third dimensionality, vulgo "pivoting": We would need something like the thing I described above, as a "starting point" to then refine the concept; we must see that today's "parent" relationships, by which (alone!) then even the tree form is built up in many such "outliners" (and definitely in UR, see Codd / early Oracle and the "Adjacency List Model for Trees") are just technical: When you build up the hierarchy geographically, you will probably have a parenting item "Europe", with several "child" items, "France, "Netherlands", and so on, and here, the parent-child relationship is not only technical, but also "organic" (those countries are "natural children" of "mother Europe", and so on), but that's just by chance; further down, you will then have the respective politics, measures, even scandals (politicians filling up their or their families' / friends' pockets, etc.), and thus, there is NO such "organic" relationship anymore between those "children" and their respective "parent" items (except perhaps, and debatably, in rare cases where you pretended that, in this very last example, "political corruption is / has now become quite natural for country x", hehe).

And most of the time, it stays that way even if you do turn round the construction, by some sort of "pivoting": Whilst in the example above, the "higher-up" "parent-child" relationships seem "natural" indeed (continent > countries > even counties and such, e.g. Bundesländer in Germany or Austria, or regions, then départements, in France, even (big) towns then, in case), the "break" occurring "further down"; now when you "build" by politics, measures, etc., again you will have some "natural parenting" higher up, and then again, the break will occur further down, at the level where you split up every (or just some) policies, etc. into their geographic variations or implementations:

Thus, whilst in theory, technically, you could "mix it all up", in most real life use cases, and not only, it seems to me, if there is geographic sub-ordering present in the "tree", the "pivoting" will be wanted along some "standard lines" but which might occur, at different positions within the "tree", at different indentation levels indeed, since in some sub-trees, you will have inserted additional subdivisions which, e.g. for "quantity" reasons, were deemed not necessary between similar element "classes" in other "tree" positions, so a simple, technically easy, "mechanical" "pivot by (tree/indentation) level n" would not be feasible, and that's obviously the reason currently no "pivoting" in "outliners" seem to exist.

Instead, we have to identify the "breaking points", by their "natural character" if I may say so, and which, see above, is NOT determined by their (systematically indefinite, "systematically aleatoric") current "parentage"; on the other hand, it's obvious that even "before pivoting", and in most real-world use cases, most parent-child relationships in the "tree" can be "left alone", i.e. they probably need not be also determined by their "systemic character" or whatever you might call it.

This again is not entirely true, unfortunately, whenever you might want to obtain aggregation, e.g. whilst in one view, you would want to clearly discern between (to remain in the above example) regions, or between measures, in another, "pivoted" view, and with scarcity, or even absence of items in some sub-groups, you would like to aggregate further-down, all the more so since in this view, your objective lies in observations elsewhere, and it's obvious that a "pivot function" for outlining can not also accomplish such additional wishes, except with quite some additional code for obtaining, then storing such additional "view" particulars.

But back to our "pivot!" task: I always said we need 3 panes, not only 2 (see in this respect the individual means "robbed" Devonthink users now employ in order to at least "replace" a little bit that third pane DT developers took away from them), and it goes without saying, considering what I have said in my previous post here, that whenever I say "tree" above, I mean that "main subtree" which should be listed as being self-contained within that very first, "additional", "project" pane (in a powerful contains-it-all db), and instead of being one of multiple, distinct DBs, in other words, I always speak of the transformations, the "pivoting" of self-contained datasets, even though technically, within the global db, their "source" element and all it "contains" further down, is a "subtree" for its own part; technically, within the global db then, those "DBs within the db", i.e. all of their items = records, should get their own special (and also indexed) "db ID", additionally to their regular "item/record ID". (Such a concept would NOT interfere with interlinking between (single or even parenting) elements of different such "DBs within the db".)

Then, when preparing the "pivoting", the user interface should, within its (then not needed) very first, "project(s)" pane, display the "tree" (again, of that "db within the DB" currently "pivoted") in its current, non-"really" updated state, before the "pivoting" takes effect, whilst in its intermediate, the "tree" pane, it continuously updates the "result", according to the changes the user makes in the aforementioned, then "(transformation) work" pane, and which is just updated by, i.e. displays the changes the user makes there, with respect to the additional, or even renames of, "systemic poles" (described in my previous post here) still needed (since the "target", the "tree" pane continuously displays the intermediate results), whilst in / on the screen position of the currently-not-needed "content" pane there is room for the necessary, concise "target" / result tree construct to be obtained, and which will be stored to get back to that additional view later on: it's the "code" then, and behind the scenes, the tool will store not the current presentation of the tree in that view, but the framework described in my previous post; it's obvious that the "work pane" here could greatly assist the user's transformational work by (always temporary) greying out elements, reformatting others, and even highlighting (parent) elements for which the necessary "system(ic) tag" has not yet been added, i.e. guide the user to possible "leftovers", to be treated yet for their allegedly wanted "result", and in order to facilitate this "system tagging", prerequisite for those transformations, it's easy to imagine that whenever the user creates obvious "parent" items (just do TWO "new sibling" commands, identical otherwise, but with e.g. return = "just sibling", and with control-return = "also retrieve, and put into the "system" column, the name of the current "parent" item, as (preliminary) "pole" (or whatever might be a better denomination), and thus, when you create a specific measure, within a measure group, you'll do it by ^enter/^return, ditto for a region creation within a country, and the special field will automatically be filled with the parent's name, but whenever you create just a technical, not systematic / taxonomic "child" item, you'll do it by simple enter/return, being willing to fill it up whenever possible necessity later on will present itself.

And at the end of the day, why not speak of the

TAX

of an item / page / element / whatever you call the records, TAX being short for the record's "taxonomical identifier". Once you have those, necessary for your core elements only, your tree(s) being organized by the quite primitive "Adjacency List Model" or by something better (and which would probably not that much show the alleged "limits" of SQLite, or the other way round: even backed by Postgres, "outliners" with the ALM would be as bad as they now are!): Once you have TAX, "outlines" will get their third dimension... and remember, the tax entry would be (just visually) identical to the parent title (since technically, it would be a _tax_ID number, and be then (only) identical to the _record_ID number of its parent, if and when that parent is, also taxonomically, its "natural" parent, and if not, not, but then, in case (and if needed or at least filled-up that way), the title / _record_ID number of its "tax parent", wherever that one might currently be positioned within the tree. - And between what the user sees and those _tax_IDs, a simple (again indexed) table will make the connection.

So much for some additional details and explanations, as concise as possible for the "message" becoming comprehensible.

In the explanations before, I think a grey zone subsists, it's what the user would do, in order to transform, i.e. what they would do in their then "work" pane. For one, they would add (or in some cases even change) core items' "taxes", i.e. they would change the name, whilst behind the scene, the _tax_ID would be changed, and here and elsewhere, the tax name entering would be "guided", as "tags" in general would be, by automatic completion for already existing (and equally "taxed", in case to the "db within the DB"'s source item) "tax parents" = "tax names", and of course, here and everywhere, those "taxed" elements being listed in that already mentioned table, any item, or tax renamings (that's two different things, obviously) would be "transferred" to (better: be visible at) any other "occurrence" (since the IDs remain unchanged anyway).

Then, in this (then) "work pane", the user would indicate (by shortcuts, making appear special symbols) the "new hierarchy" in which they would want their dataset now to appear, and if in-between, and from the "result pane"'s visual rendering of the (intermediate) "results", they see they want it displayed in some other order (at start, deep down or anywhere in-between), they might, within the third, the "construction result" pane, just click on the two elements (ditto with selection and kb) in their now "new", preferred order, or they could even do this within the result pane.

I'm not entirely sure if the third pane here is really necessary, except perhaps - and even that appears debatable - for indicating what's finally stored, for a then immediate rebuild of this "view"; since the tool cannot foresee to which "level" deep-down the user wants to transform, it will need, in the then "work" pane, to display the whole (sub-) tree, in order to enable the user to designate even elements deep-down as "relevant for the transformation" (vs. "these blocks / sub-trees are just bulk to be carried along"), but it's evident that in the "result" pane, the tool could possibly just display a quite "stripped-down", representation of the result, but then NOT "frame-only" yet since while "working" on it, the user will also need to check where the "non-frame" elements will "end up" then, and if their respective position is accordingly to their wishes.

But then, "when it's all done here", for that specific view, the "result" pane could display the "frame-only" view, i.e. just the "taxed" elements, for checking and confirming, "frame-only" meaning "just the taxed elements needed in this specific view"; it's foreseeable that in some other views, "core" elements in/of this view here will be relegated down into the above-mentioned "bulk", "beneath" the view construct.

At least I think so, tentatively, and that's why I said above we would need something "half-way complete already", in order to have some "working model" from which we can then further refine; I just jotted down the above concept yesterday and this morning, without scribbling trial trees or something, and my spatial imagination / representation isn't that much developed. But I think two panes, the left (!) one just for the "status quo", with possible renames and selections-to-trigger, i.e. as sort of a "keyboard to play on", but otherwise stable, and where you know thus where the notes are!, and the right (!) one (since Western hemisphere, do>result = left>right; probably inversed in some language versions then), equally "playable" for (as said above, especially hierarchy re-ordering triggers), but showing some, simplified, "result", and then, after check-n-confirm, the result as sparse as it can get, and just the (relevant for this view) _tax_name hierarchy, before that hierarchy, _tax_ID-wise, is then stored, should suffice.

Concurrent working in both panes seems necessary since the user needs a tree they already know, and in which thus they know how to find elements, whilst re-arrangements within the "result" should be possible within the "result" pane - "error corrections" if you want -, since there, again for "spatial representation" reasons, they will be way easier for most users, than within the (at least visual) "source" construct... where on the other hand the user is free to also select additional elements (together with their possible "bulk behind"), in order for them to then be correctly represented within the new construct, within the "result" pane, so in that latter one, the attention should not be turned again on completeness but on clarity, and real use cases will then guide further coding.

Also, the storage of these alternative views is not only of interest for then immediate general access, but it's also evident that for any further transformation, the user will "load", into the "source" pane for that transformation, the "appropriate", already existent view, and from which then the transformation they have in mind, will be rather easy, compared to the possible use of some quite "inappropriate" "source" view.

It's obvious, too, that most users will very early set out to have two "parallel" "views" to work on, a taxonomic one and a "functional" one, and in the latter one, the question of subsets arises, e.g. for just some legal resources for some legal case, but then to be chosen from the complete available set of resources, and so on - I wrote about this aspect earlier in this forum -, i.e. you can "complicate" the functionality of such a tool almost ad libitum, while it's necessary to held it as simple as gets, interaction-wise, and my "pane condensation" within my writings here in this thread is a good example of how to do it: think of what is needed, technically, then simplify the user's work to get to it, to the core, and yes, I said this earlier, too, that means quite some code behind the scenes, so that it gets as simple as gets, for the user. (And the other way round: If the appropriate code isn't there, it's up to the user to append, by then even more, external macros, at least some bits of the missing functionality.)

Oh, and above, for Christianity vs. bigotry, I should have mentioned the term of "irony", but you will have filled up that gap of mine on your own. ;-)

Oh, and it's not necessary that those multiple DBs within the db system have a common source item, it's just a convention many "outliner" developers have adopted, and concurrent maintenance of multiple, equally construed "DBs" / tree-forms with the same db system are without problems and will not prevent interlinking, cloning between those different datasets, etc., so with the right "backend", it would be absolutely natural to have a very first, additional pane (i.e. two tree panes instead of just one), or even more than that, by option (and according to your current use case); just imagine "concurrent hoisting", i.e. not behind tabs but those tab "contents" visible at the same time, and on a big screen.

This is just a detail and which in no way affects anything I wrote above; I just wanted to clarify since above I presented the common source item as sort of a prerequisite whilst in fact it's nothing more than a (bad) "standard", born off developers' wish to save some lines of code and a single additional, again indexed, column.

Ok, ok, I left out a justification for the additional, semi-automated "tax ID": it serves to automatically combine all those, instead of heaving to list them, again and again for any such "alternative" "view" (I write "view" because it's just short for "active representation" or something like that, whilst real "views", without double quotes, are just what the term implies: you couldn't work on them, just view them, and copy from them, perhaps even do non-destructive filtering and the like). Thus, you do some "work" once-and-for-all, and then get much faster results in multiple "views".

On the other hand, technically, you also could do some "primal", "source" construct, ordered in a strict taxonomic way, and then, whenever you want to create alternative "views", all of them then to be derivated from their common, "original" "source", you could have that "original tree", on the left, and your "target tree" on the right, with any "click" into the "original" then not "copying" the clicked item into the derivative build-up, but all its "children", with perhaps additional keys for "just its immediate children", or, with different selections, by expansion vs. collapsing, for different "depths" for different descendents.

In such an environment, the tool will then need to inform you about "left-overs", i.e. about "orphans" you will have overlooked, and which will not have yet found their position within the "target tree".

And speaking in general (i.e. for both concepts to get variant constructs), yes, it often might make sense to "export" just some, and even different PARTS of a "tree" (even within a "db within the db", i.e. a further subset of the "natural" subset), an example coming to mind being the (more or less empty, i.e. possibly stripped of its descendancy further down) geographic part at some position of the specific db-in-the-db, and then just some phenomena, i.e. another "selection", not bulk, from another part, into a new, now just partial, "directed" "view" of the dataset...

But then again, any envoking of that "partial, directed view" would be "live", i.e. come with all the - previously "permitted" by your construct - data as it is presently is within the "original" (i.e. the "standard and complete representation"), and if you think that's "too much" for individuals' use, think about user-groups, about corporate environments: data subsets and data rearrangements are common tasks, so combining such tasks with a "natural" tree organization, without endless scripting to achieve that, every time, obviously makes sense, even for individuals who ask for more than for, well, "the strict minimum".

Fact is, today's DBs "permit" all sorts of "data crunching", whilst "outliners" "bring order" into information data and such, but at the same, impose just one single order onto that data, and any real rearrangement (exception made then for filtering) will be destructive, which means, in practice, that you will have to produce just, logically non-"live" copies of the data you then can rearrange as you like, but which henceforth will contain obsolete data.

It's obvious even "outliners" need the "third dimension", just like and even better than it's available in Excel and the like, after now about 40 years or even some more of "tool-based outlining". (Or rather, it's big time we got that functionality back, which died with askSam, to give credit where it's due.)

This entire thread is dispensable.

Hah! On the other hand, it is clearly labeled, as promised. And until us, this was a thread where 22111 was having an apparently deeply engaging conversation with ... well, with 22111. So hey, here's your reward! We see you doing that!

"Also sprach 22111" – it has a certain ring to it...

jaslar wrote:

Hah! On the other hand, it is clearly labeled, as promised. And until
us, this was a thread where 22111 was having an apparently deeply
engaging conversation with ... well, with 22111. So hey, here's your
reward! We see you doing that!

“A thread for everyone and for no one”.


MadaboutDana wrote:

"Also sprach 22111" – it has a certain ring to it...

jaslar wrote:
Hah! On the other hand, it is clearly labeled, as promised. And until
>us, this was a thread where 22111 was having an apparently deeply
>engaging conversation with ... well, with 22111. So hey, here's your
>reward! We see you doing that!

Am I the only one who enjoys reading 22111's posts? If these posts are actually from a person, who's typing out their train of thought then I find that interesting. I can't explain them, I don't know what they mean, I don't understand a lot of them (my fault, not 22111's) but it's a fun ride for when I have extra time.

There were nuggets of interest in some of 22111's posts. He (or she) was out of line in some comments about other contributors here.

Absolutely. I enjoy the thought processes, but I object to what appears to be a compulsive need to attack developers and contributors based on very generalised premises.

There's more than enough unpleasantness out there on social media already. Let's not add to it!

Amontillado wrote:

There were nuggets of interest in some of 22111's posts. He (or she) was
out of line in some comments about other contributors here.

I got interested in the forum handle. It's pretty cool.

22111 is a prime number. If you square it, reverse the order of digits and take the square root of that, you get 11122 which is the original number in reverse order.

2111 exhibits the same behavior and it's a prime number, too. 2111 squared is 4456321. Reverse that sequence of digits to get 1236544. Take the square root of that and get 2111 backward, 1112.

Amazing what you can find in that new Google thing the kids are all talking about.

That is interesting. Neat that it set off your curiosity to research it a little also.

I read his posts. Sometimes there is some interesting (mostly hidden) oppinion in them about the stuff we talk here.
But i'm still very convinced that this guy/gal had once overdosed on LSD and never came back from that trip or more
likely just had a stroke resulting in this kind of writing style.

Don't ban him, we had worse people here, like this Filippino Storyserver guy with the idea to rewrite Ecco Pro.

Lb wrote:

Am I the only one who enjoys reading 22111's posts? If these posts are
actually from a person, who's typing out their train of thought then I
find that interesting. I can't explain them, I don't know what they
mean, I don't understand a lot of them (my fault, not 22111's) but it's
a fun ride for when I have extra time.

Oh, thank you so much, Lothar, for voting I should NOT be discarded from here and for life: sometimes, even sheer condescendance (hi, Chris, your software so many times tells me my wording is wrong, and since I'm - definitely! - a non-native speaker, this sometimes is misleading...well... ;-) ) is oh so much heartwarming!

But then, ain't you the developer of one of those electronic xx emulations, the original being invented of that German State official, having had lots of assistants to do the necessary gathering(s)?

And why you ALL - i.e. incl. you, the "coders", avoid discussion about conceptual, even technical specifics, retreating, EVERY time, into "meta"?

Ain't you capable of seeing that now, some 40 years AFTER those very-first "outliners" of-their-time (and which didn't allow the user to add "content" to their "outlines", too, just like in secondary school, right?), users should be entitled to "some more" than that?

The same, btw, is valid for file managers and their - nowadays-expected - functionality: Just today, "Directory Opus Pro 12" is "on offer" on bitsdujour, but whilst I had been mistaken, some about 5 years indeed, by commenting (over there, or was it elsewhere?), on version 12 already, that having been "out" for some 2, 3 years already in that time, that that Australian company systematically offered their "DO" "for sale" when the very next version was "in waiting" (and which had been true indeed for their previous off-price offerings), their all-"doctors" original developers had been retired, and their up-to-then "forum" answer person, some "Leo", had overtaken even further "DO" development -

Well, now, some about 5 (?) years later, and thus, their "usual" development rhythm having been quite changed indeed now - their version 11 now being about 6, 7 years old, way from their their about 2, 3 years "turnover" at the time, no? -, now, bitsdujour says, today, "Please note that all comments for this promotion will be screened before posting. It's nothing personal, just a step we have to take because of a few bad apples last time around." - which means that I should not even try to reiterate my - erroneous indeed then, exceptionally! - warning that within some months, there would appear the very next, paid "DO" version - then I was wrong, their forum- "Leo", having overtaken even further development, not observing their previous "output" schedule, but this time, I'm sure I'm "good" again, so don't buy "DO" at bitsdujour today, since version 13 should be immediate...

And then, even version 13 will be some other "classic" one, another version WITHOUT that "function beyond", and that, at the end of the day, is the reason why Chris, this forum's owner, doesn't throw me out, as about 95 p.c. of this, his, forum's "contributors" (haha!), ask him for: He obviously knows about the failings of today's coders, i.e. their inability to "look forward" in some way: to invent the unavoidable.. those functionalities that ultimately will, of course, be invented by google & Co. (i.e. amazon, Apple...), but will then spy-on-you every second of your further lifetime, transferring every one of your (possible, rare) ideas to the powers-in-place, in order for them to market'em before you'll have a chance to do so, yourself.

It' right that more than 25 years ago, I was one of the very first "outliner" developer there were, in those time, and it's right I failed, because of the "back-office" I had bought, by the MS-co-developer Allen (who's dead now, and I don't shed any tear), wasn't "prime-ready", i.e. had - in its time, and provable; I don't know about any further developments) - work memory (allocation) issues that weren't "resolvable" by a mere "application developer" like myself (in 1996/97), but then, the fact that today's "developers" i.e. coders without a dime of conceptual sense, obviously and for most of them, don't do any better than we, sorry, "avantgardists", did, in our time - I wasn't a coder, I was a conceptualist*, then coding with the means available to non-coders at the time -, that fact, that 2022's coders don't do ANY better than their pairs did, 40 years ago, is appalling, and there's no other term to describe that state-of-affairs without lying.

Fact is, I got 2 paid, legit licenses of askSam (3 and 4), AFTER having coded my "outliner" (incl. cloning and all), and then failed to get an update to v. 6 (which already included their wonderful "alternative trees" feature) because in time, i.e. within 24 hours or less, I didn't find my legit v. 4 license... and then, I got, by legitimate way again, just a non-pro version of their v. 7, i.e. one without the (necessary, for real use) indexing feature... but this way, I at least I'm a legitimate owner of their v.7 non-pro, incl. their, "pro"-including, help file, and yes, it's a fantastic concept, and whenever I discover excellence, I say so, so please permit me to also speak out whenever I see just sheer incompetence and meanness, and as I do here.

Y'see, I'm modest and humble, but I seriously think that people who have almost nothing to say, should be modest and humble, too - very sorry!

And "DO" has always be a scum, since they always - and in their time every about 2 years - asked for paid updates, i.e. for update fees, when in fact and conceptually, they remained "all the same"... and even compare their "ADS" functionality with xplorer2's one's (with xplorer2 selling, not-overpriced, "life" licenses), and you'll discover just another example of "DO"'s hybris, allegedly justifying their pricing while in fact even "DO" is, and always has been, just ordinary fare.

And ditto for every current "outliner" I know of...

Fact is, I spoke of askSam's incredible (and unique) "pivot" functionality, and you - all of you - just discussed if Chris should relegate me, finally! please! - to silence, or then not, whilst you, coders, haven't done much now, for 40 years, between the advent of the very first, very basic "outliners", 40 years ago, and now, summer of 2022?

Many of you here will have some "later" version of askSam indeed, and whilst I'm not entirely sure if my "full citation" of that help file is legit, AS being, as they say, "defunct software", and since it's in obviously general interest, well - here is its "Using Folder View" of version 7 (Pro and not-Pro) chapter (without the screen shots that is), in full-text, and when I say, coders of today should be ashamed of their, obvious, lack, of conception, well, here's proof now: (AS 7: help file: "Organizing Documents with Folders"):

With the askSam Folder View, you can organize your information in folders and sub-folders. Unlike most folder implementations, askSam Folders are displayed dynamically based on the contents of a field that you specify (for example a category field or a type field). You can quickly change the way you view and navigate your information. This is a powerful way to analyze your information.

With the askSam Folder View, you can:
Organize documents into folders and sub-folders.
Browse and navigate through your documents.
View your information from different perspectives.
Choose which field defines the folders that askSam displays.
Right-click to export, delete, email, print, and more.
Customize how the Folder View is displayed and sorted.
Run reports, stored searches, and more from the Tools Folders

NOTE: In the askSam Getting Started Guide, there is a Tutorial that leads you step-by-step through working with folders. You can access the Getting Started Guide from the HELP menu.

To show or hide the Folder View:
By default, the askSam Folder view will be turned on. On the left side of your screen, there will be a window that displays a list of the documents in your file. Underneath this window, you'll see the Tools Folders. The Tools Folders contain Entry Forms, Reports, Stored Searches, and other information associated with your database.
You can turn the Folder View on or off by choosing VIEW - FOLDERS (or pressing CTRL+G).


The Default Settings for the Folder View:
By default, the askSam Folder view displays the first line of text from each document in your file. [ICH: Since AS docs have no titles]

Click on any document to display its contents in the askSam Workspace.
NOTE: If you create a new file using a template, the default settings for the Folder View may differ.

To Setup Folders and Customize the Folder View:
You can easily customize the Folder View. The Folder View can display folders and sub-folders, sort the items listed , and list documents based on a field name (rather than the first line of text). askSam is a very flexible program and can be used to organize many different types of information. These customization features let you use the Folder View feature for all different types of information (both structured and unstructured). In addition, you can also customize the Folder View to organize and display your information in different ways.
1. Click on the triangular Button next to the word "Documents"
(You can also access the Folder View Settings from the FILE - PROPERTIES menu).
A drop down menu will appear.
2. Choose Folder View Settings...
The Folder View Settings Dialog Box will appear.


The Folder View Settings Dialog Box contains options that define how askSam will display the Folder View.

Display Folders and Sub-Folders - Displays documents grouped into folders and sub-folders. The Folder Field option specifies the field that will be used to group the documents into folders. For example, if you choose a field called Category[, the documents will be displayed in folders based the contents of the Category field.

Document Display - Determines the text that will display for the documents in the Folder View.
First Line - Displays the first line from each document.
Field - Lets you specify a field. The contents of this field will be output in the Folder View as the Document name.
Sort - Alphabetically sorts the documents listed in the Folder View.

3. Select the settings and choose the OK Button.

4. The Folder View window will be refreshed with the changes you've made.

The Folder View is a great way to organize and display information in different ways. For example, you can display the Sample Reports example file shipped with askSam in different ways:

Default Folder View in Sample Reports File (listed using First Line)


Documents displayed using the NAME[ field Documents displayed using the COMPANY[ field


Folders displayed by COUNTRY[ field and documents displayed by the COMPANY[field


Folders by AGENT[ field (Sales Agent) and
documents displayed by the COMPANY[ field documents displayed by the COMPANY[ field



To Refresh The Folder View
When you edit the Folder Field in existing documents, you'll need to refresh the Folder View to see your changes.
To Refresh the Folder View:
1. Click on the triangular Button next to the word "Documents"
A drop down menu will appear.
2. Choose Refresh
askSam will regenerate the Folder View.

To Setup Sub-Folders
You can organize your information not only in folders, but also in sub-folders (multiple levels). Setting up sub-folders is identical to setting up folders (see the section above To Setup Folders and Customize the Folder View). The sub-folders are created by the contents of the Folder Field. To create sub-folders, simply add a backslash and sub-folder name to your Folder Field. For example, in a Todo list you might have a category field. This field would contain categories for todo items:


To create sub-folders, you could fill out the category field in your documents like this:
Category[ Marketing\On-line
Category[ Marketing\Trade Shows
Category[ Marketing\Web Site
This would create a folder structure similar to the following screen:


You can even have multiple levels of sub-folders. For example, you could have a sub-folder under On-line for Advertising:
Category[ Marketing\On-line\Advertising


To Sort The Folder View:
You can alphabetically sort the documents listed in the Folder View.
1. Click on the triangular Button next to the word "Documents"
(You can also access the Folder View Settings from the FILE - PROPERTIES menu).
A drop down menu will appear.
2. Choose Sort Folder View Items
The documents in the Folder View will be sorted alphabetically.
NOTES:
1. If the Sort Folder View Items option is checked, selecting it will turn off the sort and the items will be listed sequentially (in the order they appear in the file).

2. The Sort option in the Folder View Setting Dialog Box also allows you to sort the documents in the Folder View. = ???

To Move Through Documents Using The Folder View:
You can move through the documents in your file using the Folder View. Click on the + symbol next to the folder to expand the folder. Then click on the document you wish to view. The contents of the document will display in the askSam workspace.
You can also navigate in the Folder View using the cursor keys.
The Up and Down arrow keys will move you through folders and documents.
The Right Arrow key will open a folder.
The Left Arrow key will close a folder.
NOTES:
1. To execute items in the Tools section, you're required to press the ENTER key on the keyboard or DOUBLE CLICK on your mouse.

To Create A New Folder:
askSam dynamically creates folders based on the contents of the Folder Field. To create a new folder, you simply add a document to your file and place the name of the new folder into the Folder Field. When the document is saved, it will be listed under the new folder.
For example, if you are using CATEGORY[ as the folder field:
The following document would be saved into a folder called "Marketing" in a sub-folder "Web site."

NOTE: The previous section "To Setup Folders and Customize the Folder View" explains how to set the Folder Field.

To Rename A Folder:
Because askSam folders are generated from the field contents of your file, you cannot simply edit the folder name shown in the Folder View window. To change the name of a folder, you must modify the contents of the Folder Field in the document contained in that folder.
If you only have a single document in a folder, you can simply edit that document and change the folder name in the Folder Field to the new name. If you have multiple documents in a folder, each of the documents will need to be modified in order to change the folder name.

You can use the EDIT - REPLACE command to change all the documents at one time.
1. Choose FILE - PACK to make a backup file. It's important to always have a backup before you use the EDIT - REPLACE command.
2. Choose EDIT - REPLACE.
The Replace Dialog Box will appear.
3. In the "Find this" field, enter the name of the Folder Field and the folder name. For example, if your Folder Field is category and you have a folder called "Mktg", you would enter: Category[ Mktg
4. In the "Replace with" field, enter the name of the Category field followed by the new folder name. For example: Category[ Marketing
5. Change the "In" field from "Current Document" to "All Documents".
This option tells askSam to look in all documents -- not just the current document.
Your Replace Dialog Box would look like this:

6. Choose the REPLACE ALL button.
askSam will make the changes in your file. The "Mktg" folder will be renamed "Marketing". To see the changes, you'll need to refresh the Folder View.

To refresh the Folder View:
7. Click on the triangular Button next to the word "Documents"
A drop down menu will appear.
8. Choose Refresh
You'll see the renamed folder in the Folder View.

To Delete A Folder and To Delete Documents From A Folder :
Because askSam folders are generated from the field contents of your file, you cannot simply delete a folder shown in the Folder View window. To delete a folder, you will need to delete all the documents contained in that folder (or move the documents to other folders - see below for details on moving documents).

To Delete Individual Documents from a Folder:
1 Select the document you wish to delete.
2 Press the DEL key.
A message appears asking if you are sure you wish to delete the document.
3. If you're certain you wish to delete the document, choose YES.
The document is deleted from your file.

To Delete a Folder and all Documents in a Folder:
1 Choose DOCUMENT - DELETE OTHER - SELECTION...
The Search Dialog Box will appear.
2 Choose the FIELD button.
The Search in Field Dialog Box will appear.
3. In the "Find Word or Phrase" field, enter the name of the folder. For example, if you wish to delete all the documents in the "Marketing" folder, you would enter "Marketing".
If you wish to delete all documents in the sub-folder "Trade Show" under "Marketing", you would enter "Marketing\Trade Show"
4. In the next field, enter the name of your Folder Field (for example Category[).

5. Choose the OK button.
You will return to the Search Dialog Box.
6. Choose OK
A message will appear asking if you are sure you wish to delete the documents. All documents matching the search request you've entered will be deleted from your file.
7. If you are certain you wish to delete the documents, choose YES.
The documents will be deleted from the file, and the folder will also be removed.

To Move Documents to Other Folders:

To move a document to another folder, simply change the contents of the Field Folder in that document to the name of the folder where you want to move the document.
For example, the following screen shows a document that will be in the "Web Site" sub-folder in the "Marketing" folder:

To move this to the "Todo" folder, you would change the contents of the Category field from "Marketing\Web Site" to "Todo."

To Search Documents In A Specified Folder:
To search only documents in a specific folder, use the Search in Field Dialog Box.
1. Choose ACTIONS - SEARCH...
The Search Dialog Box will appear.
2. Choose the FIELD button.
The Search in Field Dialog Box will appear.
3. In the "Find Word or Phrase" field, enter the name of the folder. For example, if you wish to search the documents in the "Marketing" folder, you would enter "Marketing".
4. In the next field, enter the name of your Folder Field (for example Category[).

5. Choose the OK button.
You will return to the Search Dialog Box. You can now enter any other search options (search by word, date, proximity, etc.). These search options will only search the items in the folder you specified.
6. Enter the other search options.
7. Choose OK to start your search.

Right Click Document Options (Delete, Email, Export, ...)
When you right-click on a document in the Folder View, a menu will appear offering you the following options:
Delete - Deletes the selected document.
Email - Emails the selected document.
Remember - Places the selected document into the Active Remembered List. (See the description of Remembered Lists in the User's Guide for details).
Export - Exports the selected document (as text, RTF, HTML, or a new askSam file).
Print - Prints the selected document.
Properties - Displays the Properties Dialog Box for the selected document.

NOTES:
1. If you don't wish to see the Folder Field in your document, you can place it in the Page Header or Page Footer. In this case, the Folder Field will only display when the document is printed.
2. The Folder View is dynamically generated when you open your askSam file. In large databases, there will be a delay before the folders are displayed. You can work in your file while the Folder View is being generated.

3. Below are the keyboard shortcut keys.
CTRL+G opens the Folder View. If the Folder View is already open, then CTRL+G key will bring your focus back to the Folder View.
ESC or CTRL+Q moves you to the Search Line.
CTRL+SHIFT+Q moves you to the Search Results Window.
CTRL+W moves you to the Work Space (into the Document).
_

That's genious, in Information Management, or then, genius: ok. But aping German state official's card board filing "inventions" of their times, with providing, by electronic means, mere better access speeds, somewhat pales in comparison, don't you convene - no, not officially, in public, but just down deep, in your heart -, Lothar?

Hein, as the French say?