Thank you for the example
VB.NET source code file. That is a big help on working on the wordfile improvements.
The use of
EnableCFByIndent in first line of the syntax highlighting wordfile left to
File Extensions = (instead of a separate line with
/EnableCFByIndent also enabling code folding by indent) may produce a code folding which looks fine for a well indented
VB.NET source code file as your example file. But it is nevertheless in my opinion not the right approach.
VB.NET is a programming language of which syntax does not depend on indents. There should not be used code folding by indent for that reason as not all
VB.NET source code files will be as well indented as yours.
The use of
EnableCFByIndent in the first line of the syntax highlighting wordfile turns off the use of the open/close fold strings in the wordfile.
Code folding by indentations is also not really working correct for
VB.NET source code files even on all lines being well indented. It can be seen on your example file with checked
Show last line of fold in syntax highlighted files at
Advanced - Settings or Configuration - Editor display - Code folding that the code folding for
Private Sub btnProcess_Click at line 18 ends with
End If at line 32 instead of
End Sub at line 33. That is
not a bug of the code folding by indent feature of UltraEdit/UEStudio. This interpretation of end of block according to indent is absolutely right for programming/scripting languages like
Python of which syntax depends on indentations for code block building.
Your example file is really good for testing wordfile improvements for
VB.NET. I started for that reason not only improving it for automatic indent/unindent and a good working code folding, but in completely rewriting it with the information offered by Microsoft on the page
Visual Basic Language Reference and the linked sub-pages.
There are a lot of "words" missing in the wordfile as I could find out already. I added already more keywords, more data types, two more color groups for enumerations and their field values (being currently present partly in the constants color group) and for special characters like brackets, dot and comma as the number of color groups is since many years not limited anymore to eight but to 20 color groups.
I have not yet finished my work on the wordfile for
VB.NET as I have to study lots of information provided by Microsoft on their documentation pages. It is a bit tricky to categorize all the words correct as some words of
VB.NET exist in more than one context. That requires making a decision to which color group adding a word which is used on more than one context.
However, I want to let you know that I am working on a much better syntax highlighting wordfile for
VB.NET. Here are the top lines of the wordfile currently used by me:
Code: Select all
/L20"VB.NET" VB_LANG Nocase Line Comment = ' File Extensions = ASP BAS CLS FRM INC VB VBA VBS
/Delimiters = ! " %&'()*+,-./:;<=>?@[\]^{|}~
/Regexp Type = Perl
/TGBegin "Functions"
/TGFindStr = "^[\t ]*(?:(?:Public|Private Protected|Private|Protected Friend|Protected|Friend)[\t ]+)?(?:(?:Overloads|Overrides|Shadows|Shared|Static)[\t ]+)?function[\t ]+([a-z][0-9a-z_]*)[\t ]*\("
/TGBegin "Parameters"
/TGFindStr = "\s*([^,]+)"
/TGFindBStart = "\("
/TGFindBEnd = "\)"
/TGEnd
/TGEnd
/TGBegin "Subs"
/TGFindStr = "^[\t ]*(?:(?:Public|Private Protected|Private|Protected Friend|Protected|Friend)[\t ]+)?(?:(?:Overloads|Overrides|Shadows|Shared|Static)[\t ]+)?sub[\t ]+([a-z][0-9a-z_]*)[\t ]*\("
/TGBegin "Parameters"
/TGFindStr = "\s*([^,]+)"
/TGFindBStart = "\("
/TGFindBEnd = "\)"
/TGEnd
/TGEnd
/TGBegin "Properties"
/TGFindStr = "^[[\t ],]*(?:(?:Public|Private Protected|Private|Protected Friend|Protected|Friend)[\t ]+)(?:(?:Overloads|Overrides|Shadows|Shared|Static)[\t ]+)?property[\t ]+((?:let|get)[\t ]+[a-z][0-9a-z_]*)[\t ]*\("
/TGBegin "Parameters"
/TGFindStr = "\s*([^,]+)"
/TGFindBStart = "\("
/TGFindBEnd = "\)"
/TGEnd
/TGEnd
/Open Brace Strings = "{" "(" "["
/Close Brace Strings = "}" ")" "]"
/Indent Strings = "Case" "Class" "Do " "For " "Else" "ElseIf" "Function " "Sub " "Then" "Try" "Catch" "Finally" "With "
/Unindent Strings = "Case" "End Class" "Loop" "Next" "Else" "End If" "End Function" "End Sub" "End Try" "Finally" "End With" "Wend"
/Open Fold Strings = "Class" "Do" "For" "Function" "If" "ElseIf" "Else" "Select Case" "Sub" "Try" "With"
/Close Fold Strings = "End Class" "Loop" "Next" "End Function" "End If" "ElseIf" "Else" "End Select" "End Sub" "End Try" "End With" "Wend"
/Ignore Fold Strings = "Case Else" "Dim" "Exit Do" "Exit Function" "Exit Sub" "Continue For" "Exit For" "Declare Function" "On Error Resume Next"
The character in the second line between
" and
% is a horizontal tab character.
I am quite sure that I will make more changes on these lines in near future, but I wanted to post here nevertheless what I have currently in use while updating the words in the color groups according to the information found in the Microsoft documentation for
Visual Basic.
"Case" is
not in the list of open/close fold strings for a specific reason which I will explain later on having finished the wordfile recreation for
VB.NET.
I will later also explain why
"Then" instead of
"If" is in the list of indent strings while the list of open fold strings contains
"If" and the ignore fold strings list
"Dim" because of line 62 in your example file. I may change
"If" to
"If " with a space in open fold strings and remove
"Dim" from the ignore fold strings which would also work for your example file with line 62. An open fold string like
"If " with the word delimiter space is usually something I try to avoid as it could be problematic if somebody uses
If followed by a horizontal tab character. I do not think that many VB programmers really use a horizontal tab character after the keyword
If and those really doing that could simply add
"If " with a horizontal tab character to the list of open fold strings, but I nevertheless try to avoid an open fold string definition containing leading or trailing spaces. However, there are use cases where an open/close fold string with a trailing space is nevertheless the best solution.
I am currently also not sure if
"Catch" and
"Finally" should be added to the open and the close fold strings lists. That is more or less a matter of personal code folding requirements. Should a
Try block always be folded up to
End Try or should the code folding be suggested/done from
Try to
Catch,
Catch to
Finally, and
Finally to
End Try?
Having
"Class" in the list of open fold strings and
"End Class" in the list of close fold strings could be also counterproductive in case of a
VB.NET source code files contain rarely multiple classes and the command
Collapse All is often used which in this case is collapsing more or less the entire file with a single class and the user must click on the
+ symbol of the line beginning the class block to expand the single class block and get a better collapsed source code file after the execution of the command
Collapse All. That is the same problem I have with C++ code folding. Most of my C++ header files contain just the function declarations of one class. But there are some C++ header files containing the declarations of a base class and of several derived classes whereby each derived class has just a small set of overloading or extending functions in comparison to the base class.
I will add such information about advantages and disadvantages of possible variations of open/close fold strings also to my post with the rewritten syntax highlighting wordfile to give
VB.NET programmers information about how to customize the wordfile further to meet the own syntax highlighting, code folding, automatic indent/unindent, auto-completion, … expectations or requirements. It is great that the syntax highlighting feature of UltraEdit/UEStudio is easily customizable by programmers by changing just a text file. I make use of that since many years with a set of more than 30 highly customized syntax highlighting wordfiles.
