For portability reasons I start PSPad.Exe within Total Commander, using a
relative path in combination with a file to be opened for editing:

J:\Programme\Tools\Files\TotalCmd\..\..\..\Edit\Text\PSPad\PSPad.Exe
j:\Programme\Tools\Desktop\AutoHotkey\SmartGUI.ini

The first part of the PSPad-path is actually an environment variable which gets
resolved to a path: %COMMANDER_PATH% -> J:\Programme\Tools\Files\TotalCmd. But
it doesn't matter if Total Commander is involved for reproducing the bug.

Opening the _first_ file, everything works fine. PSPad gets started and the
correct file gets opened within PSPad.

Now I use the same mechanism to edit a _second_ file.
Precondition: PSPad is set to allow only a single instance of itself, so further
file should be opened as tabs:

J:\Programme\Tools\Files\TotalCmd\..\..\..\Edit\Text\PSPad\PSPad.Exe
j:\Programme\Tools\Desktop\AutoHotkey\Manual.htm

Now PSPad opens "Manual.htm" as _third (!)_ tab BUT prior to this, PSPad
generates an _second_ empty tab "PSPad.Exe" which shows a quirky path when
hovering the tab: "mme\Tools\Files\TotalCmd\..\..\..\Edit\Text\PSPad\". The path
seems to be the result of the way PSPad.Exe is launched.

When closing this useless tab, all further opened files using the previously
described way recreate this useless tab.

Even worse, if PSPad.Exe is located closer to the root of the drive, PSPad
REALLY opens itself in hex mode for editing.

CAREFUL! The bug won't show when opening a file this way:
..\..\..\Edit\Text\PSPad\PSPad.Exe
j:\Programme\Tools\Desktop\AutoHotkey\SmartGUI.ini

So there seems to be a bug when starting PSPad by using a path that
_begins_ with _absolute_ adressing
(J:\Programme\Tools\Files\TotalCmd\) but _then_ uses _relative_
adressing (..\..\..) to go back to a certain path level to finally point to the
correct directory (\Edit\Text\PSPad)

>From Windows' point of view there should be no problem with such addressing
mechanisms and every other editor I tried (PlainEdit, Notepad++) opens files
correctly the described way.

I guess there is a problem in the way PSPad handles command line parameters.
Probably the first parameter is the PSPad-call itself
(J:\Programme\Tools\Files\TotalCmd\..\..\..\Edit\Text\PSPad\PSPad.Exe). And that
one maybe gets splitted by the command line analyser of PSPad into two
parameters?!

-- 
<http://forum.pspad.com/read.php?4,47936,47936>
PSPad freeware editor http://www.pspad.com

Odpovedet emailem