VB: Drag & Drop Re-ordering does not move attributes.

[ericmutta]

Environment

• Visual Studio 2015 Community Update 3
• CodeMaid 10.1
• VB,NET

Description

In the CodeMaid Spade window you can drag and drop members up or down to re-organize them physically within a file. This works great but if the methods contain an attribute, the method body moves by the attributes applied to the method are left behind.

Steps to recreate

Try to re-organise the following code using CodeMaid Spade (e.g. by moving BlockWrite() up):

`Public Module ArrayExtensionMethods
<Extension>
Public Function BlockRead(ArgSource As Byte(), ArgOffset As Integer, ArgCount As Integer) As Byte()
Dim bytes = New Byte(ArgCount - 1) {}
Buffer.BlockCopy(ArgSource, ArgOffset, bytes, 0, bytes.Length)
Return bytes
End Function

<Extension>
Public Sub BlockWrite(ArgSource As Byte(), ArgTarget As Byte(), ArgOffset As Integer)
Buffer.BlockCopy(ArgSource, 0, ArgTarget, ArgOffset, ArgSource.Length)
End Sub
End Module`

Current behavior

The method bodies are moved by the applied Extension attribute gets left standing alone which results in a syntax error.

Expected behavior

Move the method including its applied attributes. For extra value, the surrounding blank lines should be preserved after move so if someone uses blank lines to seperate methods, they apply after the move.

[codecadwallader]

Thanks for reporting the issue. This behavior works as expected in C#, so I suspect that the VB API is not reporting the StartPoint member for CodeElement's in the same way that occurs in C#. Another way to test this behavior would be to perform a reorganization operation and see if the same things happens. Under the covers, it's largely the same logic that is used to move elements within a file between Spade's drag and drop and the reorganization logic.

The code that determines the starting point of elements: https://github.com/codecadwallader/codemaid/blob/master/CodeMaid/Model/CodeItems/BaseCodeItemElement.cs#L67

In regards to the surrounding blank lines - it is expected that cleanup will be run after any move/reorganization operations which will re-standardize the blank lines.

[ericmutta]

@codecadwallader many thanks for getting back to me and confirming the bug. I hope it will be fixed in a future release (I would help, but have no experience with Visual Studio plug-in development!).

Regarding the blank lines - when I do run clean-up for a VB file (CodeMaid menu > Clean Active Document), nothing happens...even though in the settings under Cleaning > Insert, I have set it to "insert blank line padding before" methods. Could this be a seperate bug or am I doing it wrong?

[codecadwallader]

That sounds like it would be a separate bug. A few ideas:

1. Open the Output tool window in Visual Studio. CodeMaid installs a pane there and if it is encountering any errors they will be listed there.
2. Try a few different files, to see if it always happens.
3. Check your file exclusions under CodeMaid->Options->Cleaning->File Types. Some files (e.g. Form1.designer.vb) we deliberately do not clean by default since they are generated files.

[ericmutta]

I think this is seperate bug for sure. I have looked at the Output window, no messages there for CodeMaid. My file exclusions are fine (under Include, VB is ticked), and I am not formatting designer code.

Here is some code where I expect blank lines to be added between methods, but nothing happens (it's a single file inside a VB console application project):

Module Module1 Public Sub Main() End Sub Public Sub Foo() End Sub Public Sub Bar() End Sub End Module

Trying the same thing with a C# console project that looks like this, produces the expected results:

namespace ConsoleApplication1 { class Program { static void Main(string[] args) { } void foo() {} void bar() {} } }

Blank lines are added before foo() and bar() and the closing brace is shifted down to the next line.

Is VB officially supported and tested for CodeMaid or is it opportunistic in that it works whenever the VB compiler produces a code model that resembles the C# one and if they differ (as in the case of attributes reported earlier) then the behaviour is undefined?

PS: the code may appear malformed, dunno why this editor doesn't honour it as pasted

[codecadwallader]

I agree it is a separate issue, and I have reproduced it as well. Will you please create a separate issue for tracking?

To format code within GitHub issues, take a look at their Markdown syntax Example:

Module Module1
    Public Sub Main() 
    End Sub 
    Public Sub Foo() 
    End Sub 
    Public Sub Bar() 
    End Sub 
End Module

Great question and description of Visual Basic support. I would classify it as opportunistic. I have never used VB in a regular capacity, nor have any of the other main contributors to my knowledge.. so support has largely been driven by "C# freebies" and specific requests like yours. We would love to have somebody aboard who uses VB regularly and can give it that first class level of support.

[ericmutta]

I will create a seperate issue and will be happy to help with the VB support (been using it for 19 years!).

[codecadwallader]

That would be great! You may find the following link a helpful reference: http://www.codemaid.net/contribute/

[thehutman]

Hi! I've been having this reorganization bug for quite some time now that I got put onto a VB.NET project (I have for years been C# only -- so this bug never bothered me). I think I found the problem ... it's related to what appears to be VB.NET's output of the StartPoint property for CodeElements -- it doesn't appear to include the extension attributes as C# does, so the line for the start is off by one and thus misses the attributes and any comments before it.

I forked a copy of the code to play with. In my testing, I changed uses of the StartPoint property references to instead call the GetStartPoint(vsCMPart.vsCMPartWholeWithAttributes) method in the BaseCodeItemElement.cs class. I'm testing with it now, and it appears to now happily reorganize the VB code blocks. I also did the same change to the EndPoint (calling GetEndPoint(vsCMPart.vsCMPartWholeWithAttributes) ) I'm trying to get a Pull Request together for this once I get tested completely and also see how this impacts my C# code. I'm wondering if this problem is going to be in most uses of CodeElement.StartPoint in the solution?

I'm doing this extension testing in VS2017 currently on a Windows 10 VM.

Here is my test Source:

Before code changes and doing a re-org (messy and broken):

After my code changes (proper reorg and keeps code and comments together):

[ericmutta]

@thehutman I am glad someone got round to doing this fix, I really appreciate it and hope to see it in the next build :-)

PS: @codecadwallader my sincerest apologies, I vanished on you regarding this issue after saying I would help :(

[codecadwallader]

@thehutman Wonderful, thank you for working on this issue. :) The location of your change is pretty central and could have more impacts than desired. A more targeted place to consider that style of change would be in the vicinity of https://github.com/codecadwallader/codemaid/blob/master/CodeMaid/Logic/Reorganizing/CodeReorganizationManager.cs#L165

Performing some regression testing on C# would definitely be helpful. Those GetStartPoint methods are not very consistent even within a language across different member types. Here's the primary file where I use those methods as an example: https://github.com/codecadwallader/codemaid/blob/master/CodeMaid/Helpers/CodeElementHelper.cs

Thanks again for investigating and please let me know if you have any questions I can help answer!

@ericmutta Don't sweat it. :)

[codecadwallader]

This has been addressed by #444 and will be included in the next release (v10.4)