How to refer to selected item?

[Stef123]

Let me emphasize "selected" - not necessarily "selected AND focused".
<curitem> often does not cut it, it only fires if the item is focused as well. What I can't find is the equivalent to <focitem>, but giving preference the other way round. It should favor selected over focused.

[admin]

Many items can be selected. Which one do you want?

[Stef123]

The first one that got selected before the others joined him. If that's how it's usually done in Windows, unless you disagree?

[admin]

AFAIK in Windows the first is the focused AND selected one. If none such then it's the first from top of the list.

[Stef123]

Maybe it helps to explain the circumstances.
Have become addicted to using Ken's custom context menu. But still struggling with the very unusual selection & clicking process - first left click, then move out, then right-click on white ..... Don't even want to adopt this habit, as it will make me lose my selection in other apps.

So I've been trying various other approaches. One was provided by Sammay - for very easy selections you can do almost the same as in other programs = one single right-click on your selection. Only that now I have to right-drag into the file, then slightly out of it ... it's tricky but it sometimes works - and sometimes it won't work at all. NOT AT ALL. This drove me nuts until I finally discovered the reason: The context menu script uses <curitem>

However, when you right-drag-select, the focus will stay at some podunk location, way down in list view, wherever the last focus happened to be. And so I figured if I replaced Ken's <curitem> with a not-yet existing <selitem> I could pull it off. That's what I need it for: SELECTED but NOT necessarily focused.

[admin]

So there is only one selected item. A new variable <selitem> could handle that I guess. Returns like this:

Code: Select all

if foc+sel
  = this item
elseif 1 sel
  = this item
elseif many sel
  = top selected item

[Stef123]

Yes, that seems about right .... or so I guess
Again, the main point being that it doesn't mind if other non-selected items steal away the focus, thereby rendering <curitem> helpless.

[admin]

Code: Select all

        Situation               <selitem>
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        0 selected              Nothing.
        1 selected              Selected item.
        >1 selected
          one of them focused   Selected and focused item.
          none of them focused  First selected item from top.

I'm unsure about the last fork. Would it be better to totally ignore focus? Would be much simpler then:

Code: Select all

        Situation               <selitem>
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        0 selected              Nothing.
        >0 selected             First selected item from top.

[Stef123]

Well, judging from my present level of "expertise" I'd go with the simple solution. Although giving preference to focused + selected sounds very reasonable, too. Cannot make an accurate assessment - this takes someone who knows more about the dynamics of focusing, I just happened to stumble upon it.

I am fine with either way.

[admin]

I'll go for simple. After all its called "<selitem>".

[Stef123]

Thanks.

ed.
Now it works ... almost. The menu comes up correctly, but further processing also requires <selext>. To see why <curext> does not suffice, select one item, then select a different one by right-dragging into it. ::echo "<curext>"

[Stef123]

Not sure if my wish for <selext> crossed the radar threshold? It lost some of its importance because of an alternative I had not been aware of, but still - might be useful to have it anyway, to complement <selitem>

[admin]

Yes, edited posts can go unseen. I'll think about <selext>...

[Stef123]

Thanks for considering ...

[admin]

Try this:

Code: Select all

echo getpathcomponent(<selitem>, "ext");

It's not efficient to add too many variables.