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

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