No announcement yet.

#BREAK ON/OFF ?other?

  • Filter
  • Time
  • Show
Clear All
new posts

  • #BREAK ON/OFF ?other?

    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

    #DIM ALL
    PRINT "hello world"

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

  • #2
    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


    • #3
      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.


      • #4
        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?



        • #5
          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.
          Real programmers use a magnetized needle and a steady hand


          • #6
            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.


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


              • #8
                Too quick . . . default is nonstable. Equivalent to break on.


                • #9
                  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 !!
                  Last edited by Dave Biggs; 21 Jan 2021, 11:30 PM. Reason: Noted PBCC5 use of #BREAK ON/OFF was different
                  Rgds, Dave


                  • #10
                    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.


                    • #11

                      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.


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

                        #COMPILE EXE
                        #DIM ALL
                        #Break ON
                        #Include ""
                        FUNCTION PBMAIN () AS LONG
                         LOCAL MenuHandle As LONG
                          ? "Any key to force BREAK OFF.."
                          MenuHandle = GetSystemMenu(Con.Handle, %FALSE)
                          DeleteMenu(MenuHandle, %SC_CLOSE, %MF_BYCOMMAND)
                          ? "Any key to restore [X] "
                         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] :)"
                        END FUNCTION
                        Rgds, Dave


                        • #13
                          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...


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


                            • #15
                              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.
                              Michael Mattias
                              Tal Systems (retired)
                              Port Washington WI USA
                              [email protected]


                              • #16
                                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.


                                • #17
                                  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..

                                  Click image for larger version

Name:	ConSysMenu.PNG
Views:	75
Size:	1.5 KB
ID:	804324

                                  You mentioned earlier -
                                  forcing the user to execute a menu "Quit" command
                                  How is that menu implemented?
                                  Rgds, Dave


                                  • #18
                                    "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....


                                    • #19
                                      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
                                      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
                                      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" : ?
                                      END FUNCTION
                                      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
                                      Rgds, Dave


                                      • #20
                                        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
                                        ' 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 . . ."
                                        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.