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

[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!