Take Command v11 Public Beta Build 24 Uploaded
- Thread starter rconn
- Start date
There is still an issue with the TCTOOLBAR command. I tried running
tctoolbar /w tctoolbar.cfg
There was a pause, as if something were being written, but the file did
not exist in the current directory. When I ran
tctoolbar /w c:\temp\tctoolbar.cfg
the file was found in the temp directory.
A scan of my entire hard drive turned up another one in the default home
directory of my TCC configuration. This looks like a bug to me. I would
expect the file to be written to the current directory if no target
directory is specified.
Even the command
tctoolbar /w .\tctoolbar.cfg
writes the file to the default directory rather than the current directory.
I can confirm that the format of the file has been fixed. I'm still
puzzled, however, by the flag values stored. The help file for the
TCTOOLBAR command says:
The flags parameter specifies what happens when you click
the button. If flags is 0, Take Command will use command to
start a new tab (or a new window if command is a GUI app).
If flags is 1, the command text (in KEYSTACK format) is sent
to the current tab. If flags is 2, the button will change
the default directory in the Folders view. You can
optionally add 4 to the value of flags to insert a separator
before the button.
You seem to be adding 256 to all the codes when they are written out by
TCTOOLBAR.
-- Jay
tctoolbar /w tctoolbar.cfg
There was a pause, as if something were being written, but the file did
not exist in the current directory. When I ran
tctoolbar /w c:\temp\tctoolbar.cfg
the file was found in the temp directory.
A scan of my entire hard drive turned up another one in the default home
directory of my TCC configuration. This looks like a bug to me. I would
expect the file to be written to the current directory if no target
directory is specified.
Even the command
tctoolbar /w .\tctoolbar.cfg
writes the file to the default directory rather than the current directory.
I can confirm that the format of the file has been fixed. I'm still
puzzled, however, by the flag values stored. The help file for the
TCTOOLBAR command says:
The flags parameter specifies what happens when you click
the button. If flags is 0, Take Command will use command to
start a new tab (or a new window if command is a GUI app).
If flags is 1, the command text (in KEYSTACK format) is sent
to the current tab. If flags is 2, the button will change
the default directory in the Folders view. You can
optionally add 4 to the value of flags to insert a separator
before the button.
You seem to be adding 256 to all the codes when they are written out by
TCTOOLBAR.
-- Jay
Rex Conn wrote:
UNZIP doesn't see the last several files in the archive, and I've seen
situations where ZIP /R /P doesn't store all the path information and
produces zip files that are almost double the size they should be. Did you
receive the sample I emailed you last week?
--
Howard
Rex, I'm still having problems with ZIP/UNZIP. I have a file here where
UNZIP doesn't see the last several files in the archive, and I've seen
situations where ZIP /R /P doesn't store all the path information and
produces zip files that are almost double the size they should be. Did you
receive the sample I emailed you last week?
--
Howard
WAD; the 256 means to use the new button format (including the tab title field) instead of the old.
> WAD; the 256 means to use the new button format
> (including the tab title field) instead of the old.
OK, but why does reading in the file using TCTOOLBAR /R that was written
out using TCTOOLBAR /W cause the toolbar to be completely messed up?
-- Jay
> (including the tab title field) instead of the old.
OK, but why does reading in the file using TCTOOLBAR /R that was written
out using TCTOOLBAR /W cause the toolbar to be completely messed up?
-- Jay
Rex Conn wrote:
is working better now too, but I still have a couple of issues:
1. when using Zip /R, files whose names have no extensions and which are
located in folders below the specified source folder are not included in the
archive. For example, if I said
zip /r \dir1
file dir1\dir2\noext would not be included.
2. What is the /P option of Zip supposed to do when combined with /R? It
seems to have no effect at all.
--
Howard
OK, I'm using build 26 now and the sample I sent you unzips properly. Zip
is working better now too, but I still have a couple of issues:
1. when using Zip /R, files whose names have no extensions and which are
located in folders below the specified source folder are not included in the
archive. For example, if I said
zip /r \dir1
file dir1\dir2\noext would not be included.
2. What is the /P option of Zip supposed to do when combined with /R? It
seems to have no effect at all.
--
Howard
Rex Conn wrote:
information for subdirectories.
--
Howard
Definitely not what I'm seeing here. /R with or without /P saves path
information for subdirectories.
--
Howard
Similar threads
