Take Command v11 Public Beta Build 24 Uploaded

[rconn]

I've uploaded build 24 to the ftp and http (autoupdater) sites. This build should fix all of the reported bugs (with the exception of the Tk support).

 

[Jay Sage]

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

 

[Howard Goldstein]

Rex Conn wrote:

>
> I've uploaded build 24 to the ftp and http (autoupdater) sites. This
> build should fix all of the reported bugs (with the exception of the Tk
> support).
>

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

 

[rconn]

> ---Quote---
> >
> > I've uploaded build 24 to the ftp and http (autoupdater) sites. This
> > build should fix all of the reported bugs (with the exception of the
> Tk
> > support).
> >
> ---End Quote---
> 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?

I did, and fixed a problem with the zip library, and your sample works
perfectly here with UNZIP & build 24.

Rex Conn
JP Software

 

[rconn]

You seem to be adding 256 to all the codes when they are written out by
TCTOOLBAR.

WAD; the 256 means to use the new button format (including the tab title field) instead of the old.

 

[Jay Sage]

> 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

 

[rconn]

> > 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?

Can't say, since it works here. I'd have to see your toolbar file.

Rex Conn
JP Software

 

[Howard Goldstein]

Rex Conn wrote:

>
> ---Quote---
>> 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?
> ---End Quote---
> I did, and fixed a problem with the zip library, and your sample works
> perfectly here with UNZIP & build 24.
>

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

 

[rconn]

> 2. What is the /P option of Zip supposed to do when combined with /R?
> It seems to have no effect at all.

/R alone will put all of the files in the subdirectories into a single
directory in the zip file. Adding /P will save the path info for files in
subdirectories.

Rex Conn
JP Software

 

[Howard Goldstein]

Rex Conn wrote:

>
> ---Quote---
>> 2. What is the /P option of Zip supposed to do when combined with /R?
>> It seems to have no effect at all.
> ---End Quote---
> /R alone will put all of the files in the subdirectories into a single
> directory in the zip file. Adding /P will save the path info for files in
> subdirectories.
>

Definitely not what I'm seeing here. /R with or without /P saves path
information for subdirectories.

--
Howard

 

[rconn]

> Definitely not what I'm seeing here. /R with or without /P saves path
> information for subdirectories.

Definitely not what *I'm* seeing, but after further thought I decided to
remove /P altogether and have /R always save paths. I don't think /R
without the paths will prove useful.

Rex Conn
JP Software