TC-tree...

[MBaas]

TC-tree (and debugger)

I might be doing something wrong here or maybe I have missed something in the doc, so I'd like to discuss a few things and see if these are 'real' feature-requests or more issues of RTFM or (ab)usage ;)

1. I often find myself wishing the current TC-Tab would CD into the directory that has been opened in the tree. Been thinking an internal variable ("treepath") or so might help in setting up an alias linked with a keystroke - but could not find anything in that direction. Surely others must have had similar requirements?
2. And syncing in the other direction is interesting as well (display current dir from tab in tree and file-pane).
3. Upon creating a new directory in a TCMD-tab, the tree did not display that directory and I did not find a way to update the tree (I used simple MD c:\foo, no switches)
4. I have experimented a bit with the debugger (which I find very useful) and found a few issues:
   1. single-stepping through code, I found that the statement to be executed next is highlighted in yellow. That is always true, except for a set-command that uses %@select, where the select comes up while the previous statement is still highlighted...(see screenie)
   2. I like watch and environment, but one thing would make it even more useful: a simple dropdown in the environment-tab which would give options to restrict the display to the "red variables" (changed since last command) or to those that were "accessed" (read or write) by the running batch. (Or otherwise add these to the 3d tab "batch variables")
   3. right-clicking a var in env-tab could also popup a menu-option "Add to watcher" (1st tab)
   4. And finally I would like an option in the context-menu of BTM/CMD/BAT to "Open in TC-Debugger". I tried (not too intensively, I admit) to give it a go myself with the inspiration of the existing batches, but could not quite work it out...

Any feedback appreciated :)
Thanks

Michael

 

[Charles Dye]

Re: TC-tree (and debugger)

1. I often find myself wishing the current TC-Tab would CD into the directory that has been opened in the tree. Been thinking an internal variable ("treepath") or so might help in setting up an alias linked with a keystroke - but could not find anything in that direction. Surely others must have had similar requirements?
2. And syncing in the other direction is interesting as well (display current dir from tab in tree and file-pane).

alias here=cdd /t .
alias there=if "%_tcfolder" ne "" cdd "%_tcfolder"

And finally I would like an option in the context-menu of BTM/CMD/BAT to "Open in TC-Debugger". I tried (not too intensively, I admit) to give it a go myself with the inspiration of the existing batches, but could not quite work it out...

Here's my file-associations batch: http://www.unm.edu/~cdye/dl/RegTweaks.btm

If you allow it to add Take Command to the context menus, then it will also create a 'Debug' verb for batch files.

 

[MBaas]

Re: TC-tree (and debugger)

Thanks Charles, that's cool! :)

BTW, there is a problem with the localization of the file - it doesn't work in germany! (Or better: on the german locale. Or for that matter: on any locale that doesn't use decimal point!)

*if %_4ver lt 7.0 goto bad_version

This condition is met when I execute here! 7,0 would work or just 7 works as well. But there is a 9.01-check a bit later, so just ommitting the decimals doesn't do it either.
Ah, but there's the OPTION-Command which should probably be used at the start of the batch to set comma=. and thousand=, - and I wanted to show that full command now (as a little thank you for your help), but I couldn't figure out how these beasts are named, as optional decimal complains about decimal being an unknown option. How does one get the correct value then? ("decimal" was shown in the "Advanced" ini-directives (iniadvanceddlg.htm)).

Unfortunately I had some urgent work to do to make client happy, so couldn't continue my investigations, but I intend to execute regtweak successfully once and I look forward to the debugger in ctxt-menu :)

I'm on Win7-65, TCC11x64 - and just doing replace on . and , did not let the script run through. Also it did not execute so nicely when launched from a TCMD-tab. Sorry for being so short on time, would have loved to document this more fully, but just cannot afford to do right now :(

 

[Steve Fabian]

Re: TC-tree (and debugger)

| Thanks Charles, that's cool! :)
|
| BTW, there is a problem with the localization of the file - it
| doesn't work in germany! (Or better: on the german locale. Or for
| that matter: on any locale that doesn't use decimal point!)
|
| *if %_4ver lt 7.0 goto bad_version
|
| This condition is met when I execute here! 7,0 would work or just 7
| works as well.

Yes, Charles could make that change to

*if %_4ver lt 7 goto bad_version

Alternately, the test could be moved after the SETDOS command.

| But there is a 9.01-check a bit later, so just
| ommitting the decimals doesn't do it either.

The SETDOS command in the code already selects the US decimal and thousands
characters, so it should be OK everywhere thereafter.

| ...
| just doing replace on . and , did not
| let the script run through.

You don't need to do that.
--
HTH, Steve

 

[Charles Dye]

Re: TC-tree (and debugger)

Thanks Charles, that's cool! :)

BTW, there is a problem with the localization of the file - it doesn't work in germany! (Or better: on the german locale. Or for that matter: on any locale that doesn't use decimal point!)

*if %_4ver lt 7.0 goto bad_version

*face in keyboard*

You'd think I would learn; Klaus Meinhardt pointed out an identical error in an earlier script. Change the 7.0 to 7 and it should work okay.

 

[MBaas]

Re: TC-tree (and debugger)

Thank you, Charles and Steve, very helpful - for several reasons.

I've been thinking all the time (and seemed to remember from ol' 4Dos-times) that there was a way to have "local" env-vars when executing a batch. But for the life of me I couldn't remember. And searching the index for "local" was not helpful either. But your btm uses setlocal - which has put me on the track ;)

But now, as a humble amateur, may I ask you pros: why all this "tweaking with symptoms" instead of just moving the instructions around setlocal etc. to the beginning of the script, so that everything else can remain unchanged?

What do you guys think about #3 from my initial post - is that something for a bug report, or a user error? ;)

 

[Steve Fabian]

Re: TC-tree (and debugger)

| Thank you, Charles and Steve, very helpful - for several reasons.
|
| I've been thinking all the time (and seemed to remember from ol'
| 4Dos-times) that there was a way to have "local" env-vars when
| executing a batch. But for the life of me I couldn't remember. And
| searching the index for "local" was not helpful either. But your btm
| uses setlocal - which has put me on the track ;)

When searching for a concept, you should use SEARCH, not index. INDEX is
based on the set of keywords the author of HELP thinks of to mark each page.
SEARCH is global, and matches not only whole words but also words that
include the search string,so that SETLOCAL is a match for LOCAL.

| But now, as a humble amateur, may I ask you pros: why all this
| "tweaking with symptoms" instead of just moving the instructions
| around setlocal etc. to the beginning of the script, so that
| everything else can remain unchanged?

Charles' program will give a user-defined error if processed with
COMMAND.COM or CMD.EXE. It doesn't use SETLOCAL until it is certain that the
command processor in use can handle all commands. This is a necessary
preface for a program disseminated via the internet to prevent damage on
systems it is not intended for. SETLOCAL is a time and resource consuming
command.

| What do you guys think about #3 from my initial post - is that
| something for a bug report, or a user error? ;)

If I understand you issue correctly, you had created one or more directories
externally to TCC, and now you want TCC to update its database for extended
directory search. Look at the /U option of the CDD command in HELP topic
"cdd.htm".
--
HTH, Steve

 

[samintz]

Re: TC-tree (and debugger)

1. Upon creating a new directory in a TCMD-tab, the tree did not display that directory and I did not find a way to update the tree (I used simple MD c:\foo, no switches)

There does appear to be some odd behavior. If I CDD to my desktop folder and then issue:

CDD /T .

The folder tree and list view are updated correctly. If I then do:

MD FOO
CDD /T FOO

The folder tree and list view do *not* get updated. The CDD command did change me to the Desktop/FOO directory, however. Even if I re-issue a CDD /T . command the tree and list are not updated. The list view does show the new FOO directory. However, I cannot go into it from the list view. Double-clicking just seems to get ignored. If I go the the File menu and hit Refresh, then things works correctly.

-Scott

 

[Charles Dye]

Re: TC-tree (and debugger)

Charles' program will give a user-defined error if processed with
COMMAND.COM or CMD.EXE. It doesn't use SETLOCAL until it is certain that the command processor in use can handle all commands. This is a necessary preface for a program disseminated via the internet to prevent damage on systems it is not intended for. SETLOCAL is a time and resource consuming command.

I think I was actually more concerned about that SETDOS, because it uses syntax which didn't exist in older versions of Take Command (4NT, 4DOS.) So the version check needs to come before the SETDOS....

 

[rconn]

Re: TC-tree (and debugger)

> There does appear to be some odd behavior. If I CDD to my desktop
> folder and then issue:
>
> CDD /T .
>
> The folder tree and list view are updated correctly. If I then do:
>
> MD FOO
> CDD /T FOO
>
> The folder tree and list view do *not* get updated.

WAD. The folder view is not automatically updated on a new directory
creation; you need to do a Refresh.

The autoupdate is on the suggestion list; however, monitoring the file
system to support this has thus far proved too much of a burden & slowed
things down considerably.

Rex Conn
JP Software

 

[MBaas]

Re: TC-tree (and debugger)

WAD. The folder view is not automatically updated on a new directory
creation; you need to do a Refresh.

Yeah, I imagine that could be a nightmare. But when using internal commands (like MD) while working in TCMD, I would imaging you could "easily" just call a RefreshTree-Subroutine? ;)

Part of the problem, I must admit, sat in front of the computer! I had not seen the refresh-option in the File-Menu. And even after Scott and you mentioning that, I had to look several times to notice it! (It's been a long day.) But ok, for the time being that is much better than having to restart TCMD, so I won't complain :)

Thanks very much for all the answers!

Michael

 

[samintz]

Re: TC-tree (and debugger)

I understand how or why it would slow things down. But since you already
have some kind of hook in place to handle the CDD /T, couldn't you perform
the refresh at that time?

-Scott

rconn <> wrote on 03/04/2010 01:57:05 PM:

> ---Quote---
> > There does appear to be some odd behavior. If I CDD to my desktop
> > folder and then issue:
> >
> > CDD /T .
> >
> > The folder tree and list view are updated correctly. If I then do:
> >
> > MD FOO
> > CDD /T FOO
> >
> > The folder tree and list view do *not* get updated.
> ---End Quote---
> WAD. The folder view is not automatically updated on a new directory
> creation; you need to do a Refresh.
>
> The autoupdate is on the suggestion list; however, monitoring the file
> system to support this has thus far proved too much of a burden & slowed
> things down considerably.
>
> Rex Conn
> JP Software
>
>
>
>

 

[rconn]

Re: TC-tree (and debugger)

> I understand how or why it would slow things down. But since you
> already have some kind of hook in place to handle the CDD /T, couldn't
> you perform the refresh at that time?

It's not CDD, it's MD, which doesn't have a hook.

And refreshing the folder tree takes a minimum of 1-2 seconds, and a max of
about 30 seconds (if there are a lot of non-responding remote drives).

Rex Conn
JP Software

 

[samintz]

Re: TC-tree (and debugger)

Well, I understand that MD doesn't automatically update the tree. However,
if I explicitly issue a CDD /T, I *expect* the tree to get updated, not
blatently ignore me. Is there a CDD or equivilent TCC command that forces
TCMD to do a File | Refresh?

-Scott

rconn <> wrote on 03/04/2010 07:55:47 PM:

> ---Quote---
> > I understand how or why it would slow things down. But since you
> > already have some kind of hook in place to handle the CDD /T, couldn't
> > you perform the refresh at that time?
> ---End Quote---
> It's not CDD, it's MD, which doesn't have a hook.
>
> And refreshing the folder tree takes a minimum of 1-2 seconds, and a max

of

> about 30 seconds (if there are a lot of non-responding remote drives).
>
> Rex Conn
> JP Software
>
>
>
>

 

[rconn]

Re: TC-tree (and debugger)

> Well, I understand that MD doesn't automatically update the tree.
> However,
> if I explicitly issue a CDD /T, I *expect* the tree to get updated, not
> blatently ignore me. Is there a CDD or equivilent TCC command that
> forces TCMD to do a File | Refresh?

The problem isn't that CDD /T ignores you, it's that you previously did a MD
and the CDD cannot change the folder view selection to a non-existent entry.

Rex Conn
JP Software

 

[rconn]

> 1. I often find myself wishing the current TC-Tab would CD into the
> directory that has been opened in the tree. Been thinking an internal
> variable ("treepath") or so might help in setting up an alias linked
> with a keystroke - but could not find anything in that direction.
> Surely others must have had similar requirements?
> 2. And syncing in the other direction is interesting as well (display
> current dir from tab in tree and file-pane).
> 3. Upon creating a new directory in a TCMD-tab, the tree did not
> display that directory and I did not find a way to update the tree (I
> used simple MD c:\foo, no switches)

The first three have all been covered in previous messages.

> 4. I have experimented a bit with the debugger (which I find *very
> *useful) and found a few issues:
> 1. single-stepping through code, I found that the statement to be
> executed next is highlighted in yellow. That is always true, except for
> a set-command that uses %@select, where the select comes up while the
> previous statement is still highlighted...(see screenie)

WAD -- the @SELECT (like all variable substitution) is being done *before*
the next statement is selected for execution.

> 2. I like watch and environment, but one thing would make it even
> more useful: a simple dropdown in the environment-tab which would give
> options to restrict the display to the "red variables" (changed since
> last command) or to those that were "accessed" (read or write) by the
> running batch. (Or otherwise add these to the 3d tab "batch variables")

It's on the suggestion list for the next version.

> 3. right-clicking a var in env-tab could also popup a menu-option
> "Add to watcher" (1st tab)

You can already right-click on the watch list to add environment variables.

Rex Conn
JP Software

 

[samintz]

Re: TC-tree (and debugger)

My "perception" is that CDD /T ignores me not that MD didn't update the
tree. I don't really care about the technical reasons. Well, that's not
entirely true. I do care. But the point is, I'm willing to wait while CDD
/T does a refresh.

It should be easy enough to tell if a refresh is needed. If the directory
you want to change to isn't in the tree, then refresh. Otherwise, just do
the change.

-Scott



rconn <> wrote on 03/04/2010 08:39:42 PM:

> ---Quote---
> > Well, I understand that MD doesn't automatically update the tree.
> > However,
> > if I explicitly issue a CDD /T, I *expect* the tree to get updated,

not

> > blatently ignore me. Is there a CDD or equivilent TCC command that
> > forces TCMD to do a File | Refresh?
> ---End Quote---
> The problem isn't that CDD /T ignores you, it's that you previously did

a MD

> and the CDD cannot change the folder view selection to a non-existent

entry.

>
> Rex Conn
> JP Software
>
>
>
>

 

[rconn]

Re: TC-tree (and debugger)

> It should be easy enough to tell if a refresh is needed. If the
> directory you want to change to isn't in the tree, then refresh.
> Otherwise, just do the change.

Not quite -- it's a Windows control black hole. The best I can do is ask it
to change, and then ask it again what the current directory is, and if it
doesn't match, refresh. But that's apt to generate a *lot* of unnecessary
refreshes when somebody enters an invalid directory or folder.

Rex Conn
JP Software

 

[samintz]

Re: TC-tree (and debugger)

How about a prompt akin to the overwrite prompt in the COPY command?

CDD /T foo
foo doesn't exist in Folder Tree. (Refresh) (Y/N)?

-Scott

rconn <> wrote on 03/05/2010 12:48:44 PM:

> ---Quote---
> > It should be easy enough to tell if a refresh is needed. If the
> > directory you want to change to isn't in the tree, then refresh.
> > Otherwise, just do the change.
> ---End Quote---
> Not quite -- it's a Windows control black hole. The best I can do is

ask it

> to change, and then ask it again what the current directory is, and if

it

> doesn't match, refresh. But that's apt to generate a *lot* of

unnecessary

> refreshes when somebody enters an invalid directory or folder.
>
> Rex Conn
> JP Software
>
>
>
>