|
|
|||||||
I understand the need to have the default mode BREAK OFF, but I just gave myself and unexpected log off by exiting out of a script I was debugging before I had evaluated BREAK ON. I was thinking if we could add a command line switch to turn BREAK ON it would be much easier to avoid screwing yourself up. |
||||||||
|
|
|||||||
make another script on your desktop Code: break on call "scriptname.kix" |
||||||||
|
|
|||||||
Ya I could do that. The time it gets me is usually when I create something quick. Still a pain in the backside. |
||||||||
|
|
|||||||
You can use a command line switch (kind of): Code: If Not IsDeclared($BREAK) $BREAK="OFF" EndIf "Switching BREAK "+$BREAK+@CRLF $=Execute("BREAK "+$BREAK) "Try and break me in the next 5 seconds!" Sleep 5 Now call the script witth the option: Quote: kix32 myscript.kix $BREAK=ON If you don't want to specify the state you can simplify it: Code: If IsDeclared($BREAK) BREAK ON EndIf "Try and break me in the next 5 seconds!" Sleep 5 Now just call the script with $BREAK to enable it: Quote: kix32 myscript.kix $BREAK If you want BREAK enabled by default unless you specifically disable it when the script goes into production, just change the logic slightly and include it in all your scripts: Code: BREAK ON If IsDeclared($NOBREAK) BREAK OFF EndIf "Try and break me in the next 5 seconds!" Sleep 5 When you run the script from the command line break is enabled, when you push it into production just make sure that $NOBREAK is specified on the command line. Finally, how about deciding the break state based on group membership or login? Code: BREAK OFF If InGroup("DOMAIN\Give me a break") "Break enabled for support staff"+@CRLF BREAK ON EndIf |
||||||||
|
|
|||||||
Thanks guys, I think I am just in the minority for what I want. I got into writing full applications in Kix using Kixforms for the GUI. These are "scripts" that are some 4000 lines long. Typically, that is just too big to easily debug with -d and stepping through the script. I got into what might be the bad habit of dumping a problem function into a seperate script and debuging it there with known inputs. I probably should just use DEBUG ON, heck I should be using a different language, but the seperate script always made it easier to edit just that part of the script without losing my spot. The problem with doing this is the classic. 1. Copy the code into a brand new script 2. "Lets fire it up and see what is wrong." 3. "Oh look, there it is. *muddle with code* Guess I don't need to debug." 4. Close the window without geting past BREAK ON 5. Scream "NOT AGAIN!" as I log myself off. |
||||||||
|
|
|||||||
If its any comfort to you, I've always wished Break was on by default. In fact I'm sure we've had discussions of this in past, but there was no consensus. |
||||||||
|
|
|||||||
Get into the habit of pulling a template header into the top of every script you create, no matter how small or ephemeral it might be. Your template will have placeholders for documentation, standard functions and basic settings that you need - including things like turning BREAK off for yourself, setting WrapAtEOL and Explicit and so-on. The same advice applies for any coding language, not just KiXtart, and will save you a bit of self-cursing in the long run. |
||||||||
|
|
|||||||
Changing kix to have break on by default might break a lot of scripts imho. |
||||||||
|
|
|||||||
I don't think it would break anything, but it would definately require turning it on when needed... alas it don't matter |
||||||||
|
|
|||||||
And many want and run WKIX32 which has no console output and thus nothing to break on |
||||||||
|
|
|||||||
Reply from John_Ross has been moved to: http://www.kixtart.org/forums/ubbthreads.php?ubb=showflat&Number=198448 because it had nothing to do with the original post. |
||||||||
|
|
|||||||
As yu may have seen, 4.67 now has a commandline option to start with BREAK ON... |