Which value(s) for $EndDate?

Thanks for pointing that out. I read up on that now and things have become clearer! much appreciated!

@mwra thanks for the ever paint elaboration! I tried the following in the agent query $Urgent==true which fetches all the ones marked Urgent. then I applied this action

if ($Urgent==true){$Color="red"}; else {$Color ="cyan";};

no joy… does it not work because as soon as urgent is unticked, the note is removed from the agent and the else argument is not reached so to speak?

cheers for the input!! have a great weekend!

I see a typo in your code, the first semicolon is after the first closing curly bracket. It should come before it. Thus, with code slit out for clarity:

if($Urgent==true){
   $Color="red";
}else{
   $Color ="cyan";
};

The .locisng semicolon on the last line is option if not other code follows. But is some other action followed, the semicolon is needed. Also Tinderbox generally is ifnored around control characters. however, to clarify intent, I think

if(query.){code}else{code}`

is much less ambiguous than, for example,

if (query.) {code} else {code}`

In the former, I think it is more intuiting that the condition and code apply to the if command (including its optional else branch). Generally, for anything other than the simplest of codes, I also use line breaks to show more clearly what code 'belongs to which branch and—where nested conditional test are used the opening/closing [ } are correctly placed, so:

if(query){
   code
}else{
  code
}

As regards semicolons, this is fine:

if($HasSomeValue==true){
   $Height = 2
}

but if there are two discrete actions, e.f. setting two different attributes, at minimum the first expression must end in a semicolon regardless of line breaks:

if($HasSomeValue==true){
   $Height = 2;
   $Width = 4
}

Separately, if code folows the if a semicolon is needed as the whole if(){} is treaded as an expression:

if($HasSomeValue==true){
   $Height = 2;
};
$Badge = "ok";

Because I’m generally writing for non-exports my examples (unless I forget!) are verbose including semicolons after all expressions:

if($HasSomeValue==true){
   $Height = 2;
   $Width = 4;
};

This makes it clearer if line breaks are omitted:

if($HasSomeValue==true){$Height=2;$Width=4;};

or where there is an else branch:

if($HasSomeValue==true){$Height=2;$Width=4;}else{$Height=3;$Width=6;};

In the latter case, the semicolon only goes after the final } closing the else branch of the if() statement.

Also, you need to scope you queries. You don’t want to check all notes but—in this case I think—your task notes. For the latter I believe you use the built-in prototype “Task”.

If you want to check all tasks, you need a query that matches all tasks, e.g.:

$Prototype=="Task"

This finds all (and only) notes whose prototype is set to 'Task" regardless of urgency. Then use that agent’s action to do the selective work:

if($Urgent==true){$Color="red";}else{$Color="cyan";};

As the action is run separately on every current alias in the agent, non-urgent (Task) notes do match the else branch in the action (I just confirmed this in v9.2.1):

Does that help?

1 Like

Hi Mark,

this is extremely helpful and clarified loads of things. Also, it now works and gives me insight in syntax as well! I will now see where the knowledge takes me as I expand my UserAttributes during the course of my planning.

As a side note: I think I can supercharge my academic research TBX files with my new-found knowledge of OnAdd (hopefully) and conditional formatting… will put this is another post.

Lastly, I enlarged my Agents area in map-view to display more notes matching the query. Is there a way to force the agent to position the matching notes in a way that they are visible in the agent/container preview on the higher level? (I hope I am making sense?)

thanks for taking so much time, Mark.

2 Likes

Yes, see Container viewport is scrollable and Viewport detail in containers & agents.

OK, read those articles. I have figured out that you can adjust the container viewport appearance by $MapScrollx/y. But these aren’t fixed; if I double click in the container and am a bit careless it changes (as expected)… any way to fix this or update it to 0/0 when children are present? Am a bit worried about adding too many rules. Is the way newly added notes are arranged in a container predetermined or is there an attribute for that as well?

Thanks for accompanying me on this leg of my, albeit scattered, journey.

Perhaps a container rule:

$MapScrollX=0;
$MapScrollY=0;

I don’t think it makes much difference to check for children, but this is how to do that:

if($ChildCount){
   $MapScrollX=0;
   $MapScrollY=0;
};

If to aggressive (i.e. running on lots of containers, make the code an edict or even a stamp).

Before you ask, it is not possible for the user to make an attribute read-only (i.e. fixed valued).

1 Like

I don’t know if this is of any help to the original poster, but it might be worth noting that there is the “$ReadOnly” system attribute that makes all attributes for a particular note unmodifiable (i.e., read-only). I have found the $ReadOnly attribute to be quite useful in practice. If it is included in $DisplayedAttributes, then it is easy to toggle modifiability of note attributes on the fly with just a click.

As an example, I use this feature to prevent unintended modification of Action Code, especially for Stamps and Functions. However, the $Text attribute has an odd behavior where setting $ReadOnly to true (checking it) does not prevent modification of the contents in $Text until some other note is selected and then $Text for the note where $ReadOnly is set to true will become unmodifiable.

@mwra—The current description of the $ReadOnly system attribute in aTbRef does not comport with my observations of the actual behavior. In particular, $ReadOnly seems to affect all attributes for the corresponding note, not just $Text. In other words, after setting $ReadOnly to true, all attributes of the corresponding note become read-only, with the exception of the $ReadOnly attribute (thankfully :grinning:).

It may be the case that behaviour has changed over time† ‡; likely my note was written pre-the v6 app re-write and changes weren’t noticed documented. I’d need to get an update from @eastgate (currently travelling) on the status. $ReadOnly certainly doesn’t affect all attributes. A read-only note can be move, re-sized and have it’s colour changed ($Xpos, $Width, $Color, etc.). Displayed Attributes Table editing is affected, though $ReadOnly can be edited when displayed as a Displayed Attributes.

I think the current $Text behaviour is probably not intentional, in terms of a charged $ReadOnly status in the Displayed Attributes table not _immediately affecting the $Text edit state.

But the range of attributes /features affected other than $Text clearly need re-documenting (and testing).

†. People use Displayed Attributes a lot more now than in the early days of Tinderbox (when Displayed Attributes were called Key Attributes).

‡. I think the original intent was to stop the user editing the text of note’s whose text was being set via AutoFetch. Thus if the user edited text, the edit would be lost when autofetch next refreshed.

1 Like

@mwra—Your additional comments are most noteworthy. I agree that it would be helpful to document any attributes that are not covered by the $ReadOnly setting. Some are probably obvious, but given that the original purpose of $ReadOnly has obviously changed over time, it might be best to get a definitive response from @eastgate as to which attributes remain modifiable when $ReadOnly is true. There are a lot of system attributes these days.

I am finding $ReadOnly to be a very useful feature, and one that I am making considerable use of in my projects. As an example, I have modified the “Action” prototype (as well as my related “Function” prototype) to display the $ReadOnly attribute, thereby making it easy to protect my code when I’m not intentionally modifying it. In addition, it is very useful for other notes that contain imported elements, since, once imported, I rarely want to modify such notes.

Perhaps this topic is worth discussing in a new posting.

The base assumption, FWIW, is that $ReadOnly applies to user interface activities but NOT to internal processes or to actions. This chair is too small and uncomfortable to permit source code examination right now; sorry!

@eastgate—I’m just seeing this, but I had independently performed some tests, and discovered just what you said here. Namely, that Action Code can modify attributes for a Note, even if the $ReadOnly attribute is set to true.

I do understand the logic behind this, and I can appreciate the utility. In fact, what had me digging into this deeper was that I was thinking about some situations where I wanted code to be able to modify attributes for a note where $ReadOnly was true. So, in a sense, the way things now work is just what I want for what I’m doing. The only real issue is that the current behavior is not documented correctly.

Rather that pile more on @mwra 's plate, I’ll send him a suggested description of how $ReadOnly works. The only tricky part is identifying which system attributes do not honor $ReadOnly’s setting. It’s probably obvious, but probably should be confirmed.

1 Like

Thanks for your input and pointing this out. I am in the process of moving house but will definitely give this a go ASAP.

Stay safe everyone,

Cheers, Doc C