News:IMPORTANT MESSAGE! This forum has now been replaced by a new forum at http://forum.eastgate.com and no further posting or member registration is allowed. The forum is still accessible via read-only access for reference purposes. If you wish to discuss content here, please use the new forum. N.B. - posting in the new forum requires a fresh registration in the new forum (sorry - member data can't be ported).

The subtle syntax shifts (improvements!) from old export code-centric styles to action as the core syntax means a massive amount of review & update for aTbRef, so apologies that the new version is out yet. My aim is that it now won't use deprecated examples or concepts (even if they are still supported) - at least as primary examples - as this is most useful for both the new user and longer-term users wishing to update their knowledge. Much more work than I thoughts, so it may be weeks not days as I'm busy elsewhere, too.

Note that v4.6 will open all your pre-4.6 TBXs as new copies, this is to enable you to review/fix and broken syntax whilst leaving a 'clean' old copy in case you need to roll back. Eastgate's worked hard to support old usage where possible, but you may need tweak some of your queries and action codes. Export codes should continue to function as they did previously.

Mark, any good reference takes time. aTbRef is one I use every day, so it will be worth the wait.

Could I suggest that in the interim you or Mark B. post a guideline in the forum for what you believe the best practice is for performing a quick examination of a pre-4.6 document to ensure compliance with 4.6? I'm looking for the most likely 5 or 10 things in syntax that might need revision.

This won't be a very big deal for the overwhelming majority of users. As you can imagine, I myself use a bunch of Tinderbox documents, some very old, and some very tricky. Only one (my weblog) needed significant corrections, and that took perhaps half an hour. One or two others required a minor adjustment.

[This was drafted (too slowly!)m against the first post in the thread.]

Oh brother... it's simple in concept but wordy to explain. Most legacy stuff should still work (thanks Eastgate!), but the likely breakers are things that weren't quoted should now be quoted, specifically string values including simple operators */-+ (and probably a few more). For string/set attributes, literal values are quoted. Boolean and Number type values are not quoted. Color type values are quoted. Date type values, where they are strings (literal dates and format strings) are quoted.

An exception to quoting (apparent) strings is names/paths. $Color is this note's color. $Color(Some note) is the color of a note called 'Some Note'. $Color(Alumni/2001/Fred Smith) is the name of a note called 'Fred Smith' with the path from root of 'Alumni/2001'. We don't, by convention, quote names or paths (although it seems you can do so without problem).

Placeholder names - now termed 'designators' - such as child, parent, can now also use paths. $Name(parent(parent)) returns this note's grandparent's note name. I presume (untested) you can nest further, e.g. $Name(parent(parent(parent(parent)))) and such but I suspect doing so will make things run a bit slower and anyway shouldn't really be needed in real world use (i.e. there's likely a limit but you shouldn't encounter it).

Queries are now TB "expressions" - think of that as meaning action code. Indeed there are now new action code operators of all the #query codes, so #between(... becomes between(... otherwise changed except where the first point above indicates string parameters values may now need quoting. Apart from syntax within queries, the main impact of the change is a more unified use of code

In Action code (not Export code) we now $-prefix all attribute references both sides of the expression: $Color=$MyColor or $MyString="Krusty". There is one place attribute names aren't prefixed and that is in the query-like use attrbruteName(pattern). In the latter think of it as an action operator that executes a regular expression search for the pattern against the attribute whose name is used as the operator name. Thus generically we have a figurative operator op(regexp) and to search attribute MyString's value for one or more digits, we'd use MyString(\d+) or MyString(red) to match the syllable 'red'. To target a different attribute just use its name, e.g. MyOtherString(\d+).

Export code syntax remains unchanged - you don't need to quote text (except in a few where it's expressly requested such a creating link sets) and you don't need to $-prefix attribute names (again except if/wher. Note that ^value($MyString)^ equates to ^get(MyString^ and ^value($MyString(parent)^ equals ^getFor9parent,MyString)^ and ongoing best practice is to substitute action code for export code wherever possible.

If this all seems a bit wooly it's because Eastgate have pulled of revising a lot of stuff under the hood without breaking anything much in current docs. As v4.6 shakes down, I'd expect the boundary cases above to be clarified and where legacy support conflicts with new needs it will fall away so don't adopt a policy of no change.

Errors/omissions/ambiguities welcomed - please! Unless you want to discuss a point publicly I'd suggest using the email link for my sig to sent comments to me directly.

The syntax changes in v.6, whilst subtle on the surface, have necessitated a fair amount of updating and restructuring. We've more explicit string quoting, ^code deprecated outside the export context and queries now becoming action expressions. Although there's a bit of pain for existing users, I think these moves represent a real tidying of code that's going to make it easier for people to learn.

But, comments please! (I reserve the right to use English English spelling - outside code examples where US spelling matters e.g. $Color vs. $Colour <g>).

[If anyone eagle-eyed spots this is published with a beta, that's we've found some unintended consequences with very permissive export filenames & Windows servers (such as aTbRef lives on). You're unlikely to meet the issue unless you're using things like | and ! in your note names. Suffice to say a fix is in hand. The current content is based on v4.6.1]

Oops - good spot. I've re-exporting as as write. Fixed pages should be up within the hour. The glitch you report affects only Google searching - until fixed pages are up. [Done - hope that's now fixed]

I've also found some outbound lniks from included content aren't linking correctly though not sure why as yet.

Keep the input coming!

[NOTE, as yet there is no source TBX to download - I'm waiting for the new structure to settle first. If you simply must have a copy now, email me]

[Note: should now have fixed and issue with screengrabs being referenced from the wrong location.]

Image links fixed (more here) and ^ancestors^ format recovered. In v4.6. ^ancestor^ now default to an HTML bullet list like other list-generating codes. To recover the old format, you must add a format string like so: ^ancestors("",""," : ","")^

I noticed a few comments recently about peole 'discovering' stuff in aTbRef that been there for ages. I figured an outline of all the pages might help expose the depth of content (1500+ pages), so here's a site map page:http://www.acrobatfaq.com/atbref46/aTbRefSiteMap.html