Welcome!

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

SignUp Now!

bdebugger issues

samintz

Scott Mintz
May
1,582
27
On my Win7 machine, when I launch bdebugger the lower window with the "Watch, Environment, Batch Parameters, etc." tabs comes up with no labels in any of the tabs. It displays correctly on my WinXP machine.

There was an issue with it crashing when I quit on my WinXP machine with version 25, but that appears to be fixed in v26.

I attached a screen capture of the missing labels.
-Scott
 

Attachments

  • Capture.JPG
    Capture.JPG
    18.8 KB · Views: 225
> On my Win7 machine, when I launch bdebugger the lower window with the
> "Watch, Environment, Batch Parameters, etc." tabs comes up with no
> labels in any of the tabs. It displays correctly on my WinXP machine.

You probably forgot to clear your IDE registry entry when I changed the
number and format of the labels during the private beta. Go to
HKCU\Software\JP Software and delete the "IDE 12.0" key; TCMD will recreate
it the next time you run the debugger.

Rex Conn
JP Software
 
If I debug this BTM file:

Code:
DO FOREVER
    SET K=0
    INKEY /P /X /W0 %%K
    IF %K NE 0 ECHOS %K
    ECHOS .
    DELAY 1
ENDDO

... run to end (no breakpoints) every time through the loop, focus returns to the debugger. That makes it quite difficult to enter keystrokes in the console.

And, even though "Insert tabs as spaces" is unchecked, it is inserting tabs as spaces. In fact, if I check that option, then real tabs are inserted (i.e., they can be undone with a single backspace). It seems to be backwards.
 
And "Tab reformats indentation" (if that means subsequent lines have matching indentations) does not work on the fly and is not remembered.
 
And X-ing the console while IDE is running can have quite a range of effects. If no debugging had been done it just closes both TCC and IDE. If some debugging had been done, and stopped, several of my aliases are executed (HexWorkshop and Notepad start (via aliases), the console is made nearly full-screen (an "mcon" alias), and a couple of other aliases to time multiple executions of a command are run) ... and the message "TCC is not responding". If debugging and running, then I just get "Windows cannot end ...".

And putting "EXIT" is a BTM and running/debugging in IDE causes IDE to exit (and not TCC).
 
If you place the caret at the beginning of a line and double-left-click, the first word of the line PLUS the newline after the previous line become selected. For example, if I double-left-click at the beginning of the second line below ...

abc def
ghi jkl

... the selection includes the newline (now visible) after "abc def" and also "ghi". Pressing [Delete] results in

abd jkl

I suspect that double-left-clicking at the beginning of a line should select the entire line and **its** newline.

Can you put a little room between the expand/collapse column and the first character of a line? It's quite difficult to get the caret there for selecting.
 
> If you place the caret at the beginning of a line and double-left-
> click, the first word of the line PLUS the newline after the previous
> line become selected.

Not my code.


> Can you put a little room between the expand/collapse column and the
> first character of a line? It's quite difficult to get the caret there
> for selecting.

No - not my code.

Rex Conn
JP Software
 
If, in the debugger while simply editing, I use the mouse to place the caret on the name of a plugin variable or variable function (e.g., on "%@SET" or "%_INKEY" below)

Code:
ECHO %@SET[foo=bar]
SET A=%@IF[%_INKEY EQ 0,0,1]

a message appears in the console:

Code:
TCC: Syntax error "@SET[foo"
TCC: Syntax error "@IF[%_INKEY"

It also happens while running without debugging and while debugging and paused.

I hope we will be able to turn off this pop-up help thingy.
 
Not my code.
No - not my code.

Is the third-party software in v12's IDE different from that used in v11?

V11 had a nice click-margin before the text and didn't exhibit the strange selection problem I mentioned. And it had much nicer toolbar icons.
 
Yes. There is 0% code in common between the v11 and v12 editors.

Any chance you could/would go back to the start/stop/pause toolbar icons that were in v11's IDE? They're much nicer looking.
 
Tonight I noticed that if, while editing in IDE, I place the caret anywhere in the expression "%@PING[ilucky]" the function is evaluated (i.e., there is an actual ping) and the result shows in a bubble. I don't think mere editing should cause variable functions to be evaluated.
 
That worked. Thanks.
-Scott

rconn <> wrote on 09/05/2010 11:03:35 AM:


> ---Quote---
> > On my Win7 machine, when I launch bdebugger the lower window with the
> > "Watch, Environment, Batch Parameters, etc." tabs comes up with no
> > labels in any of the tabs. It displays correctly on my WinXP machine.
> ---End Quote---
> You probably forgot to clear your IDE registry entry when I changed the
> number and format of the labels during the private beta. Go to
> HKCU\Software\JP Software and delete the "IDE 12.0" key; TCMD will
recreate

> it the next time you run the debugger.
>
> Rex Conn
> JP Software
>
>
>
>
 
> Tonight I noticed that if, while editing in IDE, I place the caret
> anywhere in the expression "%@PING[ilucky]" the function is evaluated
> (i.e., there is an actual ping) and the result shows in a bubble. I
> don't think mere editing should cause variable functions to be
> evaluated.

WAD. If you hover the mouse cursor (not the caret) over a variable, the
debugger will expand the variable and display it in a tooltip.

Rex Conn
JP Software
 
| WAD. If you hover the mouse cursor (not the caret) over a variable,
| the debugger will expand the variable and display it in a tooltip.

Some of my variable functions execute a batch file to obtain their
result, a few execute external programs. When I debug a batch program, the
graphics pointer is usually hovering at some uncontrolled, random location
on the screen, thus possibly causing serious side effects if a function with
side effects happens to be scrolled there. Could this artifact be enabled or
disabled by the user?
--
Steve
 
On Tue, 07 Sep 2010 17:31:00 -0400, Steve Fábián <> wrote:

|| WAD. If you hover the mouse cursor (not the caret) over a variable,
|| the debugger will expand the variable and display it in a tooltip.
|
| Some of my variable functions execute a batch file to obtain their
|result, a few execute external programs. When I debug a batch program, the
|graphics pointer is usually hovering at some uncontrolled, random location
|on the screen, thus possibly causing serious side effects if a function with
|side effects happens to be scrolled there. Could this artifact be enabled or
|disabled by the user?

It's totally inappropriate to have batch code executed while editing. @PING is
a good example, but there are other more outrageous ones. What about @FILEOPEN,
@FILEWRITE, @BALLOC, @CONSOLEB, a lot of numeric/string functions that depend on
variables which might not even be defined (the list goes on). Evaluating many,
many variable functions is akin to executing commands (and I hope you don't
intend that hovering execute commands). I don't even think it would useful as
an option!
 
On Tue, 07 Sep 2010 16:24:38 -0400, rconn <> wrote:

|---Quote---
|> Any chance you could/would go back to the start/stop/pause toolbar
|> icons that were in v11's IDE? They're much nicer looking.
|---End Quote---
|I could, though IMO the ones in v12 are both more easily understood and
|better looking.

They're equally easy to understand, an arrow (start), a box (stop) and the
nearly universal pause bitmap. I just don't like their embedding into little TV
screens which are fuzzy looking and downright ugly when grayed. I'd like to
know what others think.
 
| On Tue, 07 Sep 2010 17:31:00 -0400, Steve Fbin <> wrote:
|
||| WAD. If you hover the mouse cursor (not the caret) over a
||| variable, the debugger will expand the variable and display it in
||| a tooltip.
||
|| Some of my variable functions execute a batch file to obtain
|| their result, a few execute external programs. When I debug a batch
|| program, the graphics pointer is usually hovering at some
|| uncontrolled, random location on the screen, thus possibly causing
|| serious side effects if a function with side effects happens to be
|| scrolled there. Could this artifact be enabled or disabled by the
|| user?
|
| It's totally inappropriate to have batch code executed while
| editing. @PING is a good example, but there are other more
| outrageous ones. What about @FILEOPEN, @FILEWRITE, @BALLOC,
| @CONSOLEB, a lot of numeric/string functions that depend on
| variables which might not even be defined (the list goes on).
| Evaluating many, many variable functions is akin to executing
| commands (and I hope you don't intend that hovering execute
| commands). I don't even think it would useful as an option!

On second thought I agree with Vince. In fact one of my problems with
debugging in the past was that files opened with @FILEOPEN were not closed
when quitting out put of the debugger in the middle of the batch program.
With the IDE running in a different environment this is no longer a problem,
though it has other issues. Since it became a separate process, I need to
manually switch to the directory where my .INI files are when I start IDE,
and specify the full path of the batch file to be debugged (usually by using
@SEARCH[]). I do wish if it cannot run in the instance of TCC whence invoked
it would at least run in one that is its child, and would thus automatically
inherit the parent's whole environment, since some batch programs may depend
on variables set by previously executed programs, possibly even history or
directory stack entries.
--
Steve
 
On Tue, 07 Sep 2010 21:47:33 -0400, rconn <> wrote:

|---Quote (Originally by vefatica)---
|And "Tab reformats indentation" (if that means subsequent lines have matching indentations) does not work on the fly and is not remembered.
|---End Quote---
|
|It does not mean that. It means that the tab key indents rather than inserting a tab character. (It is not my dialog.)

OK.

Anyway, the automatic "indent matches last line" which used to be there, is
gone.
 
And X-ing the console while IDE is running can have quite a range of effects. If no debugging had been done it just closes both TCC and IDE. If some debugging had been done, and stopped, several of my aliases are executed (HexWorkshop and Notepad start (via aliases), the console is made nearly full-screen (an "mcon" alias), and a couple of other aliases to time multiple executions of a command are run) ... and the message "TCC is not responding". If debugging and running, then I just get "Windows cannot end ...".

And putting "EXIT" is a BTM and running/debugging in IDE causes IDE to exit (and not TCC).

Besides my being completely baffled as to *why* you would be doing that, you seem to assuming that the debugger is somehow involved with TCC.EXE. There is *no* connection; the debugger/ide does not call TCC.EXE or interact with an existing TCC.EXE in any way. The batch debugger is calling takecmd.dll, and basically acting as a batch-only version of TCC.
 
If I debug this BTM file:

Code:
DO FOREVER
    SET K=0
    INKEY /P /X /W0 %%K
    IF %K NE 0 ECHOS %K
    ECHOS .
    DELAY 1
ENDDO

... run to end (no breakpoints) every time through the loop, focus returns to the debugger. That makes it quite difficult to enter keystrokes in the console.

Yes -- as it does in all previous versions of the debugger as well!

It has nothing to do with the loop; the batch debugger always returns focus to itself after executing each line, when it highlights the next line.

If you *don't* want to debug the file, why run it in the debugger?
 
And putting "EXIT" is a BTM and running/debugging in IDE causes IDE to exit (and not TCC).

Right -- so?

You're presumably invoking the IDE from a stand-alone TCC session. The EXIT will terminate the IDE session running the batch file; it doesn't have any effect on the parent TCC.EXE that launched IDE. (Did you *want* it to kill the parent session?)
 
On Tue, 07 Sep 2010 22:24:24 -0400, rconn <> wrote:

|---Quote (Originally by vefatica)---
|And X-ing the console while IDE is running can have quite a range of effects. If no debugging had been done it just closes both TCC and IDE. If some debugging had been done, and stopped, several of my aliases are executed (HexWorkshop and Notepad start (via aliases), the console is made nearly full-screen (an "mcon" alias), and a couple of other aliases to time multiple executions of a command are run) ... and the message "TCC is not responding". If debugging and running, then I just get "Windows cannot end ...".
|
|And putting "EXIT" is a BTM and running/debugging in IDE causes IDE to exit (and not TCC).
|---End Quote---
|
|Besides my being completely baffled as to *why* you would be doing that, you seem to assuming that the debugger is somehow involved with TCC.EXE. There is *no* connection; the debugger/ide does not call TCC.EXE or interact with an existing TCC.EXE in any way. The batch debugger is calling takecmd.dll, and basically acting as a batch-only version of TCC.

X-ing the console has always been a very convenient way to stop everything,
including IDE.

As for those messages from Windows, they're unsightly. I don't want to see them
and I have always figured you didn't want them, even when users do dumb things.

So IDE is attaching to its parent's console, running the batch file and
processing console I/O ... right?
 
On Tue, 07 Sep 2010 22:37:03 -0400, rconn <> wrote:

|---Quote (Originally by vefatica)---
|... run to end (no breakpoints) every time through the loop, focus returns to the debugger. That makes it quite difficult to enter keystrokes in the console.
|---End Quote---
|
|Yes -- as it does in all previous versions of the debugger as well!
|
|It has nothing to do with the loop; the batch debugger always returns focus to itself after executing each line, when it highlights the next line.
|
|If you *don't* want to debug the file, why run it in the debugger?

I don't see a need for IDE to keep giving itself focus when running to end or
breakpoint. Debugging may involve console input, in which case having to switch
to the console every time is a pain, and if the console won't keep focus long
enough to accept input, it's impossible. I often have an INKEY/SWITCH routine
inside a batch file's loop so I can communicate with the batch file while it's
running a forever loop to pause/resume, reset parameters or counters, quit, or
do just about anything else without interrupting the loop.
 
On Tue, 07 Sep 2010 23:02:28 -0400, rconn <> wrote:

|---Quote (Originally by vefatica)---
|And putting "EXIT" is a BTM and running/debugging in IDE causes IDE to exit (and not TCC).
|---End Quote---
|
|Right -- so?
|
|You're presumably invoking the IDE from a stand-alone TCC session. The EXIT will terminate the IDE session running the batch file; it doesn't have any effect on the parent TCC.EXE that launched IDE. (Did you *want* it to kill the parent session?)

No, that was just an experiment, and I was wrongly thinking that the parent TCC
was running the batch file.
 

Similar threads

Back
Top