United Kingdom
Asked — Edited
Resolved Resolved by DJ Sures!

Script Writing Questions

DJ, please do not see this as a criticism, I remain one the biggest fans of your great work!

Now I am doing extensive script writing for the ALTAIR robots, there are a couple of issues that really slow down my EZ_Builder code writing productivity.

The one that really gets me is the EZ-Script Function suggestion box (that I never use) that appears over your code making it hard to see the nearby lines and some times the window seems to lock in position and this takes a few key presses just to get rid of the box. I know this may be useful for some people but for me to say it is annoying is an understatement! Is there a way to turn this off, if not could I please ask that the option is given?

Another thing I noticed is that sometimes you cannot label a code line out (which is helpful when debugging) even with a "#" place in front of the code line it still gets parsed - it usually throws up a syntax error here is an example

"syntax error on line 67,Unknown command # $LIGHT=setbits(0,0,0,0,0,0,$bit7,$bit6)"

If I take the hash symbol away then it works again?

Thanks for anything you can do here.

Tony


ARC Pro

Upgrade to ARC Pro

Stay at the forefront of robot programming innovation with ARC Pro, ensuring your robot is always equipped with the latest advancements.

#1  

Hmmm, I am going to have to agree with Tony on the first part.... The pop up script suggestion box gets in the way and it's difficult to get it to close out (which obscures the line you are trying to type on)....

United Kingdom
#2  

Yep, I find this annoying as well regarding the pop up being in the way, but just thought it was me! :)

PRO
Synthiam
#3  

Too funny - it annoys me as well so last week I added an option to disable it.

As for the comment in front of a code line, I don't get an error. Let me take a further look and see how that could possibly happen for you.

#4  

I have found I can get rid of the pop up boxes with the escape key or by double clicking on the grey bar in the bottom of the box. I have also noticed, the odd time, that a line with a # in front of will be parsed. It usually happens after I have made a lot of changes to a script without saving it periodically.

PRO
United Kingdom
#5  

Thanks DJ! The labeling out of a code line issue does not always happen - it seems to occur when you have a script and then start labeling out to debug the code I am not sure what the link is yet? I just got it (a syntax error) when I labelled (#) out a UARTInit line.

Tony

#6  

I'm still an idiot when it comes to writing scripts but I've spent a fair amount of time writing simple scripts. Not as much though in comparison to some of the coding wizards around here. At first the suggestion box was a godsend. After a while it got annoying. Thanks for adding the option to disable it. This is funny because I think I was one of the people asking for this feature to be added a few years ago. Sorry Tony. ;)

I also have noticed odd annoying behavior with labeling and disabling lines. I noticed that if I place a # at the beginning of a line to disable it and already have a # at the end of the code (but in front of my label) my script would hang there or I'd get the syntax error Tony mentions. Hope this helps and can be fixed. :)

PRO
United Kingdom
#7  

Thanks for the update DJ it is appreciated!

The labeling out of lines is still an issue for me. Some of my scripts are now very complex and to debug them efficiently by stopping certain lines from working is essential to find where a problem is. When I label (#) lines out the moment sometimes this causes a syntax error dialogue and the whole script stops, you cannot even save the script until the syntax error is removed (taking out the hash sign).

Another sign of this problem (as Dave mentioned) is that if the line has a "#" after the code to explain what is happening, then placing a "#" at the start of the line will always cause a syntax error.

Try this example (after initializing the uart))

Open a new script then type "uartwrite(0,0,$byte1,$byte2) # send commands" - then click "syntax check" and you will get an ok.

Now add a "#" in front of the line ("# uartwrite(0,0,$byte1,$byte2) # send commands") and you will now get a syntax error?

I end up having to delete the line (or the comments) to continue, this is a real headache as you have to remember where to put them all back later. To me the ability to temporarily label out code lines is essential to efficient program development and debugging.

I hope it is possible to also sort this issue out.

Tony

#8  

Tony,

As I think you already surmised, the problem is with having two comment tags in the same line. Instead of deleting the comment, how about just entering a carriage return to move the comment to the next line, then when done debugging, you can just backspace on that line to move the comment back up.

Personally, I always just put my comments in the line above the command or section I am trying to comment on so I never saw this problem before trying to duplicate what you were seeing.

Alan

PRO
United Kingdom
#10  

Good point Alan, though it would be good to get this fixed and I have seen this occur when there is only one comment tag on a line.

Tony

#11  

If I may comment on this issue since we're talking about debugging and labeling out code, it would be nice to have a symbol (or symbol pair) to label out groups of lines. For example, while '#' disables a single line, a pair such as '(#' could begin the labeling out of a group of lines and the opposite '#)' would signify the end. Of course any not normally used symbol would work as well. It would also be good if this pair could be used on a line by itself and still be valid. For example:

(# Labeling out all the lines including this one Line 1 Line 2 Line 3 #)

Would be the same as this:

(# Labeling out all the lines including this one Line 1 Line 2 Line 3 #)

Such a thing would allow for easy labeling out or enabling of entire code sections. Being able to have the symbols on separate lines helps in visually identifying the start and end points.

An alternative method would be that when the interpreter running the script finds a '#' symbol on a line by itself, it skips all subsequent lines until it finds another '#' on a line by itself:

Labeling out all the lines including this one Line 1 Line 2 Line 3

Whatever method was used would need to ignore lines regardless of content, including lines that have a '#' symbol already in them.

I realize this sort of thing is easier said than done. My apologies if I have simply repeated a point made in the past, but I could not find such a discussion by searching the old posts.

#12  

@wsb00001

I agree that this is a great idea. I know I use this in c# and in SQL a lot. It would be a nice feature to add into scripting in ARC.

PRO
Synthiam
#13  

Toymaker,

I am able to reproduce the bug when i do this


# $LIGHT=setbits(0,0,0,0,0,0,$bit7,$bit6) # This is a second comment

I am not able to reproduce the bug any other way. You had mentioned that there are other scenarios in which a similar bug had been evident. Can you help me by providing an example code line that is different than the above which triggers this similar style bug in commenting?

PRO
United Kingdom
#14  

DJ, over the last months, the single line hash problem only happened a couple of times and I never logged what the particular lines contained as I sort of accepted the problem. I will now though record the line details if it happens again for you. The bigger problem was the 2 hash per line event that caused problems every time and I am grateful for your prompt fix for this.

Tony