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

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

It has never been a convenient way to stop the IDE, since that's running in
a different session than the parent TCC session in the console window. All
it really guarantees is that the console window handle used by the debugger
is now invalid.


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

I cannot reproduce any of those messages, and indeed I know of no way they
could possibly be generated (outside of a TCSTART / TCEXIT).


> So IDE is attaching to its parent's console, running the batch file and
> processing console I/O ... right?

The IDE attaches to its parent console if one exists; otherwise it creates a
new console. It is simply sharing the console window; there is no handle
inheritance or session sharing going on.

Rex Conn
JP Software
 
> 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.

Since this is:

1) The way the debugger has ALWAYS behaved, and

2) Very useful to see what the debugger is currently executing, and

3) Only relevant if you don't actually wait for keyboard input, and

4) It has apparently never been a problem for you previously,

I don't consider this a problem (except in the somewhat tortured edge case
you generated), and it will not be changed in v12.

Rex Conn
JP Software
 
On Wed, 08 Sep 2010 00:02:55 -0400, rconn <> wrote:

|---Quote (Originally by vefatica)---
|The "Display folding margin" option is not remembered.
|---End Quote---
|
|WAD (because there's no conceivable benefit in turning it off permanently).

If there's any benefit in turning it off temporarily, then there's benefit in
turning it off permanently. I don't want it (period!). As I said before, it's
difficult to position the caret at the beginning of a line and a mis-click in
that vicinity can collapse a whole paragraph. That's another gripe, clicking
anywhere in the folding margin adjacent to text (i.e., not only on the +/-
boxes) collapses the text. I have done that unwittingly many times.

I understand that, it being third-party software, there are things you can't do.
But if you can let is turn off the folding margin permanently, please do.
 
On Wed, 08 Sep 2010 00:03:03 -0400, rconn <> wrote:

|---Quote---
|> X-ing the console has always been a very convenient way to stop
|> everything, including IDE.
|---End Quote---
|It has never been a convenient way to stop the IDE, since that's running in
|a different session than the parent TCC session in the console window. All
|it really guarantees is that the console window handle used by the debugger
|is now invalid.

A simple test shows that if the user X's the console after a GUI app has
attached to the console, the GUI app is terminated. Run this and watch TaskMgr.

INT WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR
lpCmdLine, int nCmdShow)
{
if ( !AttachConsole(-1) )
return 1;
Sleep(60000);
return 0;
}
 
On Wed, 08 Sep 2010 00:03:07 -0400, rconn <> wrote:

|---Quote---
|> 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.
|---End Quote---
|Since this is:
|
|1) The way the debugger has ALWAYS behaved, and

|2) Very useful to see what the debugger is currently executing, and

I'm not talking about stepping. If your running to end or breakpoint,
everything in the debugger is happening so fast that you can't tell anything
except that it's flying around a loop. And the debugger can update its window
without having focus.

|3) Only relevant if you don't actually wait for keyboard input, and

I do that with some regularity.

|4) It has apparently never been a problem for you previously,

Actually it was, once or twice.

|I don't consider this a problem (except in the somewhat tortured edge case
|you generated), and it will not be changed in v12.

Too bad! Maybe in the next version.
 
On Wed, 08 Sep 2010 00:03:03 -0400, rconn <> wrote:

|---Quote---
A simple test shows that if the user X's the console after a GUI app has
attached to the console, the GUI app is terminated.

That also goes for a GUI app that has used AllocConsole().
 
> I'm not talking about stepping. If your running to end or breakpoint,
> everything in the debugger is happening so fast that you can't tell
> anything
> except that it's flying around a loop. And the debugger can update its
> window without having focus.

The debugger cannot highlight the current line without getting the focus.

Rex Conn
JP Software
 
On Wed, 08 Sep 2010 08:23:49 -0400, rconn <> wrote:

|---Quote---
|> I'm not talking about stepping. If your running to end or breakpoint,
|> everything in the debugger is happening so fast that you can't tell
|> anything
|> except that it's flying around a loop. And the debugger can update its
|> window without having focus.
|---End Quote---
|The debugger cannot highlight the current line without getting the focus.

I see (but why?). I can't even run another app (browser/email/et c.) while IDE
is doing that. I'm surprised Windows lets you how focus like that and I
certainly don't like it.
 
On Wed, 08 Sep 2010 08:23:49 -0400, rconn <> wrote:

I see (but why?). I can't even run another app (browser/email/et c.) while IDE is doing that. I'm surprised Windows lets you how focus like that and I
certainly don't like it.

That was meant to be "hog" (not "how"). You can do almost nothing else in Windows while IDE is updating its display. I think that's very wrong (and still wonder why it is so).
 
I think part of this confusion arises from a familiarity with using
exisiting programming debuggers ala Visual Studio. We think of IDE like
VS. When I debug an application in VS, VS is not running the code, the
app is. VS is the debugger and allows the app to stop its execution and
return control to VS.

So it is with BDEBUGGER. We *expect* that when we debug a batch script,
that TCC is actually executing and we are debugging the script which is
executing in TCC. The reality is completely different however.

-Scott

vefatica <> wrote on 09/07/2010 11:36:49 PM:


> 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
theparent TCC

> was running the batch file.
>
>
>
>
 
But if you are executing to end or to breakpoint, there is no "current
line." There is only a current line when the script is paused - i.e.
single step or breakpoint.

-Scott

rconn <> wrote on 09/08/2010 08:23:47 AM:


> ---Quote---
> > I'm not talking about stepping. If your running to end or breakpoint,
> > everything in the debugger is happening so fast that you can't tell
> > anything
> > except that it's flying around a loop. And the debugger can update
its

> > window without having focus.
> ---End Quote---
> The debugger cannot highlight the current line without getting the
focus.

>
> Rex Conn
> JP Software
>
>
>
>
 
But if you are executing to end or to breakpoint, there is no "current line." There is only a current line when the script is paused - i.e. single step or breakpoint.

Not true -- the debugger is executing the script line-by-line; the current line is the one currently being executed. The debugger simply doesn't pause at each line if you don't have single-stepping or a breakpoint enabled.
 
On Wed, 08 Sep 2010 12:04:41 -0400, rconn <> wrote:

|---Quote (Originally by vefatica)---
|I see (but why?). I can't even run another app (browser/email/et c.) while IDE is doing that. I'm surprised Windows lets you how focus like that and I
|certainly don't like it.
|---End Quote---
|
|Windows will not let you do that -- unless you've specifically modified a registry entry to allow it (which you apparently have done).

Yes I have done that. And now I appreciate Microsoft's intention more. Grabbing
focus can be rude; IDE's version of it is downright obnoxious.
 
On Wed, 08 Sep 2010 12:06:20 -0400, rconn <> wrote:

|---Quote (Originally by samintz)---
|But if you are executing to end or to breakpoint, there is no "current line." There is only a current line when the script is paused - i.e. single step or breakpoint.
|---End Quote---
|
|Not true -- the debugger is executing the script line-by-line; the current line is the one currently being executed. The debugger simply doesn't pause at each line if you don't have single-stepping or a breakpoint enabled.

There's little to be gained from that highlighting when running freely. It'd be
fine with me if IDE only highlighted when it was debugging and paused or ar a
break.
 
On Wed, 08 Sep 2010 12:04:41 -0400, rconn <> wrote:

|Windows will not let you do that -- unless you've specifically modified a registry entry to allow it (which you apparently have done).

Yes I have done that. And now I appreciate Microsoft's intention more. Grabbing
focus can be rude; IDE's version of it is downright obnoxious.

Which registry entry is that?
 
On Wed, 08 Sep 2010 18:48:10 -0400, David Marcus <> wrote:

|---Quote (Originally by vefatica)---
|On Wed, 08 Sep 2010 12:04:41 -0400, rconn <> wrote:
|
||Windows will not let you do that -- unless you've specifically modified a registry entry to allow it (which you apparently have done).
|
|Yes I have done that. And now I appreciate Microsoft's intention more. Grabbing
|focus can be rude; IDE's version of it is downright obnoxious.
|---End Quote---
|Which registry entry is that?

If I recall correctly, in HKEY_CURRENT_USER\Control Panel\Desktop
it's one or both of ForeGroundLockTimeout and ForegroundFlashCount. Mine are 1
and 0, respectively, the most lenient settings I believe. Google it to get a
more detailed explanation.
 
> Yes I have done that. And now I appreciate Microsoft's intention more.
> Grabbing focus can be rude; IDE's version of it is downright obnoxious.

This is the way it's behaved for more than 8 years; apparently you've either
never noticed it before or you have a high tolerance for rudeness!

Practically speaking, the debugger *has* to get the focus back from the
console, or it would be impossible to single-step without requiring the user
to click back and forth between the console & IDE windows for every command.

Rex Conn
JP Software
 
On Wed, 08 Sep 2010 21:19:56 -0400, rconn <> wrote:

|Practically speaking, the debugger *has* to get the focus back from the
|console, or it would be impossible to single-step without requiring the user
|to click back and forth between the console & IDE windows for every command.

I have no qualms about IDE having focus when it (actually the user) is single
stepping.
 
On Wed, 08 Sep 2010 21:19:58 -0400, rconn <> wrote:

|---Quote---
|> There's little to be gained from that highlighting when running freely.
|> It'd be fine with me if IDE only highlighted when it was debugging and
|> paused or ar a break.
|---End Quote---
|The current behavior is the way most users requested it (many) years ago.

I'll take your word for that. And I'll say again that the highlighting while
free-running is useless (though it is pretty, slows things down, and prevents
the use of other apps). Apparently today, few care.
 
> I don't see a need for IDE to keep giving itself focus when running to
> end or breakpoint.

I apparently haven't explained the IDE behavior clearly. To recap:

* The IDE runs scripts itself; there is no external app (such as TCC.EXE)
involved.

* The IDE is not switching focus between itself and another app; it is
(normally only rarely) switching focus between its own two windows.

* The IDE is not switching focus between its own two windows on every
command; it only does it when it detects that you're running a command that
requires keyboard input (like INKEY or INPUT).

* This is a *good* thing, as it normally leaves the user in the debugger
window, where they have immediate access to all of the debugging tools.

* This works well in 99.9999% of all cases; the only one where it creates
a potential problem is in your (slightly demented) example of putting an
INKEY /W0 inside an infinite loop, and then telling the debugger to run (and
not debug) the script. (The IDE detects the INKEY, switches to the console
window, immediately times out, switches back to the debugger window, ad
infinitum.)

I do NOT feel that it's a good idea to force the user to manually switch
between windows for the 99.9999% of batch files that do not suffer from this
issue, and I have no intention of changing the current behavior for v12.

Rex Conn
JP Software
 
On Thu, 09 Sep 2010 23:56:24 -0400, rconn <> wrote:

|---Quote---
|> A simple test shows that if the user X's the console after a GUI app
|> has attached to the console, the GUI app is terminated.
|---End Quote---
|Yes, but I wouldn't call crashing the app a "convenient way to terminate"
|it!
|
|Most apps appreciate the opportunity to shut down gracefully.

After AttachConsole oe AllocConsole, a console ctrl handler will allow for that
(tested). I don't think it's a crash; rather just X-ing a CUI app.
 

Similar threads

Back
Top