Community
Participate
Working Groups
Created attachment 255645 [details] Steps to recreate the problem Customer created a new category in Customize Palette and inserted code into the template. After completing the customize palette he right click on the item & copy. Then right click in a empty place and paste. The paste completes successfully but the data in the template does not copy over. Code in the Template: // ${Field_desc} (${Field_name}) If OldRec.$(Field_name) <> NewRec.${Field_name}; WriteLog(Incom : InVendo : '*CHG' : '${Field_name}'; OldRec.${Field_name} : NewRec.${Field_name}); Endif;
Moving to RSE
moving again to wst since the plugin is org.eclipse.wst.common.snippets
Following up checking to see if anyone has had a chance to take a look at this issue yet?
Hello Alex, I tried to recreate the problem in WTP 3.6 and 3.7, and I couldn't. But I notice that in version, you put 3.4. So I also tested in 3.4, and I could not reproduce. Do you see an exception in the log? Can you reproduce it?
Hi Roberto, Below is the update from RDi development: "I can consistently reproduce the problem with base eclipse 4.4 please reopen the bug on eclipse with the following steps to reproduce open eclipse create new category in snippets view create new item under category with multiline template select copy on item select paste on category select customize on new copy -> has complete multiline template as expected open notepad, enter multiline text, select text, select copy in snippets view, select copy on 1st item again select paste on category select customize on new copy -> only has 1st line of template"
Hi Roberto, Checking to see if you had a chance to revisit this problem.
Hi Roberto, I'm checking on the status of this problem. Thanks...Alex
Alex, I'm finally able to recreate the issue. The key point to recreate it is to create a new item with multiple lines, save it, restart eclipse, and then do the copy/paste. If you first use the Customize option and change something in the resulting dialog and press OK, then I cannot recreate the issue. The problem is that when the snippets are first loaded, the EOL characters are replaced to use the OS characters (in Windows, \r\n). This is done in ModelFactoryForUsers.createContent(Node item). After doing this, the content of the snippet is serialized to XML like this: <?xml version="1.0" encoding="UTF-8"?><snippets> <item category="category_1451959391137" class="" editorclass="" id="category_14519593911371452011612295" label="Logging" smallicon="" snippetProvider="org.eclipse.wst.common.snippets.ui.TextSnippetProvider"> <description><![CDATA[Logging field changes]]></description> <content><![CDATA[ // ${Field_desc} (${Field_name})]]> <![CDATA[ If OldRec.$(Field_name) <> NewRec.${Field_name};]]> <![CDATA[ WriteLog(Incom : InVendo : '*CHG' : '${Field_name}';]]> <![CDATA[ OldRec.${Field_name} : NewRec.${Field_name});]]> <![CDATA[ Endif;]]></content> </item> </snippets> Note that there are several CDATA sections in the content section. When the new snippet is created for the Paste action, only the first CDATA section is used (the first line) If you use the Customize dialog, and do something (like deleting a category or snippet), the EOL character of the snippet is changed to \n (in variableItemEditor.updateItem()), which makes the snippet to be serialized with only one CDATA section with all the contents, and that is when the problem does not occur. So, I know the cause of the problem now, but at this moment I do not know the best way to fix it. I see a few methods messing around with line delimiters in this snippets code :\
Created attachment 259287 [details] Proposed patch v1
Nitin, could you take a look at the attached patch? I tried to make this patch the least invasive possible, so I decided to add code to the Copy action to replace line delimiters before serializing to XML, to prevent the problem. This also works for the Cut action (Cut/paste also removes the lines of the snippet). I tested this in Windows, I have not tested it in Linux
Nitin We are wondering if this has been addressed, since we are not seeing this in 4.6.3
