[11.1.125 Pro] - Generated code issues

[11.1.125 Pro] - Generated code issues

Having Always Add Delimiters set to Always add apostrophes `` is definitely not without side-effects. I have a stored procedure that looks like this:

code completion (upon selecting the stored procedure from the list after CALL) will insert the following code into the editor:

	Code:
	CALL `usp_add_table_to_clear`(v_`a_test_case_set_name`, v_`a_schema_name`, v_`a_table_name`)

SA appends the prefix v_ in front of the arguments but only after surrounding it with the delimiters and that results in a syntax error.

I have a few questions:
#1 is that prefix (v_) necessary? Is that hardwired? Can it be disabled or even better, customized?
#2 the formatting of the inserted code is odd. Why is it broken into two lines after the second argument? Checking the code it generates for other procedures (having fewer or more arguments) I guess it tries to keep the code width at 80 characters. Is that also hardwired? None of my formatting styles use that value, they are set to use much longer lines (the shortest is set to 160 characters).

Also, the statement delimiter is not added to the code though there isn't anything that could be added to it so it could be closed with a ; without any problems.

Additional side-effects can be observed in this short video here:

When selecting arguments of a stored procedure to pass to another stored procedure called in the current one, SA adds another two sets of delimiters to the arguments, creating a syntax error. This only happens if they are selected from the popup for the stored procedure and they can be selected from the argument list because they have the same name. When selecting the arguments from the popup for the local variables, they are inserted properly.

For #1 unfortunately I don't know where v_ comes from. I will need to ask for help and get back to you.

I thought I knew the answer to #2, it suppose to wrap text lines after reaching "Line Length for Code Wrapping" parameter value, which is 120 characters by default. However I tried that and it doesn't work as I expected. I suspect it's a defect and the value is hard-coded somewhere in the legacy part of the code, it should be using the configured value.

Any updates on this one?

Based on what I have found in the issues database, the first issue is supposed to be resolved in 11.3.278, if I read it correctly. I'm sorry the description of what was changed is a bit too cryptic for me, there is a comment for what was changed internally in the code to update the behavior. Are you still seeing it in 11.5?

For she second issue/question about code wrapping, there is more clarity now. It's certainly unrelated to text wrapping rules in the editor, the right margin, which is applicable only when the text wrapping option is enabled in the editor. The easiest method to find out if it's enabled or not is to mouse over the dotted line and read what the hint says about the current state. What seems to happen here, the code snippets processor somehow calculates line wrapping based on the text of the code snippet before the macro variables get expanded and replaced with the actual values. That's why we couldn't figure out earlier fro mthe results where the text gets wrapped. I don't see any related changes in 11.5 to change that behavior, it's still an open ticket.

I'm sorry, I should have been more precise. I happily report that issue #1 is toast. My question was related to issue #2, the wrapping anomaly.