UDL language highlighting causes issue if open comment string /* is used within quotation marks. "/*"
I am using progress Openedge UDL . In this user defined language the open comment string is:
/*, and the close comment string is:
Now I have a piece of code that actually has the open comment(
/*) included within a string encapsulated within quote characters , like follows:
" **/**** "
The UDL interprets this as the start of a open comment , and the rest of the program , from this point onwards is highlighted in the comment shade , because a close comment is never found .
Can anyone please assist?
You might want to use something other than quotes. My UDL for dBASE allows for square brackets to also be used to delimit strings, and I ended up with the same problem you did with the open
/*symbols, until I enclosed them in the
delimiters. It depends on how your UDL implements various aspects of the language, that determines how it’s going to show up in NPP, so you may need to use a set of delimiters for encasing the string that works. The problem is that some of the UDL uses quotes to encase two word keywords, and such, so I had trouble when using the quotes since for some reason they didn’t delimit or they delimited too much like you just showed. My problem came originally from typing something like
it'sand that apostrophe would start the highlighting and never find another closing apostrophe to stop it. I removed the quotes also, for similar behavior I think, because in dBASE, SQL commands that can be sent via a function, need to be enclosed in single quotes, and then other strings inside would be enclosed by double quotes…etc, so I just removed them from any special highlighting.
The crux of this, however, is that it doesn’t actually affect your code, just how you see it in NPP via your UDL. Try using a different delimiter and see if that doesn’t allow you to enclose that character set without triggering the behavior you see. Here’s a screen shot of what mine does.
If you define the quotes as a delimiter pair, it will only allow a comment in that delimiter pair if you tell it to allow it:
example: comment not allowed inside quote delimiter:
example: comment is allowed inside quote delimiter:
unbalanced version (replicates the problem you described):
Wow Peter, I feel like an idiot. I don’t think I noticed that
Escape:option in there before myself…I was dealing with the nesting to try and avoid those conflicts. Looks like I’m back to the drawing board to relearn what I missed and messed up again. :(
Thanks for the correction and help, now I can work on mine again. Happy Easter for the egg I just found. :)
Actually, relooking at it, our language doesn’t allow for comments inside of quotes/strings and that may be my reason for not allowing it, but I think I should mess with it, some more because our SQL stuff, does need the different aspects to work together…at least I don’t feel like a complete idiot now…but I am working on it. So thanks still…need to relook at it anyway, since I’m playing with the RC, so my normal files will be safe if I screw something up. :)
I don’t think I noticed that Escape: option in there before myself…
I put in the Escape out of habit, and I’m glad you’ve now learned of its existence… but Escape had nothing to do with whether or not the Comment-start inside the string was recognized as a comment or not. The nesting decision is fully determined by the checkboxes in the Nesting section.
Checkmark not checked:
Regarding the Escape:
With no escape defined:
With escape defined as backslash:
our language doesn’t allow for comments inside of quotes/strings
Right. which is why in the Styler for the quote delimiter, you have to make sure that the checkbox for comments is NOT checked, so it doesn’t try to highlight the text inside a quote as a comment, even though it may use those characters.
Thanks. Apparently I was paying attention and did it right since they work, and the nesting was the key for me. Don’t know why I didn’t mention it for the OP, but…it is determined by how the UDL is defined…so. :)