According to the FTP logs, a couple of you are downloading QBAT. It's still undergoing much experimentation and changes. The filename has changed. I have put it in a zipfile, ftp://lucky.syr.edu/4plugins/qbat.zip, along with a brief txtfile.
QBAT notes
- Thread starter vefatica
- Start date
Vince,
I'm still getting an error with QBAT when I do not specify a
batch file name on the command line. See below. Something is
inserting "Files\JPSoft\TCMD9\" after the current directory
name. For the moment I have solved the problem by defining
an alias that ensures that a file name is specified.
-- Jay
C:\temp>*qbat
QBAT: Failed to open "C:\temp\Files\JPSoft\TCMD9\tcc.exe"
C:\temp>echo %comspec
C:\Program Files\JPSoft\TCMD9\tcc.exe
I'm still getting an error with QBAT when I do not specify a
batch file name on the command line. See below. Something is
inserting "Files\JPSoft\TCMD9\" after the current directory
name. For the moment I have solved the problem by defining
an alias that ensures that a file name is specified.
-- Jay
C:\temp>*qbat
QBAT: Failed to open "C:\temp\Files\JPSoft\TCMD9\tcc.exe"
C:\temp>echo %comspec
C:\Program Files\JPSoft\TCMD9\tcc.exe
On Sat, 02 Aug 2008 21:39:08 -0500, Jay Sage <> wrote:
Did you get my emails? When you first reported that, there was a bug. Plugin
initialization was corrupting my data because I was using an old PLUGININFO
structure which was missing two members that TCC writes to. I fixed that a few
days ago. Have you gotten new ones? Do you see all the new features
(PAUSE/RESUME for example)? Could you be getting a cached copy? It's now a
zipfile:
ftp://lucky.syr.edu/4plugins/qbat.zip
QBAT expands %@FULL[arg] where "arg" is either the default "qbat.bat" or the arg
you supplied. It never again touches that name. Rex, is there any way %@FULL[]
could possibly return that string by mistake?
Jay, I put a debug statement in it and uploaded a new one just now. As soon as
it gets %@FULL[arg] it will tell you the filename:
Printf(L"QBAT will use the file: %s\r\n", szFileName);
Thanks for the feedback.
Did you get my emails? When you first reported that, there was a bug. Plugin
initialization was corrupting my data because I was using an old PLUGININFO
structure which was missing two members that TCC writes to. I fixed that a few
days ago. Have you gotten new ones? Do you see all the new features
(PAUSE/RESUME for example)? Could you be getting a cached copy? It's now a
zipfile:
ftp://lucky.syr.edu/4plugins/qbat.zip
QBAT expands %@FULL[arg] where "arg" is either the default "qbat.bat" or the arg
you supplied. It never again touches that name. Rex, is there any way %@FULL[]
could possibly return that string by mistake?
Jay, I put a debug statement in it and uploaded a new one just now. As soon as
it gets %@FULL[arg] it will tell you the filename:
Printf(L"QBAT will use the file: %s\r\n", szFileName);
Thanks for the feedback.
> Did you get my emails?
Probably not. I sent my message from work, and I'm only there are rare
occasions now.
> Have you gotten new ones? Do you see all the new
> features (PAUSE/RESUME for example)? Could you be
> getting a cached copy? It's now a zipfile:
Yes, I had just downloaded the ZIP file, and I still have the problem.
It would be nice if you embedded a build number that was displayed with
the /? help. That way we could check our version number.
The version I have running now exits when I type Ctrl-E, so I think it
really is a new version.
-- Jay
Probably not. I sent my message from work, and I'm only there are rare
occasions now.
> Have you gotten new ones? Do you see all the new
> features (PAUSE/RESUME for example)? Could you be
> getting a cached copy? It's now a zipfile:
Yes, I had just downloaded the ZIP file, and I still have the problem.
It would be nice if you embedded a build number that was displayed with
the /? help. That way we could check our version number.
The version I have running now exits when I type Ctrl-E, so I think it
really is a new version.
-- Jay
Vince,
Before my last reply, I had not read the rest of your message. I just
downloaded and installed your version with the debug message. Here's
what I get.
C:\temp>*qbat
QBAT will use the file: C:\temp\Files\JPSoft\TCMD9\tcc.exe
QBAT: Bad file extension
C:\temp>*qbat test.btm
QBAT will use the file: C:\temp\test.btm
QBAT: idle
-- Jay
Before my last reply, I had not read the rest of your message. I just
downloaded and installed your version with the debug message. Here's
what I get.
C:\temp>*qbat
QBAT will use the file: C:\temp\Files\JPSoft\TCMD9\tcc.exe
QBAT: Bad file extension
C:\temp>*qbat test.btm
QBAT will use the file: C:\temp\test.btm
QBAT: idle
-- Jay
On Sun, 03 Aug 2008 12:33:55 -0500, Jay Sage <> wrote:
Well, I'm dumbfounded. I would expect that string in argv[0] when the string
passed to QBAT is empty. But I'm not looking at argv[0]. What version of
Windows do you use? Below is the code leading to that message. Maybe Rex or
someone else can spot something.
I've put more debugging stuff in it (ftp://lucky.syr.edu/4plugins/qbat.zip).
I see:
g:\projects\plugsample\release> *qbat
psz = ****
argc = 1
argv[0] = **D:\TCMD9\TCC.EXE**
QBAT will use the file: G:\Projects\plugsample\release\qbat.bat
g:\projects\plugsample\release> *qbat jp.bat
psz = ** jp.bat**
argc = 2
argv[0] = ****
argv[1] = **jp.bat**
QBAT will use the file: G:\Projects\plugsample\release\jp.bat
Here's the code.
INT WINAPI QBAT ( WCHAR * psz )
{
INT argc;
WCHAR *p, *q, *r, szExtensions[256], **argv;
for ( p=psz; *p; p++ )
if ( *p == L'/' && *(p+1) == L'?' )
return QBATHELP();
Sprintf(szFileName, L"qbat.bat");
bDeleteFile = FALSE;
argv = CommandLineToArgvW(psz, &argc);
for ( INT i=1; i<argc; i++ )
{
if ( !lstrcmpi(argv, L"/D") )
{
bDeleteFile = TRUE;
}
else if ( argv[0] )
{
lstrcpy(szFileName, argv);
break;
}
}
LocalFree(argv);
MakeFullName(szFileName, 1);
Printf(L"QBAT will use the file: %s\r\n", szFileName);
Well, I'm dumbfounded. I would expect that string in argv[0] when the string
passed to QBAT is empty. But I'm not looking at argv[0]. What version of
Windows do you use? Below is the code leading to that message. Maybe Rex or
someone else can spot something.
I've put more debugging stuff in it (ftp://lucky.syr.edu/4plugins/qbat.zip).
I see:
g:\projects\plugsample\release> *qbat
psz = ****
argc = 1
argv[0] = **D:\TCMD9\TCC.EXE**
QBAT will use the file: G:\Projects\plugsample\release\qbat.bat
g:\projects\plugsample\release> *qbat jp.bat
psz = ** jp.bat**
argc = 2
argv[0] = ****
argv[1] = **jp.bat**
QBAT will use the file: G:\Projects\plugsample\release\jp.bat
Here's the code.
INT WINAPI QBAT ( WCHAR * psz )
{
INT argc;
WCHAR *p, *q, *r, szExtensions[256], **argv;
for ( p=psz; *p; p++ )
if ( *p == L'/' && *(p+1) == L'?' )
return QBATHELP();
Sprintf(szFileName, L"qbat.bat");
bDeleteFile = FALSE;
argv = CommandLineToArgvW(psz, &argc);
for ( INT i=1; i<argc; i++ )
{
if ( !lstrcmpi(argv, L"/D") )
{
bDeleteFile = TRUE;
}
else if ( argv[0] )
{
lstrcpy(szFileName, argv);
break;
}
}
LocalFree(argv);
MakeFullName(szFileName, 1);
Printf(L"QBAT will use the file: %s\r\n", szFileName);
Jay Sage wrote:
| Boy is this strange! Here's the output from the latest debugging
| version.
|
| -- Jay
|
| C:\temp>*qbat
| psz = ****
| argc = 2
| argv[0] = **C:\Program**
| argv[1] = **Files\JPSoft\TCMD9\tcc.exe**
| QBAT will use the file: C:\temp\Files\JPSoft\TCMD9\tcc.exe
| QBAT: Bad file extension
The problem seems to be that there is a SPACE character in TCC's path, which
is parsed into argv[0] and argv[1]. Microsoft strikes again!
Jay, try to create a simple directory junction to the directory where
TCC.EXE is located which has no embedded special characters:
mklnk "C:\Program Files\JPSoft\TCMD9\tcc.exe" c:\tccdir
and run C:\TCCDIR\TCC.EXE.
I bet the QBAT problems will go away!
--
HTH, Steve
| Boy is this strange! Here's the output from the latest debugging
| version.
|
| -- Jay
|
| C:\temp>*qbat
| psz = ****
| argc = 2
| argv[0] = **C:\Program**
| argv[1] = **Files\JPSoft\TCMD9\tcc.exe**
| QBAT will use the file: C:\temp\Files\JPSoft\TCMD9\tcc.exe
| QBAT: Bad file extension
The problem seems to be that there is a SPACE character in TCC's path, which
is parsed into argv[0] and argv[1]. Microsoft strikes again!
Jay, try to create a simple directory junction to the directory where
TCC.EXE is located which has no embedded special characters:
mklnk "C:\Program Files\JPSoft\TCMD9\tcc.exe" c:\tccdir
and run C:\TCCDIR\TCC.EXE.
I bet the QBAT problems will go away!
--
HTH, Steve
On Sun, 03 Aug 2008 15:51:01 -0500, Jay Sage <> wrote:
Strange! I'd say so. When I tested here, I saw the whole name of the exe in
argv[0].
Well, you saw the code, and even if you don't speak "C", you could see it starts
looking at args at argv[1], and puts only one of them into szFileName. What
version of Windows are you using? Are you starting that TCC session in a
peculiar way? Rex, have you ever seem anything like that? It's the result of
CommandLineToArgvW() used on an empty string passed to a plugin function.
Anyway, I got rid of CommandLineToArgvW() and re-wrote the routine using Rex's
NthArgument() function. There's a new one at
ftp://lucky.syr.edu/4plugins/qbat.zip
Strange! I'd say so. When I tested here, I saw the whole name of the exe in
argv[0].
Well, you saw the code, and even if you don't speak "C", you could see it starts
looking at args at argv[1], and puts only one of them into szFileName. What
version of Windows are you using? Are you starting that TCC session in a
peculiar way? Rex, have you ever seem anything like that? It's the result of
CommandLineToArgvW() used on an empty string passed to a plugin function.
Anyway, I got rid of CommandLineToArgvW() and re-wrote the routine using Rex's
NthArgument() function. There's a new one at
ftp://lucky.syr.edu/4plugins/qbat.zip
> Jay, try to create a simple directory junction to the
> directory where TCC.EXE is located which has no
> embedded special characters:
>
> mklnk "C:\Program Files\JPSoft\TCMD9\tcc.exe"
> c:\tccdir
>
> and run C:\TCCDIR\TCC.EXE
Steve,
You have a typo in there that caused me a bit of grief. I copy/pasted
your commands and ended up with a file c:\tccdir that I could not get
rid of (finally succeeded outside of TCMD).
When I entered instead
mklnk "C:\Program Files\JPSoft\TCMD9"
and then ran "C:\TCCDIR\TCC.EXE", I ended up with a session in which
QBAT works, as you predicted.
prompt>*qbat
psz = ****
argc = 1
argv[0] = **C:\tccdir\tcc.exe**
QBAT will use the file: C:\Program Files\JPSoft\TCMD9\qbat.bat
QBAT: idle
Clearly some quotes are missing somewhere in the code, either Vince's
code or Microsoft's code (or, I suppose, Rex's code). The directory
"Program Files" is the normal directory for programs in Windows XP.
(Vince, to answer your question, I'm running XP SP2.)
-- Jay
> directory where TCC.EXE is located which has no
> embedded special characters:
>
> mklnk "C:\Program Files\JPSoft\TCMD9\tcc.exe"
> c:\tccdir
>
> and run C:\TCCDIR\TCC.EXE
Steve,
You have a typo in there that caused me a bit of grief. I copy/pasted
your commands and ended up with a file c:\tccdir that I could not get
rid of (finally succeeded outside of TCMD).
When I entered instead
mklnk "C:\Program Files\JPSoft\TCMD9"
and then ran "C:\TCCDIR\TCC.EXE", I ended up with a session in which
QBAT works, as you predicted.
prompt>*qbat
psz = ****
argc = 1
argv[0] = **C:\tccdir\tcc.exe**
QBAT will use the file: C:\Program Files\JPSoft\TCMD9\qbat.bat
QBAT: idle
Clearly some quotes are missing somewhere in the code, either Vince's
code or Microsoft's code (or, I suppose, Rex's code). The directory
"Program Files" is the normal directory for programs in Windows XP.
(Vince, to answer your question, I'm running XP SP2.)
-- Jay
Jay Sage wrote:
| Steve,
|
| You have a typo in there that caused me a bit of grief. I copy/pasted
| your commands and ended up with a file c:\tccdir that I could not get
| rid of (finally succeeded outside of TCMD).
Sorry. I type fast, furious, and erroneous. Glad you figured out the mistake
and solved the immediate issue.
--
Steve
| Steve,
|
| You have a typo in there that caused me a bit of grief. I copy/pasted
| your commands and ended up with a file c:\tccdir that I could not get
| rid of (finally succeeded outside of TCMD).
Sorry. I type fast, furious, and erroneous. Glad you figured out the mistake
and solved the immediate issue.
--
Steve
> I abandoned the use of CommandLineToArgvW() which,
> according to your example, was behaving oddly (or I
> don't fully appreciate how it works).
Hooray! The new one works! I think you can drop the debugging code.
-- Jay
prompt>*qbat
QBAT will use the file: C:\Program Files\JPSoft\TCMD9\qbat.bat
QBAT: idle
> according to your example, was behaving oddly (or I
> don't fully appreciate how it works).
Hooray! The new one works! I think you can drop the debugging code.
-- Jay
prompt>*qbat
QBAT will use the file: C:\Program Files\JPSoft\TCMD9\qbat.bat
QBAT: idle
Jay, I'm glad to hear it's working better. I added a handy feature ... a single-line edit control for parameters to the batch file. There's a new file in place.
I haven't, but could easily, have those parameters remembered between QBAT invocations (not between TCC sessions). Do you think that's a good idea?
Thanks.
I haven't, but could easily, have those parameters remembered between QBAT invocations (not between TCC sessions). Do you think that's a good idea?
Thanks.
Vince,
The new version works very nicely. Thank you very much for creating this.
> I haven't, but could easily, have those parameters
> remembered between QBAT invocations (not between TCC
> sessions). Do you think that's a good idea?
So far I don't see any reason to remember them. I imagine using QBAT
primarily for short, one-time-use batch files. Perhaps if (when) I use
it for developing more complex scripts over a period of time, I would
find it useful if the parameters were remembered, but I don't foresee
such a use.
Here's another idea for accomplishing a similar end. How about allowing
additional parameter on the QBAT command line that would become the
initial parameter string for the QBAT editing session. Then command-line
recall or an alias could be used to remember parameters that one wants
each time.
-- Jay
The new version works very nicely. Thank you very much for creating this.
> I haven't, but could easily, have those parameters
> remembered between QBAT invocations (not between TCC
> sessions). Do you think that's a good idea?
So far I don't see any reason to remember them. I imagine using QBAT
primarily for short, one-time-use batch files. Perhaps if (when) I use
it for developing more complex scripts over a period of time, I would
find it useful if the parameters were remembered, but I don't foresee
such a use.
Here's another idea for accomplishing a similar end. How about allowing
additional parameter on the QBAT command line that would become the
initial parameter string for the QBAT editing session. Then command-line
recall or an alias could be used to remember parameters that one wants
each time.
-- Jay
On Tue, 05 Aug 2008 08:54:26 -0500, Jay Sage <> wrote:
A good idea. I'll work on it when I get home from work. I might have to signal
the start of the parameters with a switch, maybe /P, (so you could give params
and no file name).
I also added a feature (not ready for prime time) wherein, if you put something
in the params box and press [Enter], it's executed in the current console and
deleted (say, just in case you forgot to do something before QBAT).
A good idea. I'll work on it when I get home from work. I might have to signal
the start of the parameters with a switch, maybe /P, (so you could give params
and no file name).
I also added a feature (not ready for prime time) wherein, if you put something
in the params box and press [Enter], it's executed in the current console and
deleted (say, just in case you forgot to do something before QBAT).
2008/8/5 vefatica <>:
How about just a line of 10 dashes or so in place of the QBAT: idle
line, and remove the "Running" line altogether? That way each run is
separated by a single line.
Also, can you add an "@" at the start of the ON BREAK QUIT? I don't
have "Default batch echo" switched off, so the ON BREAK line gets
displayed, which is mildly irritating.
Paul.
How about just a line of 10 dashes or so in place of the QBAT: idle
line, and remove the "Running" line altogether? That way each run is
separated by a single line.
Also, can you add an "@" at the start of the ON BREAK QUIT? I don't
have "Default batch echo" switched off, so the ON BREAK line gets
displayed, which is mildly irritating.
Paul.
The 10 dashes works for me. And I added the @ as requested (good idea). I also allowed for QBAT command line parameters to the batfile (see /?). Those parameters are remembered across QBAT sessions (within the same TCC session) and are auto-restored if you use the parameters edit box to execute a command (still a preliminary feature with no safe-guards).
There was a bug in the one posted last night (Thursday); [Up], [Down], and friends, didn't work in the edit box. That's fixed. New features: you can scroll the console with [Alt-Up] (and friends, same keys as in the console) while in either edit box. You can resize the dialog relative to the default size (the units are pixels) with ini options vDelta and Hdelta or with the command line options [/V M] and [/H N]. Vdelta (and M) have a lower limit of -100, giving an editor about two lines high. Hdelta (and N) have a lower limit of -150. There are no upper limits (yet?). A typo gave me a dialog 6000 pixels high! Be careful.
I made some big changes; read the txtfile.
Most notably, the FontSize spec has changed to point size (was height). The default is 9.
<Ctrl-ParametersButton> will invoke the ChooseFont dialog. If you use it to change the font, the new font is remembered in "HKCU\Software\QBAT" (if allowed) and, if found there, is subsequently used automatically.
I may get rid of the INIfile's "FontName" and "FontSize".
The dialog is resizable; drag its frame.
Most notably, the FontSize spec has changed to point size (was height). The default is 9.
<Ctrl-ParametersButton> will invoke the ChooseFont dialog. If you use it to change the font, the new font is remembered in "HKCU\Software\QBAT" (if allowed) and, if found there, is subsequently used automatically.
I may get rid of the INIfile's "FontName" and "FontSize".
The dialog is resizable; drag its frame.