Caused a crash

[Xclio]

Well earlier I was messing around and I caused a crash.  It was a total lockup not a nice unhanded exception or anything like it totally took a crash on me.  I haven't really messed with it since as I was building and tweaking my latest rail tamer that I just realized on winuo but I will play around with it again tomorrow to see if I can reproduce the crash.  I didn't wanna chance it while I was trying to write alot of new code.

[TrailMyx]

Was it during a syntax check?  I think there still might be a place where  it can get into a loop in the main task.  In any event, I hope you can reproduce that one.  It's been a very long time since I've seen it do something like that.

[Xclio]

Alright well I got to my work computer which only has build 189 and I can't do it because the play script functions were removed.  I will see if I can find an older version that I have on this comp that has those functions so I can throw that bug back at ya.

Basically if I remember right as to what happened I was doing some testing with a yesnocancel menu and I had it do a pause.  It worked just fine but when I hit the stop button I got a hard crash.

Also something I noticed when doing some of the run script testing using that older version is that the stop command specificlaly doesn't work and it seems that my yesnocancel description below wasn't working quite right either but more details for you on that if you want as obviously the script run features aren't anywhere near ready for public release yet.

below is a generic of the code I wrote to cause the crash on the older version.  Like I said I will see if I can find that older version so I can be sure I give you the right info on it though.

Code: [Select]

display yesnocancel blah blah blah
if #dispres yes
        display ok you chose yes
if #dispres no
        display ok you chose no
if #dispres cancel
        display ok you chose cancel
pause

[TrailMyx]

Ah, ok, well with the actual running of the code, I can see there are still several possibilities for crash potential.  It's kinda why I took the run feature out in preparation for public release.

My intention is to test the "no run" version to be sure there are no huge crash bugs and release that to the public.  Then I'll bring back our internal version that has the code execution and UI developer so we can play with that internally. 

But I feel a little better now since I was worried that there was one of those "lock up" crashes in the potential public version.

To be frank, I haven't even started officially testing the version that executes code and debated releasing it at all.  So at this point if anything works at all, I'm surprised. 

[TrailMyx]

Once we get back to testing the version that does code execution, there will be a lag in the system variable usage.  My original handler for the "#var" values wasn't very thread-friendly, so what's in the code now is only about 1/4 re-written.  I never finished it since I changed my focus back to bug squashing in the editor itself.  So currently, anything that uses "#dispres", "#result", "#strres", etc, etc ,etc will probably not work.

[Xclio]

Yeah I had figured that it was in a pretty infant stage at this point and that is why I felt the need to make sure you knew that it was code execution based and not the public release version that we are working toward.