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.

[Spliff]

Thanks for checking though. ;-)

[Spliff]

I had never touched post/sendMessage in AHK; it opens up totally new possibilities indeed, thank you very much!

I happily confirm that
sendmessage, 273, 57803,,, ahk_exe UltraRecall.exe
works as you promised (=saves the current item if needed, without needing any "wait" allowance), and that's extremely helpful!

My current "navigation" problem is now to "find" - in fact, I kindly ask YOU to find it for me=us if such a thing exists! - similar code for "expand current item by 1 level" OR (even less probable) for "CharSearch" (incl. CharSearch being finished, then incl. the parent expansion, done by mode 7 after the target's find).


To explain a little bit: My system relies on (hierarchical) "markers" (you might call them "constructors") which, for the higher-up levels within a tree / db, somewhat "replace" / "mimic" the folder hierarchy within a file system; navigation (for viewing, or for moving/copying items) is then possible "several steps at once", as far as the user input is concerned, but has to be done, technically, every step one after another, since:

I have to do it "from the outside", so these "markers" are within item titles (i.e. I can't address the IDs), and are traveled to by CharSearch, top-down, CharSearch is also used, as last step, after some of the (earlier) travels, to common parent items (identified by the item-path-titles), will have done bottom-up (and in which case those common parent items are obviously expanded already).

I had used CharSearchMode 8, with lots of "waits" and/or "choking" of my macro, i.e. when the wait for the necessary expansion is not long enough, you find yourself at some unwanted "target" position, which for viewing isn't that desastrous, but if you apply such an unreliable macro to move items, you'll create chaos, obviously.

Thus, applying CharSearchMode 7, at first sight, seemed to be better suited (see my post above), since it also finds those title start chars for hidden items, but then, after having found the item, it invariably expands the item's parent item, in order to display the item: thus, in the end, mode 7 does not save any (!) expansion, it just automatically expands the sub-list after the search, instead of the macro expanding it previous to the search.

Iin this context, it should be noted that mode 7 would have become my mode of choice if I had been able to devise a "deep markers" char-search, i.e. one where one single, multiple-char char-search would have searched a compound marker deep-down, but that's not possible, so my macro has to combine several char-searches, one after the after, which then causes the problem of necessary waits even for intermediate expansions-to-be-finished, before the macro can savely trigger the next char-search.

Thus, it now becomes evident for me that mode 7 has no advantage over mode 8 with respect to my navigational (viewing/moving) scripting, BUT is has no disadvantage over it either in this respect*, so if either "CharSearch, to be finished" (incl. automatic expansion, triggered by the CharSearch in mode 7) OR (more probably successful?) "Expand current item by 1 level, to be finished" can be controlled in this respect by some "sendmessage", I'll be happy with either solution, and I could present a fast AND reliable macro for either alternative.

*=In general use though, mode 7 would probably cause many more unwanted "finds" than mode 8 does, I suppose.

[kinook]

To expand the selected item, it's

SendMessage(WM_COMMAND, ID_TREE_EXPAND)

WM_COMMAND = 0x0111 (273 decimal)
ID_TREE_EXPAND = 0x7D16 (32022 decimal)

For collapse, it's

SendMessage(WM_COMMAND, ID_TREE_COLLAPSE)

WM_COMMAND = 0x0111 (273 decimal)
ID_TREE_COLLAPSE = 0x7D17 (32023 decimal)

A complete list of commands is attached.


The char search functionality is implemented by the control handling keypress events and there isn't a specific command for it.

[Spliff]

Absolutely tremendous, thank you so much, that's more than constructive!

I'll check all this thoroughly! It's not a real API yet, but the main problem with external macroing being those awful "waits" in-between, always too short or unbearably long, being able to do away with (most of) those is an incredible jump forward!