AP/SCO Inhibit Break Key

AP/SCO Inhibit Break Key

Post by Steven L. Ste » Sat, 22 Aug 1998 04:00:00



In AP/SCO 6.1.20, I'm attempting to disable the Break Key in an external
subroutine.  But, if the Break Key is pressed, even though it is disabled
in the called subroutine, it gets processed when returning to the calling
subroutine.

Also, EXECUTE "BREAK-KEY (F" doesn't seem to disable the Break Key within
the Basic program.  BREAK OFF is the only way to inhibit the Break Key.

So, if my subroutine is:

SUBROUTINE INHIBIT.BREAK
  EXECUTE "BREAK-KEY (F"; * disable break key
  crt "try Break Key!"
  input nada
  EXECUTE "BREAK-KEY (N"; * enable break key
  crt "returning from inhibit.break"
  RETURN

And, my calling program (TEST.INHIBIT.BREAK) is:

CALL INHIBIT.BREAK
crt "returned from INHIBIT.BREAK"
stop

The results are:
try Break Key!
?
<break>
*I4
*

If I change SUBROUTINE to:
SUBROUTINE INHIBIT.BREAK
  break off; * disable break key
  crt "try Break Key!"
  input nada
  break on; * enable break key
  crt "returning from inhibit.break"
  RETURN

The results are:
try Break Key!
?
<break>

*I7
*g returning from inhibit.break
returned from inhibit.break

So, as soon as BREAK ON is executed, the previous <break> is processed.
This seems to be a bug to me.  Also, why doesn't the EXECUTE "BREAK-KEY
(F" really enable BREAK within the BASIC program?  It seems to be
irrelevant.

TIA

--
Steven L. Stein
Cornell Business Services

 
 
 

AP/SCO Inhibit Break Key

Post by Tony Gravag » Sun, 23 Aug 1998 04:00:00


OK Steven, you get one cookie out of two:

The following code (my variation on yours) does indeed fail in AP and
on D3:
01 print "1"
02 break off
03 print "2"
04 input x
05 print "3"
06 break on
  ** fall to debug here because we buffered the break
07 print "4"

I'll check this out at the office on Monday.  If there is already an
action item on this then all we can do is wait for a patch.  If there
is not an action item on it then I'll enter one in your name.  If
there is a short-term work-around I'll post it here.

Thanks for bringing this one up.  Sorry about the bug.  It's
apparently been out there for years and no one has noticed yet.  I
think this is because in most user applications we probably want to
turn the break key off and leave it off unless there is some need to
turn it on.

On the issue of \execute "break-key-off"\ there's no prize, sorry:
The TCL break-key functions are intended to work at their current
level and higher.  When we push a level to set the break status, we
intentionally don't want to bring it back with us to a lower level.
If you want to control breaks from BASIC, you should be using the
BASIC "break off" statement -- uh, yes, despite the aforementioned
issue.

Regards,
Tony

http://members.home.net/gravagno
(Restructured/Updated 17-Aug-1998)
Pick Systems Quality Assurance Manager
http://www.picksys.com
## Insert disclaimer here about how these comments
## are mine and not my employer's.
## Oh, I did?
## Never mind.

 
 
 

AP/SCO Inhibit Break Key

Post by steve lancou » Sun, 23 Aug 1998 04:00:00


Tony,

        I battled break-key problems in AP/SCO for a year before moving to D3
after being told a year ago that there would be no fix for the problems
in AP.  The problems I reported weren't the same as reported by the
poster here, but it might be worth checking whether they are related.
Talk to Joe Rabinski for details.  I was also told that I was the first
to report the problem I was having, although a deja-news search at the
time found two other posts in CDP reporting the same problem.

Thanks.


> OK Steven, you get one cookie out of two:

> The following code (my variation on yours) does indeed fail in AP and
> on D3:
> 01 print "1"
> 02 break off
> 03 print "2"
> 04 input x
> 05 print "3"
> 06 break on
>   ** fall to debug here because we buffered the break
> 07 print "4"

        <snip>

Quote:>  It's apparently been out there for years and no one has noticed yet.  

        <snip>

--
Steve Lancour

 
 
 

AP/SCO Inhibit Break Key

Post by Tony Gravag » Wed, 26 Aug 1998 04:00:00




Quote:>OK Steven, you get one cookie out of two:

Presto change-o ...  Tony was wrong.  Sorry about that.  One of my
highly esteemed colleagues has informed me that the behavior exhibited
by the "break off" is actually correct.  The purpose of turning off
the break key is to prevent the user from hitting break.  If it is
turned on again, it must be in a place where encountering a break is
OK, even if the original event occurred at some point earlier.  As I
said in the previous post, an application will turn off the break and
generally leave it off because you either do want a user to break or
you don't.  If a "break off" is issued, the break signal is held.  If
the user logs off, the break is discarded, so you never see it.

This wasn't a bug.  The fact that it hasn't been changed in so long
confirms that as well.  This functionality goes WAY back and thus
cannot be changed, lest it should break lots of other apps...

My advice, Steve, is to just leave it off and tell users not to break,
or turn it on when required and establish a known policy for how such
events are to be handled.

(Thanks to Dr. Who.)
Tony


http://members.home.net/gravagno
(Restructured/Updated 17-Aug-1998)
Pick Systems Quality Assurance Manager
http://www.picksys.com
## Insert disclaimer here about how these comments
## are mine and not my employer's.
## Oh, I did?
## Never mind.

 
 
 

AP/SCO Inhibit Break Key

Post by Steven L. Ste » Sat, 29 Aug 1998 04:00:00


Tony,

If my program (subroutine) disables break in Basic, it gets reset (i.e.
enabled) when the subroutine is exited.  I want my application to ignore
breaks (i.e. pretend they aren't there, even if they are).  I consider the
fact that I can't turn it off in a subroutine and not have it processed as
soon as I exit a "bug".  If this is a feature, then I need a way to
achieve the desired result.

Thanks for the reply.  I trust someone at Pick Systems can provide a
work-around solution.  




> >OK Steven, you get one cookie out of two:

> Presto change-o ...  Tony was wrong.  Sorry about that.  One of my
> highly esteemed colleagues has informed me that the behavior exhibited
> by the "break off" is actually correct.  The purpose of turning off
> the break key is to prevent the user from hitting break.  If it is
> turned on again, it must be in a place where encountering a break is
> OK, even if the original event occurred at some point earlier.  As I
> said in the previous post, an application will turn off the break and
> generally leave it off because you either do want a user to break or
> you don't.  If a "break off" is issued, the break signal is held.  If
> the user logs off, the break is discarded, so you never see it.

> This wasn't a bug.  The fact that it hasn't been changed in so long
> confirms that as well.  This functionality goes WAY back and thus
> cannot be changed, lest it should break lots of other apps...

> My advice, Steve, is to just leave it off and tell users not to break,
> or turn it on when required and establish a known policy for how such
> events are to be handled.

> (Thanks to Dr. Who.)
> Tony


> http://members.home.net/gravagno
> (Restructured/Updated 17-Aug-1998)
> Pick Systems Quality Assurance Manager
> http://www.picksys.com
> ## Insert disclaimer here about how these comments
> ## are mine and not my employer's.
> ## Oh, I did?
> ## Never mind.

--
Steven L. Stein
Cornell Business Services