Hi everyone,
I have a livecode stack that works perfectly in the ide..... but as a standalone (windows) there is a crash on start.
As far as I know right now my only option is to revert to the last save where the standalone didn't crash and re-insert the code and features i've put in since and try and nail down the source of the crash.
Is there another way to debug these kinds of crashes and finding what caused the crash in the standalone?
Thanks.
Advice on debuggin crashing windows standalone
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller
Advice on debuggin crashing windows standalone
Founder & Developer @ MakeShyft R.D.A - https://www.makeshyft.com
Build Software with AppStarterStack for Livecode - https://www.AppStarterStack.com
Save Time with The Time Saver's Toolbox - https://www.TimeSaversToolbox.com
Build Software with AppStarterStack for Livecode - https://www.AppStarterStack.com
Save Time with The Time Saver's Toolbox - https://www.TimeSaversToolbox.com
Re: Advice on debuggin crashing windows standalone
Usually LiveCode Standalones should not crash at all. If you can share it, I'm sure that support@runrev.com would be interested in your stack, to see what they need to fix for it not to crash as a standalone.
Other then that, i guess you could try disabling externals and/or not running code on startup (assuming it could be your scripts that cause it).
Other then that, i guess you could try disabling externals and/or not running code on startup (assuming it could be your scripts that cause it).
Various teststacks and stuff:
http://bjoernke.com
Chat with other RunRev developers:
chat.freenode.net:6666 #livecode
http://bjoernke.com
Chat with other RunRev developers:
chat.freenode.net:6666 #livecode
Re: Advice on debuggin crashing windows standalone
Hmmm.... ok what I will do is I will figure out what is causing the crash, repeat it, and then send in a report.
Founder & Developer @ MakeShyft R.D.A - https://www.makeshyft.com
Build Software with AppStarterStack for Livecode - https://www.AppStarterStack.com
Save Time with The Time Saver's Toolbox - https://www.TimeSaversToolbox.com
Build Software with AppStarterStack for Livecode - https://www.AppStarterStack.com
Save Time with The Time Saver's Toolbox - https://www.TimeSaversToolbox.com
Re: Advice on debuggin crashing windows standalone
Be sure and remove all 3rd party externals before sending the problem on to RunRev. They would be more interested that way.
For me (as an external developer) 90% of the crashes I get are in the 4th party libraries I use in my externals.
For me (as an external developer) 90% of the crashes I get are in the 4th party libraries I use in my externals.
Re: Advice on debuggin crashing windows standalone
Tom-
1. PowerDebug lets you debug standalone applications. You include the remote debug library, add a line of code to start using it on startup, then build the standalone. With the IDE running any runtime errors in the standalone will be caught by the debugger.
2. The standalone builder has an option to let you use a custom handler for errorDialog messages. Showing the error context when a runtime error happens can help localize the source of the problem.
3. The major difference between a standalone application and a stack running in the IDE is the use of the startup handler in the standalone, so that would be the first place I'd look for a problem.
4. Place a try/catch construct around code where you suspect a problem, and display any caught errors in an answer dialog.
1. PowerDebug lets you debug standalone applications. You include the remote debug library, add a line of code to start using it on startup, then build the standalone. With the IDE running any runtime errors in the standalone will be caught by the debugger.
2. The standalone builder has an option to let you use a custom handler for errorDialog messages. Showing the error context when a runtime error happens can help localize the source of the problem.
3. The major difference between a standalone application and a stack running in the IDE is the use of the startup handler in the standalone, so that would be the first place I'd look for a problem.
4. Place a try/catch construct around code where you suspect a problem, and display any caught errors in an answer dialog.
PowerDebug http://powerdebug.ahsoftware.net
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev