I replaced your improved vbdotnet.uew by an even more improved version in your post above.

I have made additionally following improvements:

1. Ran the macros SortLanguage, TestForDuplicate and TestForInvalid from the ultimate syntax highlighting tools and removed the duplicates and invalids.
2. Removed the line /EnableCFByIndent as EnableCFByIndent should be in the first line of a syntax highlighting wordfile left to File Extensions = on really using it. But code folding should be done in this case according to the Open and Close Fold Strings and not according to the indentation levels of the code. EnableCFByIndent is removed completely from the wordfile for that reason.
3. Replaced the multiplier * (zero or more times) by the multiplier ? (zero or once) after each non-capturing group (?:public[\t ]+|private[\t ]+) because there can be only once public OR private left to function or sub or property but not public private or private public or public public or private private. A little bit syntax checking on searching for strings for the Function List is in general advisable.

Let us know about more wanted improvements.

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:
Note: 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.

Regular expression cannot be used for the definition of open/close fold strings. They can be used only for finding strings for the Function List view and for IntelliTips.

There can be added "{" to the list of open fold strings and "}" to the list of close fold strings to be able to fold the formattingRules list.

I have not forgotten to complete revising the syntax highlighting wordfile for VB.NET using the current Microsoft documentation. I have just not found enough time in the last weeks to do it. But I will for sure complete that work, hopefully in the next weeks.