New variable or Get parameter: PFA Items

[TheQwerty]

Code: Select all

v15.00.0119 - 2015-03-21 09:54
    * File | Open Selected Item(s): Experimentally changed the behavior of this 
      core function, i.e. what happens on pressing ENTER on selected list items.
      Before, if more than one item was selected then the items were opened one 
      after the other with each item's associated application (be it XY- or 
      OS-associated), even if all items were opened by the same application.
      Now all items are opened in one call if they are of the same type and 
      hence share the same associated application.
      The new behavior is analog to the selecting the bold default item (if 
      there is one) in the "File | Open with..." popup menu.

Since that change the <pfaitem> variable can no longer be entirely trusted because we have two possible outcomes:

1) Each selected item is opened separately.
Thus <pfaitem> is the item used for PFA matching and the item to open.

Occurs when any of these is true:

• Pre-v15.00.0119
• When only one item is selected.
• When multiple items of differing types are selected.
• The user enables the (unmarked) OpenAllSelectedInMultipleInstances tweak.

2) The selection is treated as one.
Thus <pfaitem> is the item used for PFA matching (either the current item or the first in the selection ).
But <selitems> or Get('SelectedItems...') must be used to determine the items to open.

Occurs when ALL of the following are true:

• Post-v15.00.0119
• Multiple items are selected and are all of the same type.
• The user has not enabled the OpenAllSelectedInMultipleInstances tweak.

The problem is... previously we could use <pfaitem> as the item to open, now we cannot.
Now we must perform our own check on the selected items and if they are all of the same type use the selection, if not we use <pfaitem>.


Hence, I'd like to see a new variable or Get parameter: pfaitems
Such that:
<pfaitem> always equals the item used for matching.
<pfaitems> always equals a list of items to open.

[TheQwerty]

It's worse than I thought thanks to File | Open Focused Item (#162) and POM.
There is no way for scripts to determine which item(s) the user actually wants to open.

POM made it possible for long to open the selection as a single group/instance regardless of types. <pfaitem> has always been a single item, and did not work well with POM (better off using the selection). Since v15.00.0119 the default behavior for the more common Enter/Open Selected Item(s) made it possible to open multiple items via PFA - extending the <pfaitem>/POM weakness further.

For legacy reasons <pfaitem> should be left as-is (or deprecated), but documented as "The item used for PFA matching."

Going forward we definitely need a new variable/get parameter which is a list of the items actually being opened.

[admin]

Next beta has <pfaitems>. Try and see if it works...

[binocular222]

This PFA is unreliable:

Code: Select all

{:Media}>::echo <pfaitems>

when select only few items, it always execute only once, but if I select a lot of items, it trigger multiple times:
- The first times, it returns <pfaitems>
- Subsequently, it return <pfaitem> each times

There's no clear cut how many items is "a lot", but it seems about >20.
Only happens with {:Media}, not happens to {:Text}

[bdeshi]

All of this became horribly unreliable since the introduction of OpenAllSelectedInMultipleInstances.

[admin]

This PFA is unreliable:

Code: Select all

{:Media}>::echo <pfaitems>

when select only few items, it always execute only once, but if I select a lot of items, it trigger multiple times:
- The first times, it returns <pfaitems>
- Subsequently, it return <pfaitem> each times

There's no clear cut how many items is "a lot", but it seems about >20.
Only happens with {:Media}, not happens to {:Text}

Yes, .

It's not the number, it's whether it's mixed types or all the same type.

[FluxTorpedoe]

Hi’
Previous fixed, but Ooops…
With the latest .0130 <pfaitems> fix, opening X different items now returns X times the full whole list;
but double-clicking on a single item now returns an empty string…


Edit — to whom it might concern / interest:
It may be interesting (though somehow inconsequential) to note an ordering difference between <selitems> and <pfaitems>.
— <selitems> returns the list of items as they appear in the list view, regardless of the focused item.
— <pfaitems> returns the list of items in a different order depending on the focused item.

[admin]

- double-clicking on a single item now returns an empty string: bug indeed
- the list order in <pfaitems> is as Explorer orders the items when opening multiple items: from focused item down to end, then from top down to one-before-focused

[TheQwerty]

With OpenAllSelectedInMultipleInstances=1 or a selection of differing types <pfaitems> contains all items instead of just the one being opened.

[TheQwerty]

All looks good in v15.70.0131.

[FluxTorpedoe]

All looks good in v15.70.0131.

Yep! Even with OpenAllSelectedInMultipleInstances=0.

Thanks!
Flux

---------------------------
So, to sum things up, when opening:

• Single item:                    <pfaitems> = <pfaitem> = Full path of selected item    —  One return
• Several similar items:    <pfaitems> = Full list of all selected items                     —  One return
• Several different items: <pfaitems> = <pfaitem> = Full path of a single item     —  Several returns (one for each item)

---------------------------

[TheQwerty]

I recommend avoiding the temptation to think about this in terms of the selection.
Doing so makes it too easy to write a PFA script which will not work as expected when called via other open methods.

This does make it difficult to follow the logic in a nice table, but the flow chart isn't too bad:

XYplorer-OpenFlow.png

EDIT: And I realize there's a small lie there, since POM with a single item selection is technically single item in single instance, but that makes things really ugly and behaves no differently.

[FluxTorpedoe]

Wicked!!!

[admin]

Mon dieu!