#BREAK ON/OFF ?other?

[Tom Tallardy]

I have a 10+yr old utility originally written in PB.
updated to use a "master file" on a (home LAN) network drive.
it runs on any one of four computers on the network, using the trick of keeping a file open & looking for err70 - to indicate to any other user "program in use"
the master file is a simple (if there is such a thing...) csv file.

when writing new PB files, one irk of mine is having to specific #BREAK ON - the default is off.
for quick and dirty stuff, it's so convenient to hit the Big Red X

well, I decided to modify the program so the master file is kept local and upon forcing the user to execute a menu "Quit" command - so can FILECOPY [localfilr],[netdrivefile] prior to a shutdown.

I removed #BREAK ON
I explicitly put in #BREAK OFF
the application still responds to the upper right corner X.

with my app still 'open', it I create a new program

#COMPILE EXE
#DIM ALL
FUNCTION PBMAIN () AS LONG
PRINT "hello world"
WAITKEY$
END FUNCTION

the default #BREAK OFF works and one cannot exit the program via the title bar X.

is there some known oddity or order of compile like
CONSOLE NAME "My App"
or using
#INCLUDE "win32api.INC"
that overrides an explicit #BREAK OFF?

this is all a W10 environment. I have my suspects about W10 using cached info vs a 'newly compiled version' but that's another horror story....

[Tom Tallardy]

curious. no ideas?

I saved my ide .bas as a .txt file

then created a "new file" in PB
pasted in a 'copy all' of the txt file
same results.

obviously there is some legal PB coding that over rides #BREAK OFF

[Manuel Valdes]

Hi Tom,

#BREAK ON is fully functional in PBCC Graphic Window mode, so maybe you can rewrite your program to fit. Not a difficult task in my opinion.

[Dale Yarker]

obviously there is some legal PB coding that over rides #BREAK OFF

No. My PBCC 6.04 demo code follows the #BREAK ON/OFF setting.

Master copy on LAN not getting/using latest compiled version?

Cheers,

[Bud Durland]

I'm not sure if a console compiler executable can be "taught" to ignore the red "X". In Windows GUI programs, the message to close the window can be intercepted and dealt with, bit not sure if CC has a similar mechanism.

[Dale Yarker]

GRAPHIC WINDOW has GRAPHIC WINDOW NONSTABLE and GRAPHICWINDOW STABLE commands.
TXT.WINDOWs are always stable. (No "X".)

My read of what Tom wants is #BREAK ON without having to type it in each new source code.

[Manuel Valdes]

GRAPHIC WINDOW has GRAPHIC WINDOW NONSTABLE and GRAPHICWINDOW STABLE commands.

Yes, then he could switch it programmatically. (GRAPHIC WINDOW STABILIZE hWin / GRAPHIC WINDOW NONSTABLE hWin )

[Dale Yarker]

Too quick . . . default is nonstable. Equivalent to break on.

[Dave Biggs]

I removed #BREAK ON
I explicitly put in #BREAK OFF
the application still responds to the upper right corner X.

This should not happen in PBCC60^. Can you duplicate this with compilable test code?

NOTE> #BREAK [ON|+ | OFF|-] Was a different Metastatement in PBCC5 !!

[Tom Tallardy]

in post #1 I show a code snippet that compiles/runs/behaves as advertised.
it defaults to #break off - no can exit by title bar X
If I explicitly use #break on - the title bar X is active.
so - my copy of PBCC6.04 is apparently 'intact' - W10 is apparently intact - the HP laptop is apparently 'intact'

I want #break off - I want the user to exit the program only by menu option so I can ensure the last changes to the common file are copied to the network drive.

this is PBCC 6.04

it's my own little application that is not obeying the rules. it will not default to #break off, it will not obey an explicit #break off.
tried setting the network location to local disk - ie. running completely on that one machine

the utility sits on the local hard drive(s) and accesses the common file on the network.

this utility probably started out in PB4.x - so....
I saved the source code as a .txt file, cold booted the machine, used PB IDE to create a new file, saved as 'test.bas'
copied/pasted the .txt contents into the new test.bas and compiled.
same behavior.
that indicates to me that something in the code is 'over ruling' the explicit #break off statement.

it's not any kind of fancy code - calling up 'Select printer' is about as extraordinary as it gets, using #INCLUDE "win32api.INC" - various MOUSE functions.

[Stuart McLachlan]

Debugging 101

If you have appropriately "modularised" your code, comment out all functions/sub calls in PBMAIN and replace them with simple assignments of appropriate return values. Re- compile and break should work. If it doesn't - remove all the commented out code and post the code here.
If it does start to work, start re-implementing the functions/subs one at a time until it fails. Then post the code you have just uncommented.

If it's a poorly built monolithic program with GOSUBS, GOTOs everywhere, it gets much harder to debug. Try commenting out blocks of code (inserting assigned values where necessary) and re-compiling unitl the problem doesn't occur.

[Dave Biggs]

It's possible that there is additional code in the source that affects the System Menu?

eg.

#COMPILE EXE
#DIM ALL
#Break ON
#Include "win32api.inc"
 
FUNCTION PBMAIN () AS LONG
 LOCAL MenuHandle As LONG
 
  ? "Any key to force BREAK OFF.."
  WAITKEY$
 
  MenuHandle = GetSystemMenu(Con.Handle, %FALSE)
  DeleteMenu(MenuHandle, %SC_CLOSE, %MF_BYCOMMAND)
  
  ? "Any key to restore [X] "
  WaitKey$
 
 Local sItem As String : sItem = "Close" + $TAB + "Alt-F4"
  InsertMenu(MenuHandle, %SC_CLOSE, %MF_BYCOMMAND, %SC_CLOSE, ByVal StrPtr(sItem))
 
  ? "Any Key To Exit - even [X] :)"
  WAITKEY$
 
END FUNCTION

[Tom Tallardy]

Dave - that compiles and runs "as expected" on this machine.

I've commented out all the metacommands - including inc'ing win32api -
remmed out anything that didn't compile eg MessageBox, etc.
remmed out everything con. related - screen functions, mouse functions...
removed (old syntax) CONSOLE NAME "TSP" - which is methinks the only bit that affects the title bar/system defaults....

it compiles (certainly won't run, I suspect) but it does not default to break off nor does it recognize an explicit #break off.

nothing but math an string functions left.... (famous last words....)
so I'm eliminating subs/functions one by one...

[Dave Biggs]

Did you try compiling the file with a different file name?
(In case there is some weird registry setting related to the original name)

[Michael Mattias]

I'm not sure if a console compiler executable can be "taught" to ignore the red "X"

Maybe it won't learn,,, but you may handle the processing yourself.

The SetConsoleCtrlHandler() function can be used to redirect console events (e.g CTRL_BREAK_EVENT) to your own user-defined procedure... .and if you return TRUE from your handler code, the default handler ("Close this console and end this program") is skipped.

When you read the doc you will see there are multiple events you may intercept this way when creating a console program.

[Tom Tallardy]

Dave Biggs
Did you try compiling the file with a different file name?
(In case there is some weird registry setting related to the original name)

see post #10.
copied code to NotePad - no warnings of 'characters will be lost'
cold boot
imported code from DOS .txt file
different/new name
no joy.

[Dave Biggs]

so I'm eliminating subs/functions one by one...

Are we there yet? (Empty PBMain)

BTW another way BREAK OFF can be undone is when the System Menu is reset with..

  MenuHandle = GetSystemMenu(Con.Handle, %True)    ' CONSHNDL PBCC5

That resets the Console Window System Menu and leaves you with this 'default' when the Caption Bar is Right-Clicked..



You mentioned earlier -

forcing the user to execute a menu "Quit" command

How is that menu implemented?

[Tom Tallardy]

"menu" execution is by capturing row/column of mouse click where "Quit" is printed on screen. old old school.

I extracted PBMain and got it to compile; #break off default works - so there something in one of the 30 some SUBs/FUNCTIONs that's triggering the problem.
since no compile/runtime/debug errors are generated, I'll need to remove one by one to find it. time consuming because I have to dummy up various&sundry values in order to get it to compile...

as to failing code not shown, the code is 3,000 lines. I doubt anyone wants to spend time looking through it....

[Dave Biggs]

Being able to run a console app with BREAK OFF can prevent 'unregulated' closing, however a persistant user might still close the app via it's task bar Jump List or thumbnail, both of which will still have active [X] Close options

Another solution could be to use a 'Handler Routine', catch the sc_close event and use that to trigger a file save / copy.

The drawback there is that a CTRL_CLOSE_EVENT notification occurs after the console has begun its close down process and console functions are 'no longer reliable'.

In my tests the console app and associated processes are gone within a maximum time of 5 seconds or so after the notification.

The attached test code explores a way of ensuring there is enough additional time to complete any house keeping required..
'

'#BREAK OFF             ' (PBCC60^) Default is OFF ie [X] on Caption Bar is disabled
#DIM ALL
#COMPILE EXE
#INCLUDE "WIN32API.INC"
'------------------/
 
FUNCTION CheckForMutex(ProgName AS ASCIIZ) AS LONG
 LOCAL hMutex AS DWORD
  hMutex = CreateMutex(BYVAL %NULL, 0, ProgName)
  IF hMutex = %NULL THEN FUNCTION = 0 : EXIT FUNCTION
  IF GetLastError = %ERROR_ALREADY_EXISTS THEN _            ' * App already running!
  FUNCTION = 1 : EXIT FUNCTION
END FUNCTION
'------------------/CheckForMutex
 
SUB HouseKeep()
  FILECOPY EXE.FULL$, EXE.PATH$+EXE.NAME$+".bac"  ' eg
  SLEEP 8000    ' eg test extended time by adding more here
  PLAY WAVE ("\windows\media\tada.wav")
  SLEEP 2000    ' time to play sound :)
END SUB
'------------------/HouseKeep
 
FUNCTION PBMAIN() AS LONG
  IF CheckForMutex("Mutex_"+EXE.NAME$) = 1 THEN
    IF COMMAND$(1) = "HK" THEN CALL HouseKeep()             ' *
    EXIT FUNCTION
  END IF
 
  CON.CAPTION$ = "Console Handler Test"                     ' define handler for CLOSE events
  SetConsoleCtrlHandler CODEPTR(CCtrlHandler), 1
 
  ? "** ConsoleCtrlHandler Test - Press Esc to Quit **" : ?
  ? "Tests: [X] / Sysmenu Close, Close button on App's TaskBar thumbnail or Jump List" : ?
  ?
  CON.WAITKEY$($ESC)
END FUNCTION
'------------------/PBMain
 
FUNCTION CCtrlHandler(BYVAL dwEvent AS DWORD) AS LONG
  SELECT CASE dwEvent
    CASE %CTRL_CLOSE_EVENT  ' Console is closing - can't be circumvented !!
      ?                     ' console functions no longer reliable..
      ? "[X] button clicked or other Close event"
      ?
      ? "CTRL_CLOSE_EVENT is unstoppable! - but takes a few seconds :)"
      WinBeep 400,400
 '      Call HouseKeep()
      SHELL EXE.FULL$ + " HK"   ' Open new process to ensure file copy completes
      SLEEP 5000        ' even with 10000 closes after ~ max 5 seconds anyway
  END SELECT
END FUNCTION
'------------------/CCtrlHandler

[Tom Tallardy]

this has to be some goofy Win10 hate for console windows thing.

got PBMain compiling and break on/off working as advertised.
as I added back subs/function (pieces) at a time, here's the (first piece of) code that causes #BREAK OFF to be ignored:

in this in a SUB / END SUB code
explicit CALL (Sub) used


IF ENote&=1 THEN
' COLOR 14,0
l&=5
' INCR l&:LOCATE l&,5:PRINT "Advisory Note:"
' INCR l&:LOCATE l&,5:PRINT "the length of some item locations exceeds maximum allowed (5 characters)"
' INCR l&:LOCATE l&,5:PRINT "Excess length has been truncated."
' INCR l&:LOCATE l&,5:PRINT ""
' INCR l&:LOCATE l&,5:PRINT "press any key to continue . . ."
CON.WAITKEY$
CLS
END IF

if I take out any one of the remmed (') for those lines the compile goes from break off to break on.
an IF clause in a SUB - not exactly anything that seems terrible suspicious....

tried con.locate
tried con.cell
tried "legacy console" properties
tried quick edit on/off - and all those 'options' under properties.

if I compile that snippet alone, no problems.
now..... LOCATE then PRINT is used a few billions times without issue.
but not here.

if I eliminate these lines in the 'finished working code" compiled and behaving with Break on, it still stays break on.
that leaves the possibility that other code compiled subsequent to this snippet is _also_ causing the problem - however why COLOR or LOCATE causes a problem in the (truncated but compiling) code is a total mystery.