MS Access & Latest Alpha hotfix still not working

[BobTB]

I tired the latest alpha release with Access VBA:

1. It is very slow to open VBA editor, takes 5-10 seconds
2. It is parsing, but it does never finish, or it does, with "resolver error" or "parsing errors" without any way to see the errors - clicking on the button does nothing
3. On simple projects - a few modules with perhaps 100 lines total - it does finish, but code explorer is completely empty, clicking anything like rename etc, crashes Access
4. It slows down VBA editor so much, that it is impossible to use (100% single core use)

[retailcoder]

Thanks for the feedback!

1. The lag is Rubberduck starting up - at this point the entire application's dependency graph gets resolved at once, at startup... there's quite a number of components involved, and Ninject isn't the fastest dependency injection framework out there (it was chosen for its neat and powerful API, ease of use, and refactoring-friendly configuration), but we definitely need to look into doing things more lazily, i.e. deferring initialization to the first use... and then I guess we'll start having people asking why the source control panel takes so long to open the first time it's accessed haha! We need to strike a balance here.
2. Parsing errors should be behind us at this point - if there's valid code that Rubberduck can't parse, we need to see it and we'll make sure we patch our parser ASAP. Clicking the "Error" status label should bring up a search results toolwindow showing what the parser error(s) is/are - if nothing comes up then it's possible the "Error" status was caused by an exception other than SyntaxErrorException, in which case "Error" state gets reported but there's no parsing error per se... we need to improve this.
3. hmm.. Code Explorer is (well, should be) disabled for now, as it's not fully implemented yet; it's essentially commented-out. Does renaming work from the code pane context menu?
4. Interesting. Is the slow-down continuous, or only while parsing? We're running parser tasks on background threads, to leave the VBE browsable while it's working in the background... but a single-core machine can't really run multiple threads, so it's basically like in 1.x, you have to wait for it to complete before you're able to do anything... right? Got more details about your particular hardware setup / environment? Maybe we need to up the "minimum requirements" a bit.. in any case, there's certainly room for improvement - the work being done is very CPU-intensive indeed.

[BobTB]

1. Ok, as long as it is expected do work like this
2. Parsing erros: Somehow I managed it to make the parser errors show, after I deleted a lot of modules form the code I have. I know this is some ugly and legacy code, but I am looking forward to refactor it by using Rubberduck to help.

Here are the problematic parts – which compile normally in VBA. First two look like a parser problem with underscore _ . For the third, I don’t know.

ERROR: WebRequest Module L519C1 extraneous input 'End Property' expecting {':', ELSE, ELSEIF, END_IF, NEWLINE, REMCOMMENT, COMMENT, ''', WS, LINE_CONTINUATION}

CODE Example 1: (The place of the parse error is marked with * * ) - this is the location double clicking on the error in the parse error window puts the cursor to

'' ' @internal ' @property Id ' @type String '' Public Property Get ID() As String If web_pId = "" Then: web_pId = WebHelpers.CreateNonce ID = web_pId End Property

ERROR: WebHelpers Module L593C9 extraneous input 'Next' expecting {':', ELSE, ELSEIF, END_IF, NEWLINE, REMCOMMENT, COMMENT, ''', WS, LINE_CONTINUATION}

CODE Example 2:

'' ' Convert Dictionary/Collection to Url-Encoded string. ' ' @method ConvertToUrlEncoded ' @param {Dictionary|Collection|Variant} Obj Value to convert to Url-Encoded string ' @return {String} UrlEncoded string (e.g. a=123&b=456&...) '' Public Function ConvertToUrlEncoded(Obj As Variant) As String Dim web_Encoded As String

If TypeOf Obj Is Collection Then
    **Dim web_KeyValue As Dictionary **  

    For Each web_KeyValue In Obj
        If VBA.Len(web_Encoded) > 0 Then: web_Encoded = web_Encoded & "&"
        web_Encoded = web_Encoded & web_GetUrlEncodedKeyValue(web_KeyValue("Key"), web_KeyValue("Value"))
    Next web_KeyValue
Else
    Dim web_Key As Variant

    For Each web_Key In Obj.Keys()
        If Len(web_Encoded) > 0 Then: web_Encoded = web_Encoded & "&"
        web_Encoded = web_Encoded & web_GetUrlEncodedKeyValue(web_Key, Obj(web_Key))
    Next web_Key
End If

ConvertToUrlEncoded = web_Encoded

End Function

CODE Example 3:

ERROR: Global Code Module L2921C25 extraneous input '(' expecting {, ':', '!', '.', '&', ACCESS, AD...........

Public Function VsebinaF(FileSpec As Variant, Optional ReturnErrors As Boolean = False, Optional ByRef ErrCode As Long) As Variant

Dim lngFN As Long

On Error GoTo Err_FileContents
If IsNull(FileSpec) Then
    VsebinaF = Null
Else
    lngFN = FreeFile()
    Open FileSpec For Input As #lngFN
   ** VsebinaF = Input(LOF(lngFN), #lngFN)**
End If
ErrCode = 0
GoTo Exit_FileContents

Err_FileContents: ErrCode = Err.Number If ReturnErrors Then VsebinaF = CVErr(Err.Number) Else VsebinaF = Null End If Err.Clear Exit_FileContents: Close #lngFN End Function

1. Ok :) I did not read the readme, that it is disabled
2. What I meant is that is uses the whole CPU on a multi CPU machine, with occassional msAccess is not responding etc..

[retailcoder]

@autoboosh could ' @Something be interfering with the annotations grammar rules?

No, wait. I suspect a regression with the instruction separator, possibly affecting line labels. Looks more likely.

[ghost]

Line 246 in VBAParser.g4 is the culprit it seems:

IF whiteSpace ifConditionStmt whiteSpace THEN whiteSpace blockStmt (whiteSpace ELSE whiteSpace blockStmt)? # inlineIfThenElse

After THEN could be a COLON, the grammar does not allow that to happen.

[retailcoder]

Also looks like FreeFile() (or any function call for that matter) made with empty parens could be causing a parser error.

[ghost]

In Example 3. What's up with this line:

** VsebinaF = Input(LOF(lngFN), #lngFN)**

That's not part of any VBA dialect I know of and doesn't compile in Excel either.

[ghost]

Same problem in Example 2. What is the tool you are using to write VBA in called?

[BobTB]

Ok, I had to reinstall the preview to try this again.

What I am using is MS Access.

Here is the code again, this does compile normally, but does not parse. But now, after reinstalling I can not get he parse Error window to open any more. It did not open before either, I had to try a few times and delete some code etc.. for it to open at all.

Here are both examples in pastebin:

http://pastebin.com/CZzePACw

http://pastebin.com/nkxW9gCq

[BobTB]

I am aslo using MZ Tools, which does a similar thing with code parsing, but it does it really fast. Source code review results are immediate. Probably different approach, but here is an example screenshot it does, just for reference.

[BobTB]

One more thing :) If parse error window would open up, I have a lot more examples of code that does not parse, but compiles normally in Access VBA.

[retailcoder]

Yeah I need to ask Mr.Quintero about his approach to "unused variables" and "used in comments" next time he shows up in our chatroom - I suspect he's only relying on the VBIDE API and parsing the raw text without lexing the input (or with a very basic lexer), which is fast indeed, but then you don't have a symbol table or an abstract syntax tree (AST)... I haven't tried to break it, but I'd think the MZ-Tools approach would be more prone to false positives - there's much more to identifier reference resolution than simply matching strings.. at least if you want to handle all possible edge cases.

Also, Rubberduck isn't only looking at whether a variable is "used" - it knows if it's an object variable assigned without the Set keyword, or if it's an implicit Variant, it differentiates a variable that is used but never assigned, one that is assigned but never referred to. Rubberduck's inspections (aka "code review") do much more than check for unused variables, parameters and procedures: we know when a module-level variable is only used in one smaller scope, and we give you a quick-fix/refactoring to move that declaration closer to its usage; we know when a parameter is passed ByRef implicitly, and then never assigned a new value - so we suggest passing it ByVal. Or when it's passed ByVal, and then when it is assigned a new value - so we suggest introducing a local variable, and warn you that if the caller is supposed to know about the new value, you possibly have a bug there; we tell you when a function's return value is an implicit Variant, and when a function's return value is never used such that the function is used as a procedure and could be written as a Sub instead; we warn you about obsolete keywords and code constructs like Let assignments, usages of the Global modifier, Call function, Rem comments and when you're using cryptic type hints instead of specifying an explicit type - and we provide quick-fixes for all of those. We also warn you when a local object variable is self-assigned with = New, and explain how it changes the way VBA handles that object's lifetime and can result in unexpected behavior.. we suggest renaming poorly named variables (those with 1-2 characters, no vowels, or ends with a number).. and then give you a quick-fix that renames the identifier and ripples to all references of that identifier across the project. And we tell you that a property that only exposes a setter propably should also expose a getter - we have 36 code inspections implemented at this point, most with one or more quick-fixes. And we have an internal representation of the code that allows us to implement pretty much any inspection we could think of.

We never expected that analytical power to come without a price :wink:

[BobTB]

Oh yes, I know this does wonders :) and some wonders take some CPU time!

[ghost]

Looks like there's another problem with if-statements. Parts of it are sometimes classified as procedure calls which might lead the identifier resolver to resolve it wrong. Just as a heads up.

[Hosch250]

We released the beta a couple days ago, if you want to try it out. On the other hand, I'm going to release again on Monday or Tuesday with a bunch of new bug fixes and features, if you want to hold out. Either way, please check this soon and see if it is resolved.

[Hosch250]

Closed as obsolete.