Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

Done Suggestions for v10

Charles Dye

Super Moderator
May
5,134
137
Staff member
Rex Conn wrote:

> I'm starting the design for Take Command v10. If you have any suggestions for TCMD or TCC, please submit them to the "Take Command and TCC / Suggestions" forum.

Y'know, I was just wishing there was an option to make all the popup windows save their screen positions at close, and reopen in the same place the next time they were invoked.

It would be interesting to see your current list.
 
Charles Dye wrote:


> It would be interesting to see your current list.

There is no current list -- I'm starting with a fresh slate on v10. The
old list was getting too clogged with detritus dropped from earlier
versions (and in many cases not relevant to the new architecture and/or
potentially not desired any longer by the users).

The only thing that is certain at this time is a complete revamping of
the debugger IDE.

Rex Conn
JP Software
 
.) Well, I'll ask for Ctrl-Break in TCI again. You've established
precedent of fixing plenty of MS's impossibilities already, so I don't
expect you to be completely stuck here again, either. I hope you're
flattered instead of frustrated that my opinion is that you'll be able
to get past any thing that MS stuffs in front of you.

.) DIR /S sorting as a whole list instead of dir-by-dir. I would use
this feature a LOT. The custom program I wrote takes as many file
patterns as you give, and then sorts the entire output. Like piping to
sort, but retaining all colors and header/trailer.

.) setlocal/endlocal from the command line. I'll admit that now with
TCI I often just bring up a new TCC window tab and then destroy it,
but would surely switch to using set/end if they worked from the
command line.

.) An easy, supported way to make a .btm run on a client machine
without having to install any files -- I have some VARs who have
clients who strictly prohibit actually installing anything, but will
let us run my utilities. Something I could package and send would be
necessary. The famous "batch file compiler." Perhaps like perl2exe
from www.indigostar.com where the script just gets stuck on the
executable / DLL package. That's what I've been using for utilities on
one client recently.

.) This is way outside the realm of TCC, but since CascadePoint is
also, ... an installable file system so I can use FTP: from any app. I
have a couple places where that would be exceptionally useful. Perhaps
in your copious free time ....



On Thu, Jun 12, 2008 at 8:09 AM, rconn <> wrote:

> Charles Dye wrote:
>
>
> Quote:
>> It would be interesting to see your current list.
> There is no current list -- I'm starting with a fresh slate on v10. The
> old list was getting too clogged with detritus dropped from earlier
> versions (and in many cases not relevant to the new architecture and/or
> potentially not desired any longer by the users).
>
> The only thing that is certain at this time is a complete revamping of
> the debugger IDE.
>
> Rex Conn
> JP Software
>
>



--
2008 Fridays: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
Next year they're Saturday.
Measure wealth by the things you have for which you would not take money.
 
Rex,

I'd like to see commands in TCC that allow to control the Folder- and
Listview of TCMD: mark dirs or drives, open and close branches, mark
files and dirs. You probably need to lock/unlock TCMD from TCC to avoid
2 consoles sending conflicting commands.

Allow TCC to set filters in the filter bar and use the Find field in
TCMD.

Reversely, it should be possible to mousemark in Folder- and Listview
and send the marked items to a TCC command (right mouse menu?).

I'd like to map the full XP color palette to the 16 DOS colors, changing
each DOS color to my preference, for background and fonts in TCC. I'd
like to use the full XP palette for backgrounds and colors in TCMD.

Mit freundlichem Gruß,

Klaus Meinhard
 
There is already support for reading xml files. Please add support for creating/updating nodes/attributes and writing the new/updated file.
 
For the delay command, add:

/F(lush): Clear keystrokes buffer when delay ends

as in the RB_Utils plugin. (Unfortunately, that plugin has a problem in v9.)

-- T
 
rconn wrote:


> > There is no current list -- I'm starting with a fresh slate on v10.

So I'll renew the request for a "text" variable, that will ignore
critical characters inside. At least it could automate the

setdos /x-135678
set varsetdos/x0

approach.

Mit freundlichem Gruß,

Klaus Meinhard
 
K_Meinhard wrote:
| rconn wrote:
|
|
|
| ---Quote---
||| There is no current list -- I'm starting with a fresh slate on v10.
| ---End Quote---
| So I'll renew the request for a "text" variable, that will ignore
| critical characters inside. At least it could automate the
|
| setdos /x-135678
| set varsetdos/x0
|
| approach.

I support this. I would not object, nay, I would support modified syntax for
defining such variables. Simple candidates that come to mind:

1/ A new command:

LET xyz="ab'c""<xy>|` "

2/ A new assignment operator in SET command:

SET xyz=="ab'c""<xy>|` "

3/ A new option for the SET command:

SET/T xyz=="ab'c""<xy>|` "

Regardless of the method used, the VALUE of the text variable xyz defined
above would be (shown below with a leading and trailing colon : added to
display blank spaces correctly:

:ab'c"<xy>|` :

In other words, the special rules for definition are:
a/ string is delimited by leading and trailing quotation mark
b/ two consecutive quotation marks represent included quotation mark

Note: In at least one HLL this rule is enhanced to using either apostrophe
or quotation mark as the leading and trailing delimiter, and the doubling
rule b/ applied only to the delimiter used in the current statement. This
enhancement allows text containing only one of them to be delimited by the
other, without requiring doubling.

Additionally, new options would be required for the DO and FOR commands when
the value set they process is from a file (including a pipe) to indicate
that the literal text is to be used. New functions @LINET[], @FILEREADT[]
are also required for direct file access.

Lastly, but most importantly, the text variables need special usage rules:

1/ Like the variables received by a GOSUB via the command line, or the loop
control variables of FOR (esp. single letter FOR variable names), the "text
variable" attribute must be stored so the parser would be aware of the need
for special treatment on value retrieval

2/ When retrieving the value of a text variable, the parser should deliver
it to the command or function using it without regard to content.

If this were implemented, one could write batch programs that process other
batch programs one line at a time as data. Currently this is almost
impossible to do.
--
Steve
 
The /affinity=n option of start is currently incompatible with (and less useful) than the same in CMD.EXE. In TCC n is the number of the processor, in CMD it is a processor mask. So for example one can specify '3' to request that the process run on CPU-s (or cores) 0 and 1. I never cared before, but, hey, I now have a quad-core, so who knows...
 
It's a revolutionary, new idea, but I'd like to get away from having to use a console window for my command processor.

Since most of the code is in takecmd.dll, you could write a GUI front end and make the shell more of a Windows program.

- It could use Crtl-C/X/V for copy/cut/paste like pretty much every other Windows program.

- It could have a larger scrollback buffer than TCC.

- It could handle Ctrl-Break and not vanish the way TCC does.

- The LIST command could use the window scroll bar

Perhaps you could start a special new development project and codename it "Osprey".

-- Timothy
 
It's a revolutionary, new idea, but I'd like to get away from having to use a console window for my command processor.

If you care to, you can read my take on this revolutionary new idea on the old forum. It was on August 25, 2004....

.... but it wasn't a likely direction for development back then, and it seems about twenty times less likely now.
 
Péter Köves wrote:

> The /affinity=n option of start is currently incompatible with (and less
> useful) than the same in CMD.EXE. In TCC n is the number of the
> processor, in CMD it is a processor mask. So for example one can specify
> '3' to request that the process run on CPU-s (or cores) 0 and 1. I never
> cared before, but, hey, I now have a quad-core, so who knows...

The /affinity option in TCC was created before MS added the option to
CMD (which is only supported in XP64 & Vista).

I can change it in TCC to match the new CMD behavior, though it'll
potentially break existing code. Does anybody out there care if it's
changed?

Rex Conn
JP Software
 
Changing the affinity to match cmd is fine, and even desireable, with
me.

Sent from Cookie's iPhone

On Jun 15, 2008, at 16:26, rconn <> wrote:
 
From: rconn
Sent: Sunday, June 15, 2008 6:27 PM
Subject: RE: [Suggestions-t-185] Re: Suggestions for v10

>
> I can change it in TCC to match the new CMD behavior, though it'll
> potentially break existing code. Does anybody out there care if it's
> changed?

Instead of changing something that's been in place for a while, perhaps it
makes more sense to add alternate syntax for the new behaviour, e.g.:

/affinity=0x3

or

/affinitymask=3

Jonathan Gilbert_
\\\ / / / \ |_) |_/
\\\/ \/ \__/ | \ | \
Software Systems
 
Jim Cook wrote:
| Changing the affinity to match cmd is fine, and even desireable, with
| me.

I don't use it at all, so I have no objection to anything you may decide to
do.
--
Steve
 
logic wrote:


> Quote:
> >
> > I can change it in TCC to match the new CMD behavior, though it'll
> > potentially break existing code. Does anybody out there care if it's
> > changed?
>
> Instead of changing something that's been in place for a while, perhaps it
> makes more sense to add alternate syntax for the new behaviour, e.g.:
>
> /affinity=0x3
>
> or
>
> /affinitymask=3

The original issue was CMD compatibility; this doesn't address that.
New syntax still wouldn't work with CMD and probably wouldn't be used
for TCC files, so I doubt there's much to be gained.

Rex Conn
JP Software
 
Being able to use the toolbarbuttons as defined in the tcmd.ini as the default.

Like: tctoolbar /D (d for default) would reread the inifile and set the buttons like the where with startup.

If I create a toolbar file and edit those buttons the changes are written to the tcmd.ini. That's not a problem, however if I wan't use those buttons again after reading a different toolbar file I have to restart TCMD to get the original buttons back
 
K_Meinhard wrote:


> Quote:
> > > There is no current list -- I'm starting with a fresh slate on v10.
>
> So I'll renew the request for a "text" variable, that will ignore
> critical characters inside. At least it could automate the
>
> setdos /x-135678
> set varsetdos/x0
>
> approach.

The problem is not in having a variable like that, it's that there
wouldn't be any way to get data into it or out of it without the parser
potentially choking on the special characters.

Rex Conn
JP Software
 
Rex,:


> > The problem is not in having a variable like that, it's that there
> > wouldn't be any way to get data into it or out of it without the
> > parser potentially choking on the special characters.

I don't quite understand. To automate the process

setdos /x-135678
set myvar=foobar with some "forbidden" chars
setdos /x0

to a new command (tset ?) or switch to set (set /T ?) shouldn't throw
the parser:

Another way using existing mechanisms might be to escape each character
individually. Of course, the resulting variable must be marked somehow
as "text"var (to tell the parser "forbidden chars"). It doesn't have to
be in the normal environment (so no "extra" char would be needed to mark
it as a text var). The handling of such vars would simply follow what
you do now with escapes chars.

This is probably the longest standing request, voiced many times since
early 4DOS. Just imagine the simplification for support: instead of
"don't do that" you can say "put in in a text var" :-)

Mit freundlichem Gruß,

Klaus Meinhard
 
Back
Top
[FOX] Ultimate Translator
Translate