Can you add another variable "itemchanged" to the item's "command line"?

[Spliff]

Before navigating off from the current item, or before copying / moving it, UR automatically SAVES the current item IF its content ("Item Details", "Item Notes") has been changed in any way (and if a periodic or manual (user-triggered) change hasn't occurred in-between that is). (This doesn't also apply to possible item title changes which are processed immediately.)

This automatic save "at leaving the item" takes some milliseconds, from just some to multiple ones; now my macros, both for navigation away to another, specific item, and for moving an item to another, specific location, first retrieve the current item's "command line" anyway, and that, albeit implicating the clipboard, works very fast, so this systematic command line retrieval doesn't "cost" too much.

On the other hand, and since the possible duration of a necessary "save" can't be determined "from the outside", i.e. by a user macro, the necessary "wait" for that "save" to proceed should not be too short, perhaps 1,500ms (which will cover most of such "saves" at least), and that IS a cost indeed: unavoidable IF there will be a save, but totally unnecessary if there will be no save in-between.

That's why, before sharing my macros, I would like to amend them a little bit in this respect, i.e. make them avoid that "wait" when there is no need for it.

That's why I would like them to retrieve some sysvar "the current item has been changed AND will need a save upon leaving it", short "item_is_changed" 1 (default = 0) or similar, inserting such an extended "wait" just if necessary, not systematically anymore.

(I don't know of course if this is technically possible, since I just suppose (sic!) that UR changes (from false/0 to true/1) some, already existent, sysvar "ItemHasBeenChanged" after any input, in order to then trigger the periodic save when it's time, and also, to trigger the save on leaving the item, but it's also possible that both saves are triggered anyway but do nothing if there has been no change in-between, in which case such a var might not already be present?)


EDIT:

I don't know how I could forget, since another sysvar, %ItemExpanded%, is even much more important in this context, since whilst some %ItemChanged" would be retrieved just once per macro, at its starting point, %ItemExpanded% would even to be retrieved several times, in order to avoid "waits" within the macros, or then to avoid wrongdoings - when the macro is "stuck" at some point / item, for insufficient "wait", then, for navigational purposes, it will just navigate to a non-intended target item, but if the same occurs within a "move" macro, the item to be moved will be moved to some non-intended position within the tree, which is even much more annoying, and in fact, it had been these malfunctions vs. unnecessary "waits", slowing down the macros too much for being "presentable" (when a macro takes as long as manual navigation would have taken, it becomes devoid of interest after all), which made me hesitate some weeks ago. (The pretty thing in this context being that if some higher-up parent item is not yet expanded, we know, without further check(s), that the deeper-down, intermediate targets are not expanded yet either.)

(Btw, your brilliant "expand by n level" commands have been very helpful here, too, already (in fact, the "expand by 1 level" variety), in view of the fact that the commands I had used originally, {backspace} and {right}, both work differently (sic!) upon an item, depending of it being expanded or not, making macros using those commands totally unpredictable and thus unreliable: These problems are resolved now, with "expand by 1 level" (instead of {right}, and by "go first sibling" (which had been available previously; by Alt-{home on my system}), and then "go 1 up" (just {up}), instead of {backspace}.)

[kinook]

Why not just save the item before executing the macro, either by typing Ctrl+S shortcut or by invoking the save command from the macro?

[Spliff]

Because, when a %CHANGED% (or similar) is 1/true, I'd do exactly that, AND I'd have to insert a (hopefully sufficient) "wait" in the macro (some 1500ms), before the next "real" command, whilst I (have to) retrieve the "command-line" anyway, its processing (= analysis of the retrieved string) then being immediate, an NO need for the (otherwise mandatory) "save" "wait" if the sysvar is 0/false. In other words, "save" is among the multiple commands where my AutoHotkey macros have to "wait" for, in order to not to "choke", whilst e.g., the programmatic creation of multiple new files, or multiple file renames and even moves, from within AHK, doesn't pose a problem; the creation of a new UR item (even while it's empty yet) HAS to be waited for by AHK, before further processing.

Ditto for %EXPANDED% (or similar): (Even unnecessary) "expanding" will cost time, while, if I don't allow for that time, the macros "choke". (It goes without saying that any ancestor of the current item, to be retrieved from the TitlePath of th current item, IS already expanded, so no "check" for a sysvar is needed for them, but the same is not also true for "lateral" paths, from the first child item below the bifurcation of the two paths down.

(What's missing, on my = the AHK side, is the availability of some system info, "system is busy" or the like, which could check IF a save is currently done, and "wait" only then. Btw, similar problems, in AHK, arise (and are discussed within the its forum) when a macro tries to retrieve quick changes of the the current window's caption: It systematically retrieves the previous values then, not the current one, so retrieval by other means (in UR: the "command line" sysvar) is both quicker AND much more reliable, even when it implies clipboard use, which in itself isn't that "reliable" to begin with - but as said, the UR "command line" is retrieved quite fast indeed, thankfully.)


EDIT:

This arises the question if I should switch to CharSearchMode 7, instead of 8, which would eliminate the "is_expanded_or_not" problem, and make those scripts (navigation = "go to" some item; move some item to ...) much simpler, and much quicker indeed; the problem being that currently, this is not a toggle, but a registry entry, changes upon which come into effect from the next UR run only.

When you introduced these additional CharSearchModes, I had briefly trialed #7 (since it had been my idea), but I then quite fast changed to #8, since in regular, day-on-day-off use, #7 had produced too many unwanted "hits":

item 1
item 2 (collapsed, but with children aitem, bitem, citem, sitem)
some other item

I'm on item 1, I enter "s", I want to go to "some other item", but #7 opens up sitem, within the sub-tree below item 2, no in "normal day" use, #7 is scarcely useful.

On the other hand, for my navigational, and move scriptlets, it'd be pure gold, since they, within a fixed naming structure (sic!), are meant to do exactly that: go to, or move to, precise, and even collapsed-out (their respective parents are collapsed, they themselves are thus collapsed-out, thus my "weird" wording here) target items: #7 would make this neat and fast.

Thus, a possible toggle, between TWO preferred CharSearchModes, one being the default (#8 in my case) and a special one (#7 for my scriptlets) would make those much more elegant, much less cumbersome indeed, but without constantly interfering in day-to-day character search, the one the user uses when they simply want to jump from one sibling to another one, within the immediate vicinity of = below the first one.

Unfortunately though, I think such a toggle will NOT be possible, since it (allegedly) affects the internal processing of the tree component (similar, btw, for the setting "wordwrap in tree" which would be individual for each db, instead of remaining the current setting for all DBs (which makes it more or less unusable since for most "things", the user allegedly wouldn't want it to be that way, just for some specific data).

As said before, with #7, my macros would become really elegant, which they currently (using #8) are not - all those "waits" in-between are really quite awful, for the "user experience" -, so I'm even considering to switch to #7 indeed (being ready to navigate "manually" from one item, to some sibling of it, just 5 or 8 positions further down... since, at the end of the day, that's what I need to do anyway, every time that sibling is 5 or 8 positions above the current one) if you can't make it a toggle between CharSearchMode1 (#8 for most users, I suppose), and CharSearchMode2 (secondary, to be switched on just for specific macros).

[kinook]

If you call SendMessage in AHK to perform the save in UR, that will not return until the save has completed, so a wait shouldn't be necessary.

SendMessage(WM_COMMAND, ID_FILE_SAVE)

WM_COMMAND = 0x0111 (273 decimal)
ID_FILE_SAVE = 0xE103 (57603 decimal)

https://ahk4.us/docs/commands/PostMessage.htm

I will consider what could be done about making the search mode dynamic.

[Spliff]

Oh, that's great news, I hadn't been aware of that, will try to implement!

Btw, all those CharSearchModes have a common glitch:

You enter t for example, to go to that, but before that comes this, so your first t goes to this; so far so good.

You then press t a second time, in order to get (from this) to that, but it's stuck at this, since the current item fulfills the condition.

I don't know if that's possible, but for CharSearch:

Can you make them go to the next (!) item fulfilling the condition (instead of it doing nothing (instead of reloading the current item it seems, judging from the flicker on screen then?), whenever even the current item fulfills the condition?

Of course, if the CharSearchMode allows for more than 1 char, and IF the user has seen the problem beforehand, they could have entered tha, in order to NOT getting stuck at this (here: even 3 chars needed, not "only" 2!), but in practice, the user will enter just a single t, and then, on this, will need to first press {down}, then t again, instead of just a second t.

This might ask for more code than it'd be worth then, I don't know, but it's a quite often recurring situation.

[kinook]

The char search functionality is implemented by the tree component and not by us and cannot be customized beyond what is already provided.