Button Parameter field eats double pipe
Moderators: white, Hacker, petermad, Stefan2
Button Parameter field eats double pipe
I have a program which gets two pathes separated by double pipe chars
Examples:
c:\temp\test||c:\temp\test2
%P%N||%T%M
In TC 9.51 this worked in a button as parameters.
In TC 10.00b1a it no longer works, it only delivers c:\test for the first simple example.
Examples:
c:\temp\test||c:\temp\test2
%P%N||%T%M
In TC 9.51 this worked in a button as parameters.
In TC 10.00b1a it no longer works, it only delivers c:\test for the first simple example.
Windows 11 Home x64 Version 23H2 (OS Build 22631.3593)
TC 11.03 x64 / x86
Everything 1.5.0.1376a (x64), Everything Toolbar 1.3.3, Listary Pro 6.3.0.78
QAP 11.6.3.3 x64
TC 11.03 x64 / x86
Everything 1.5.0.1376a (x64), Everything Toolbar 1.3.3, Listary Pro 6.3.0.78
QAP 11.6.3.3 x64
-
- Power Member
- Posts: 872
- Joined: 2013-09-04, 14:07 UTC
Re: Button Parameter field eats double pipe
Not confirmed.
The first example (c:\temp\test||c:\temp\test2) and second example (%P%N||%T%M) work the same in both TC 9.51 and TC 10.00b1a.
Did you perhaps re-configure the button for your TC 10.x tests?
Note that with such an argument, it matters what you invoke. If a batch script is invoked, "c:\temp\test||c:\temp\test2" without quotes will be truncated when using either TC 9.51 and TC 10.00b1 (obviously, as the commandline parsing in this case goes through cmd.exe).
If an exe is invoked, "c:\temp\test||c:\temp\test2" (without the quotes) will be passed on to the exe in the same manner for both TC 9.51 and TC 10.00b1 in my tests. (I used a simple batch script and a quick'n'dirty .NET program which output the arguments as passed to them.)
If your problem is not due to this difference in exe vs. batch invocation, could you share the complete configuration for the affected button, including the program you invoke?
The first example (c:\temp\test||c:\temp\test2) and second example (%P%N||%T%M) work the same in both TC 9.51 and TC 10.00b1a.
Did you perhaps re-configure the button for your TC 10.x tests?
Note that with such an argument, it matters what you invoke. If a batch script is invoked, "c:\temp\test||c:\temp\test2" without quotes will be truncated when using either TC 9.51 and TC 10.00b1 (obviously, as the commandline parsing in this case goes through cmd.exe).
If an exe is invoked, "c:\temp\test||c:\temp\test2" (without the quotes) will be passed on to the exe in the same manner for both TC 9.51 and TC 10.00b1 in my tests. (I used a simple batch script and a quick'n'dirty .NET program which output the arguments as passed to them.)
If your problem is not due to this difference in exe vs. batch invocation, could you share the complete configuration for the affected button, including the program you invoke?
Re: Button Parameter field eats double pipe
You are right, for testing with cmd I had to quote the parameter.elgonzo wrote: ↑2021-03-12, 14:08 UTC Not confirmed.
The first example (c:\temp\test||c:\temp\test2) and second example (%P%N||%T%M) work the same in both TC 9.51 and TC 10.00b1a.
Did you perhaps re-configure the button for your TC 10.x tests?
Note that with such an argument, it matters what you invoke. If a batch script is invoked, "c:\temp\test||c:\temp\test2" without quotes will be truncated when using either TC 9.51 and TC 10.00b1 (obviously, as the commandline parsing in this case goes through cmd.exe).
If an exe is invoked, "c:\temp\test||c:\temp\test2" (without the quotes) will be passed on to the exe in the same manner for both TC 9.51 and TC 10.00b1 in my tests. (I used a simple batch script and a quick'n'dirty .NET program which output the arguments as passed to them.)
If your problem is not due to this difference in exe vs. batch invocation, could you share the complete configuration for the affected button, including the program you invoke?
The real application is XYplorer.exe but with further testing using the old TC I found that there is the same problem.
The strange thing is that a similar parameter construct using QuickAccessPopUp to call XYplorer works.
The button is simple
Code: Select all
TOTALCMD#BAR#DATA
C:\Tools\XYplorer\XYplorer.exe
%P%N||%T%M
C:\Tools\XYplorer\XYplorer.exe
XYplorer
-1
Windows 11 Home x64 Version 23H2 (OS Build 22631.3593)
TC 11.03 x64 / x86
Everything 1.5.0.1376a (x64), Everything Toolbar 1.3.3, Listary Pro 6.3.0.78
QAP 11.6.3.3 x64
TC 11.03 x64 / x86
Everything 1.5.0.1376a (x64), Everything Toolbar 1.3.3, Listary Pro 6.3.0.78
QAP 11.6.3.3 x64
-
- Power Member
- Posts: 872
- Joined: 2013-09-04, 14:07 UTC
Re: Button Parameter field eats double pipe
I am not sure if that means you are still experiencing the problem. I just downloaded the portable version of XYplorer and used your button definition (with the path to XYplorer adapted, of course). I suppose the argument "dirA||dirB" tells XYplorer to open dirA and dirB in each of its two folder panes. As far as i my tests went, i didn't observe any issues, with the button working just fine in both TC 9.51 and TC 10.00b1a (unless my assumption about the purpose of the argument "dirA||dirB" is mistaken).
Re: Button Parameter field eats double pipe
Yes that what I doing.elgonzo wrote: ↑2021-03-12, 16:53 UTCI am not sure if that means you are still experiencing the problem. I just downloaded the portable version of XYplorer and used your button definition (with the path to XYplorer adapted, of course). I suppose the argument "dirA||dirB" tells XYplorer to open dirA and dirB in each of its two folder panes. As far as i my tests went, i didn't observe any issues, with the button working just fine in both TC 9.51 and TC 10.00b1a (unless my assumption about the purpose of the argument "dirA||dirB" is mistaken).
I also have a portable XYplorer installation with Double pane set as default.
The parameters with || where working in the past but I didn't use them since a longer time
and was now trying while doing the TC 10 tests.
I have the newest beta of XYplorer and I will try it with a fresh ini.
[Edit]
I found that it works when XYplorer is already running in the background.
IF not, only the first path is taken on its start-up, the other pane stays on the last used one.
The strange thing is that it works regardless of its state if invoked from QAP.
Windows 11 Home x64 Version 23H2 (OS Build 22631.3593)
TC 11.03 x64 / x86
Everything 1.5.0.1376a (x64), Everything Toolbar 1.3.3, Listary Pro 6.3.0.78
QAP 11.6.3.3 x64
TC 11.03 x64 / x86
Everything 1.5.0.1376a (x64), Everything Toolbar 1.3.3, Listary Pro 6.3.0.78
QAP 11.6.3.3 x64
-
- Power Member
- Posts: 872
- Joined: 2013-09-04, 14:07 UTC
Re: Button Parameter field eats double pipe
I double-checked again. Curiously, for me it doesn't matter if XYplorer is already running or not. It always works. It works the first time (when the evaluation notice pops up), it works when XYplorer is already running, and also when XYplorer has to be started anew. It also does not seem to matter here whether XYplorer had the two folders already open in a previous XYplorer session or not. Looking in the Task Manager at the commandline with which XYPlorer is being invoked, there is nothing unusual there to see, either. Me thinks there is some other contributing factor at play on your side, but i have no idea what.
P.S. Spam post above mine already reported.
P.S. Spam post above mine already reported.
Re: Button Parameter field eats double pipe
I found that it always works for me when I have 2 dirs in TC selectedelgonzo wrote: ↑2021-03-12, 17:51 UTC I double-checked again. Curiously, for me it doesn't matter if XYplorer is already running or not. It always works. It works the first time (when the evaluation notice pops up), it works when XYplorer is already running, and also when XYplorer has to be started anew. It also does not seem to matter here whether XYplorer had the two folders already open in a previous XYplorer session or not. Looking in the Task Manager at the commandline with which XYPlorer is being invoked, there is nothing unusual there to see, either. Me thinks there is some other contributing factor at play on your side, but i have no idea what.
P.S. Spam post above mine already reported.
but for many times I have selected 2 files in the TC panes and then the result is sometimes wrong.
I like the fact that YXplorer postions the cursor on the files if they are given as command line args.
Its the same behaviour as TC has.
Btw. I have removed that spam user.
Windows 11 Home x64 Version 23H2 (OS Build 22631.3593)
TC 11.03 x64 / x86
Everything 1.5.0.1376a (x64), Everything Toolbar 1.3.3, Listary Pro 6.3.0.78
QAP 11.6.3.3 x64
TC 11.03 x64 / x86
Everything 1.5.0.1376a (x64), Everything Toolbar 1.3.3, Listary Pro 6.3.0.78
QAP 11.6.3.3 x64
-
- Power Member
- Posts: 872
- Joined: 2013-09-04, 14:07 UTC
Re: Button Parameter field eats double pipe
Ah okay, that might explain it, as i only have tested with directories and never tried having a file path as part of the argument.
-
- Power Member
- Posts: 872
- Joined: 2013-09-04, 14:07 UTC
Re: Button Parameter field eats double pipe
Well, curiosity killed the cat and i played around some more. I can reproduce the problem here now, but it seems to be unrelated to directories vs. files.
It seems to do with quoting. Whenever one or both of %P%N or %T%M is being quoted by TC (if it contains special characters such as spaces), you'll end up with a commandline argument that is either "itemA"||itemB, itemA||"itemB" or "itemA"||"itemB". And XYplorer seems to have an issue with parsing such, leading to the result as you described when XYplorer starts anew.
That passing such arguments to a running XYplorer instance already works is probably some side effect of how exactly the second XYplorer instance passes the arguments to the first running instance, probably not using exactly the same code path as used to parsing and evaluating the commandline string for the primary instance (and either intentionally or accidentally sanitizing the commandline argument before passing it on to the primary instance).
It seems to do with quoting. Whenever one or both of %P%N or %T%M is being quoted by TC (if it contains special characters such as spaces), you'll end up with a commandline argument that is either "itemA"||itemB, itemA||"itemB" or "itemA"||"itemB". And XYplorer seems to have an issue with parsing such, leading to the result as you described when XYplorer starts anew.
That passing such arguments to a running XYplorer instance already works is probably some side effect of how exactly the second XYplorer instance passes the arguments to the first running instance, probably not using exactly the same code path as used to parsing and evaluating the commandline string for the primary instance (and either intentionally or accidentally sanitizing the commandline argument before passing it on to the primary instance).
Re: Button Parameter field eats double pipe
Thank for analysing, I'll make an problem report in the XYplorer.elgonzo wrote: ↑2021-03-12, 18:25 UTC Well, curiosity killed the cat and i played around some more. I can reproduce the problem here now, but it seems to be unrelated to directories vs. files.
It seems to do with quoting. Whenever one or both of %P%N or %T%M is being quoted by TC (if it contains special characters such as spaces), you'll end up with a commandline argument that is either "itemA"||itemB, itemA||"itemB" or "itemA"||"itemB". And XYplorer seems to have an issue with parsing such, leading to the result as you described when XYplorer starts anew.
That passing such arguments to a running XYplorer instance already works is probably some side effect of how exactly the second XYplorer instance passes the arguments to the first running instance, probably not using exactly the same code path as used to parsing and evaluating the commandline string for the primary instance (and either intentionally or accidentally sanitizing the commandline argument before passing it on to the primary instance).
Windows 11 Home x64 Version 23H2 (OS Build 22631.3593)
TC 11.03 x64 / x86
Everything 1.5.0.1376a (x64), Everything Toolbar 1.3.3, Listary Pro 6.3.0.78
QAP 11.6.3.3 x64
TC 11.03 x64 / x86
Everything 1.5.0.1376a (x64), Everything Toolbar 1.3.3, Listary Pro 6.3.0.78
QAP 11.6.3.3 x64