Words Other Than Declarations

[ls-2037]

Hi,

I have been using this recently with a large Access project and it's been working great. I wanted to start a discussion here about handling words other than declarations. The VBE will also adjust the case of GoTo labels and object properties (Form.top vs Form.Top), for example. It seems to adjust the case of any word that's not in a comment or string.

Prior to using this addin I wrote a tool that read manually written case definitions from a string and wrote them into a block that was never compiled, as shown below.

#If False Then
    Dim X
    Dim Y
    Dim Z
#End If

This allowed me to also deal with predefined words that were not legal variable names in VBA (but could be affected by the case changing as property or method names of objects in libraries - such as To or Next), and the RegEx in this addin picks them up fine. However, it would probably make more sense to broaden the RegEx to gather these additional words automatically the same way it does declared variables.

Are you accepting pull requests on this project? If so, do you have any preference on how to handle this? I'll probably implement something for my own use, and I'd like to do it in a way that it can make it back upstream.

[josef-poetzl]

Thanks for fixes!

I wanted to start a discussion here about handling words other than declarations.

For the first test, I only use the declarations, as this produces relatively few comparison words.

Just a thought: should we include an option for the "depth of recognition"?
Then you could choose between "fast" and "just declarations," up to "everything," which is a bit slower. But maybe "everything" is so fast that you won't notice any difference from "just declarations."

[ls-2037]

I tested using RegEx for all words, and it did make it extremely slow, unfortunately. I didn't do in-depth profiling, but I'm almost sure it was the RegEx because it went from taking 30 seconds for ~12k words to 5 minutes for ~18k words. Either I wrote a very inefficient RegEx (totally possible, even likely), or it would be better to switch to a simpler way of parsing the strings if we're going to have many more matches (the unique words were 18k, but the number of matches was obviously much more). It's also possible that the huge number of new duplicated words wasn't playing nice with the logic for adding them to the list.

Fortunately, for all words, it's a fairly simple thing to parse, since it's just all the legal characters for VBA variable names (including the non-breaking space, sadly) delimited by any other character.

I'll give it another shot probably some time soon, and if I produce anything usable, I'll bring it here.

[hrschupp]

I thought about a completely different approach to the whole parsing when I saw what PrepareCode does. Maybe it would be more efficient and allow a deeper recognition when "nearly everything" is added to the dictionary. To accomplish this, PrepareCode would remove anything from the code that is a reserved word (on its own, i.e. not preceded or followed by comma or exclamation mark) and all built-in type names, then also anything starting with a digit and all operators (+, -, /, ...), punctuation, brackets and so on. Everything left should be an identifier of some kind and added to the dictionary.

Please be aware that FixLetterCase must be adapted when not only just declarations and labels have to be corrected. You can use nearly anything (including reserved words!) as property names, so fixing should go along the lines of

Private Type ACLibDeclDictDummy
    <Word> As Variant
End Type

instead of
Private <Word>

[josef-poetzl]

Note:
I write the declaration variants that I can think of in this test code module: DeclarationDictTestCodemodule.cls
(Line labels are now added.)

[josef-poetzl]

Experiment: Read TypeLib declarations from the references.
see: https://github.com/AccessCodeLib/ACLibDeclarationDictionaryCore/tree/dev-read-typelib

I use a .net com-dll, because I was not able to use the API LoadTypeLibEx from oleaut32.dll directly in VBA with reasonable effort.

Follow-up thought:
If a .net-dll is now in use, you could perhaps also use it to search the current VbProject.
Or is it better to leave it in the Access add-in so that it is easier to customize?

[josef-poetzl]

After a few tests, I'm not sure whether loading all declarations from the references makes sense, as this restricts your own notation very much if the TypeLib declarations concerned are not even in use.

The approach of @hrschupp to additionally read out the members creates a much smaller list and is in my opinion even more effective.

[hrschupp]

There were still a lot of fixes and enhancements to that approach that I didn't have the opportunity to push to GitHub yet.
The performance penalty for this extended parsing isn't even especially high. In a bigger project it was 18 vs. 16 seconds.
NB: The alternative idea to read all the type libraries didn't even occur to me.