RE: Comment on editing front scripts
Hi gals and guys, Speaking of frontscripts, wouldn't it be cool if you could query variables while debugging via the message box? like put array[x,y] and you get the answer you can't see in the debugger without adding debuging context variables... Just a thought... Worth a bugzilla suggestive entry? cheers Xavier -- MonsieurX.com - Be wild! ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Comment on editing front scripts
> This reminds me of an annoyance: as noted in the docs somewhere, > sometimes script errors in frontscripts or backscripts are not reported > properly as such, instead pointing to the non-inserted script that > called it. > > Why is that, and how hard would it be to fix? > > Mark W? Me? Where? I think you must be thinking of someone else... ;o) Having taken a quick look at this, as far as I can see the engine is reporting this correctly - i.e. if you put a try/catch handler around some offending lines, then the resulting error string is what you would expect. Therefore, I'd guess any problem in this area would lie with the parsing of the reported error string. (I'm not ruling out there couldn't be a glitch or two in the engine's report, but my brief tests seem to suggest that it is most likely IDE related). Indeed, it seems that this problem appears only when Script Debug Mode is off - therefore this suggests it is revErrorDisplay's interpretation of the error string that is at fault. (The reason it's okay in Script Debug Mode is because the engine sends a 'traceError' message instead, and this includes the context as a parameter). Anyway, shouldn't be too hard to fix... Warmest Regards, Mark. - Mark Waddingham ~ [EMAIL PROTECTED] ~ http://www.runrev.com Runtime Revolution ~ User-Centric Development Tools ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
RE: Comment on editing front scripts
we do have to look at the scope we need. Debugging, variables, script editor, error display (and relevance to error or compilation problems), etc... And there is the hierarchy of problems when a function calls one which has a mistake as you pointed out before (an old problem!)... Part of this problem is the lack of threading in the engine imoho. Different threads that dont interfere or block the others would be quite helpful! It would require a few "trys" and catches more but it would solidify things further. HyperCard has a separate code running to do debugging and script editing and surely that helped a lot more than having an all in one script environment that does the IDE operations and debugging at the same time. As I've said before the IDE interferes a lot, and the issue comes back again and again in one form or the other... If it helps, here's some rules and logic operation schemes from XOS: For one, I keep track of who locks and unlocks what and in what order (FIFO style). If one operations blocks the other, there's either a debug breakpoint with data report (customizable report of who did what when with what data) or there is an overrule of a lock (uninplemented yet). One intersting adventure I had is this: You know the errordisplay is GM broken each time an error occurs (where's that revOnline update i wonder). But the RevVariableWatcher uses a resizestack handler. I tried to improve the RVW because of it's totally annoying resizing inneficient design and adding Rev's GM features was total chaos in the engine! I had to restore an virgin copy of the RVW to continue! ;) So, separation of tasks via threading (for non-data-returning handlers) would be cool and a solution to Rev's error-handling erratic display... As soon as my mom leaves, I'll start working on the GM for XOS now that the XOS Language engine is near finished. It's hard to develop an IDE, that's for sure! But all together it's that much easier! Cheers Xavier > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Richard Gaskin > Sent: Saturday, February 12, 2005 07:36 > To: How to use Revolution > Subject: Re: Comment on editing front scripts > > MisterX wrote: > > >>>>On Feb 11, 2005, at 10:52 AM, Richard Gaskin wrote: > >>>> > >>>>> This reminds me of an annoyance: as noted in the docs > somewhere, >>>>> sometimes script errors in frontscripts or > backscripts are not >>>>> reported properly as such, instead > pointing to the non-inserted >>>>> script that called it. > >>>>> > >>>>> Why is that, and how hard would it be to fix? > >>>> > >>>> Ahhh...Now if we could have reliable script errors in > >>>> every instance, life would be much easier. > >>> > >>> It may not be much of a bullet-point, but for myself I'd > >>> prefer to see an overhaul of error handling above any > >>> other feature currently in queue. > >> > >> I have 5 votes waiting to add to that if you'll point me > >> to the request. > > > > You can add your votes to bugzillas 2347, 2344, 2320, > 2351, 1638, > etc... > > Those cosmetic issues would be helpful, but I was thinking > less about the UI than what's going on under the hood with the engine. > > I don't mind taking an evening to make my own error dialog (I > have to anyway to get something suitable for including with > my app), and if the error handling was revamped it would only > be a few lines anyway. > > But getting to a simple, robust, and thorough reporting > mechanism may be a bit of engine work. > > I've posted a message to the improve-rev list to see if we > can get a spec together to propose > > -- > Richard Gaskin > Fourth World Media Corporation > ___ > [EMAIL PROTECTED] http://www.FourthWorld.com > > ___ > use-revolution mailing list > use-revolution@lists.runrev.com > http://lists.runrev.com/mailman/listinfo/use-revolution > ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Comment on editing front scripts
MisterX wrote: On Feb 11, 2005, at 10:52 AM, Richard Gaskin wrote: > This reminds me of an annoyance: as noted in the docs somewhere, > sometimes script errors in frontscripts or backscripts are not > reported properly as such, instead pointing to the non-inserted > script that called it. > > Why is that, and how hard would it be to fix? Ahhh...Now if we could have reliable script errors in every instance, life would be much easier. >>> >>> It may not be much of a bullet-point, but for myself I'd >>> prefer to see an overhaul of error handling above any >>> other feature currently in queue. >> >> I have 5 votes waiting to add to that if you'll point me >> to the request. > > You can add your votes to bugzillas 2347, 2344, 2320, 2351, 1638, > etc... Those cosmetic issues would be helpful, but I was thinking less about the UI than what's going on under the hood with the engine. I don't mind taking an evening to make my own error dialog (I have to anyway to get something suitable for including with my app), and if the error handling was revamped it would only be a few lines anyway. But getting to a simple, robust, and thorough reporting mechanism may be a bit of engine work. I've posted a message to the improve-rev list to see if we can get a spec together to propose -- Richard Gaskin Fourth World Media Corporation ___ [EMAIL PROTECTED] http://www.FourthWorld.com ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
RE: Comment on editing front scripts
Mark, You can add your votes to bugzillas 2347, 2344, 2320, 2351, 1638, etc... I've entered quite a few bugzillas concerning debugging, script editor and associated stacks... There was a big improvement in 2.5 but there still lots of issues including ugly visuals in the script editor menu bar! A little searching in bugzilla will give you a list of voting targets... cheers Xavier > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Mark Talluto > Sent: Friday, February 11, 2005 20:33 > To: How to use Revolution > Subject: Re: Comment on editing front scripts > > > On Feb 11, 2005, at 11:25 AM, Richard Gaskin wrote: > > > Mark Talluto wrote: > >> On Feb 11, 2005, at 10:52 AM, Richard Gaskin wrote: > >>> This reminds me of an annoyance: as noted in the docs somewhere, > >>> sometimes script errors in frontscripts or backscripts are not > >>> reported properly as such, instead pointing to the non-inserted > >>> script that called it. > >>> > >>> Why is that, and how hard would it be to fix? > >> > >> Ahhh...Now if we could have reliable script errors in > every instance, > >> life would be much easier. I noticed this problem as > well. I did a > >> dance of beeps, put [insert variable here], exit [insert handler > >> here], and wait 2 seconds to figure out where true problems arose. > > > > It may not be much of a bulet-point, but for myself I'd > prefer to see > > an overhaul of error handling above any other feature currently in > > queue. > > I have 5 votes waiting to add to that if you'll point me to > the request. > > > Mark Talluto > -- > CANELA Software > http://www.canelasoftware.com > > ___ > use-revolution mailing list > use-revolution@lists.runrev.com > http://lists.runrev.com/mailman/listinfo/use-revolution > ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Comment on editing front scripts
>Debugging front scripts that contain events like (mouseMove, mouseUp, >mouseDown...), is impossible in Rev. Rev's script editor changes size >erratically and buttons on the editor move to unknown places. So I >switched to my trusty copy of MC to work on them. Dawg gone of MC did >not give it the best try to work on them. For the most part, editing >was ok. Then I realized that variables are still updating live as your >mouse moves across your app to get to the script editor. Thus things >start falling apart. I also have had weird results with these type of front scripts. The solution that worked well for me was to put a line like this into all of the front scripts. if the tool is not "browse tool" then pass mousemove --or whatever other handler That way, when editing scripts all I had to do was switch to the select tool and all of the frontscripts would be disabled, and editing scripts worked ok again. Best of all, this line doesn't need to be removed after you're done debugging and ready to compile. -Ben ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Comment on editing front scripts
On Feb 11, 2005, at 11:25 AM, Richard Gaskin wrote: Mark Talluto wrote: On Feb 11, 2005, at 10:52 AM, Richard Gaskin wrote: This reminds me of an annoyance: as noted in the docs somewhere, sometimes script errors in frontscripts or backscripts are not reported properly as such, instead pointing to the non-inserted script that called it. Why is that, and how hard would it be to fix? Ahhh...Now if we could have reliable script errors in every instance, life would be much easier. I noticed this problem as well. I did a dance of beeps, put [insert variable here], exit [insert handler here], and wait 2 seconds to figure out where true problems arose. It may not be much of a bulet-point, but for myself I'd prefer to see an overhaul of error handling above any other feature currently in queue. I have 5 votes waiting to add to that if you'll point me to the request. Mark Talluto -- CANELA Software http://www.canelasoftware.com ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Comment on editing front scripts
Mark Talluto wrote: On Feb 11, 2005, at 10:52 AM, Richard Gaskin wrote: This reminds me of an annoyance: as noted in the docs somewhere, sometimes script errors in frontscripts or backscripts are not reported properly as such, instead pointing to the non-inserted script that called it. Why is that, and how hard would it be to fix? Ahhh...Now if we could have reliable script errors in every instance, life would be much easier. I noticed this problem as well. I did a dance of beeps, put [insert variable here], exit [insert handler here], and wait 2 seconds to figure out where true problems arose. It may not be much of a bulet-point, but for myself I'd prefer to see an overhaul of error handling above any other feature currently in queue. -- Richard Gaskin Fourth World Media Corporation ___ [EMAIL PROTECTED] http://www.FourthWorld.com ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Comment on editing front scripts
On Feb 11, 2005, at 10:52 AM, Richard Gaskin wrote: This reminds me of an annoyance: as noted in the docs somewhere, sometimes script errors in frontscripts or backscripts are not reported properly as such, instead pointing to the non-inserted script that called it. Why is that, and how hard would it be to fix? Ahhh...Now if we could have reliable script errors in every instance, life would be much easier. I noticed this problem as well. I did a dance of beeps, put [insert variable here], exit [insert handler here], and wait 2 seconds to figure out where true problems arose. Best regards, Mark Talluto CANELA Software -- http://www.canelasoftware.com ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
RE: Comment on editing front scripts
it's cool but it's like resorting to mallocs ;)) yuk! Xav > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Mark Talluto > Sent: Friday, February 11, 2005 19:44 > To: How to use Revolution > Subject: Re: Comment on editing front scripts > > > On Feb 11, 2005, at 9:53 AM, MisterX wrote: > > > There's also some scripts or calls you dont want to have in the > > frontscripts! Rather reserved for the back scripts or stacksinuse... > > > This is true. I could probably move half of my code to the > back scripts. > > > Best regards, > Mark Talluto > CANELA Software > -- > > http://www.canelasoftware.com > > ___ > use-revolution mailing list > use-revolution@lists.runrev.com > http://lists.runrev.com/mailman/listinfo/use-revolution > ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Comment on editing front scripts
Mark Talluto wrote: On Feb 11, 2005, at 9:53 AM, MisterX wrote: There's also some scripts or calls you dont want to have in the frontscripts! Rather reserved for the back scripts or stacksinuse... This is true. I could probably move half of my code to the back scripts. This reminds me of an annoyance: as noted in the docs somewhere, sometimes script errors in frontscripts or backscripts are not reported properly as such, instead pointing to the non-inserted script that called it. Why is that, and how hard would it be to fix? Mark W? -- Richard Gaskin Fourth World Media Corporation ___ [EMAIL PROTECTED] http://www.FourthWorld.com ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Comment on editing front scripts
On Feb 11, 2005, at 9:53 AM, MisterX wrote: There's also some scripts or calls you dont want to have in the frontscripts! Rather reserved for the back scripts or stacksinuse... This is true. I could probably move half of my code to the back scripts. Best regards, Mark Talluto CANELA Software -- http://www.canelasoftware.com ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
RE: Comment on editing front scripts
> Then it dawned on me to remove the front script just before > the breakpoint line. This simple solution took me a few > hours to realize. > Thought others might benefit from my pain. Good going! This might have helped greatly prevent some nitrous explosions while I developped the WinN20 and PropsN2O plugins last year! A smooth trick to avoid debugger errors or intruding the debugger while keeping track of execution values is to just "put" whatever in the message box like the variables' name and values that you want, you can also put them into a global array or use a condition to ask to change a value (if the shiftkey is down...). I made a debugarray global and a debug display handler too so it doesn't have the message box interfering! Last week I was working on injecting Nitrous into the RevVariableWatcher stack and of course it all went berzerk. GM included (bogzillaed months ago). Now I know how to get back on track ;) Thanks! There's also some scripts or calls you dont want to have in the frontscripts! Rather reserved for the back scripts or stacksinuse... Customize the gui at your sweetest taste! Its the Hyper Spirit! Sweet and ez! Cheers Xavier -- http://MonsieurX.com Boost your Rev-RAD with X's Nitrous plugins ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
Comment on editing front scripts
Debugging front scripts that contain events like (mouseMove, mouseUp, mouseDown...), is impossible in Rev. Rev's script editor changes size erratically and buttons on the editor move to unknown places. So I switched to my trusty copy of MC to work on them. Dawg gone of MC did not give it the best try to work on them. For the most part, editing was ok. Then I realized that variables are still updating live as your mouse moves across your app to get to the script editor. Thus things start falling apart. Then it dawned on me to remove the front script just before the breakpoint line. This simple solution took me a few hours to realize. Thought others might benefit from my pain. Best regards, Mark Talluto CANELA Software -- http://www.canelasoftware.com ___ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
