Max, I ran into another problem with the IProjectReferencesProvider -- since I need it on the declaration finder, the logical thing to do was to ctor-inject it. However, when I work out the injection, I realize that this causes a cycle because it is RPS that uses the DeclarationFinderFactory, but the implementations of the IProjectReferencesProvider both requires the RPS, so if I try to add the provider to RPS's ctor, that becomes a cycle. The factory is not abstract so CW is no help.
> Version 2.3.1.4445 OS: Microsoft Windows NT 10.0.17763.0, x64 Host Product: Microsoft Office x64 Host Version: 16.0.11231.20080 Host Executable: WINWORD.EXE
**Description** Refactor rename does not use the selected identifier.
In the code below I tried to rename Logger.report to Logger.log. I refreshed rubberduck then selected the identifier 'report' followed by rubberduck.refactor.rename. The identifier in the rename dialog box was the name of the procedure 'DoLogging' and no
> `logger` is a Variant, thus Rubberduck has no idea what `logger.Report` is - there's likely a warning log entry specifically about this.
While I agree this could *probably* be improved, it isn't a bug: Rubberduck can't know what the members of a `Variant` are.
If you have a logger interface, `logger` should probably ve declared as such - that would turn your late-binding duck-typed polymorphism (works? great! doesn't? boom, error 438) into actual interface-based polymorphism (compile-tim
> Basically there is nothing in `DoLogging` that even remotely hints at what the interface should be; everything being `Variant`, you get no IntelliSense for any of this, and `Option Explicit` can't spare you from a typo, since the compiler has no way of knowing what the members of a variant are. This is 100% late-bound code where none of the types are known until run-time; compile-time types are all `Variant`.
As a *static* code analysis tool, Rubberduck can't know what the runtime types are
> Hi, thanks for the super quick response. Yes, the code compiles.
> The Fakes API objects are meant to be very short-lived, i.e. the duration of a single test. Here they're alive from before the first test runs, until after the last test finished.
> These are hooks into the VBA runtime, intercepting internal function calls: them being alive for longer than they're needed is definitely not helping.
Would destroying the fakes objects right after the AdjustCell call possibly help?
> Hi, thanks for the super quick response. Yes, the code compiles.
> The Fakes API objects are meant to be very short-lived, i.e. the duration of a single test. Here they're alive from before the first test runs, until after the last test finished.
> These are hooks into the VBA runtime, intercepting internal function calls: them being alive for longer than they're needed is definitely not helping.
I tried destroying the fakes object right after the AdjustCell call (`Set Fakes = Nothing
> Hi, thanks for the super quick response. Yes, the code compiles.
> The Fakes API objects are meant to be very short-lived, i.e. the duration of a single test. Here they're alive from before the first test runs, until after the last test finished.
> These are hooks into the VBA runtime, intercepting internal function calls: them being alive for longer than they're needed is definitely not helping.
I tried destroying the fakes object right after the AdjustCell call (`Set Fakes = Nothing
What I want to do is to resolve the expression [A1] from a given line Set foo = [A1] to something like Excel._Global.Evaluate(), rather than runtime expression. Note there is also a separate case where Me.[A1] cannot be resolved until we know about the document type.
But how it will resolve will ultimately depend on the reference priority. In Access VBA project, by default, Set foo = [A1] will throw an error about unrecognized external name. But if we then reference the Excel library in the Access VBA project, that expression becomes valid because we now have Excel's _Global added to the global namespace.
And obviously, if an Excel VBA project references another Office library that provides a evaluate expression off a global class, that will not get accessed because Excel's will always take priority.
That would open up new opportunities for inspections surrounding implicit access to those global members.
Then I'll need to understand a bit more about how the resolver is composed.
It looks like it's only used by DefaultBindingContext which eventually gets new'd up from ReferenceResolveRunner through 3 different ways. It looks like the runner is CW-provided. So even if I were going to make a new binding, I'd end up needing to ctor-inject the runner, pass it down through the DefaultBindingContext to ultimately provide to it. Same thing even if I elect to use a factory.
I think I see the problem - it is used in the DeclarationResolveRunner
In other words, it's trying to treat the expression [A1] as a reference, rather than a declaration.
> I spent some time trying to replicate this locally with the provided code (and with a couple other scenarios inspired by the log file) and haven't been able to cause a crash in Excel 2013 x64. When Excel crashes, it should be generating a application crash event via Windows Error Reporting. Can you track down a sample WER log and post the contents here? You should find it in the Event Viewer under Windows Logs -> Application. There can be a lot of traffic through there, so you may want to f
Sanity check --- when is an expression a declaration vs. a reference? I'm thinking that for the expression [A1], which the full form should be Excel._Global.Evaluate("A1")... That's a reference, not a declaration, right? I suppose A1 could be considered a literal declaration, though.
In theory, if it resolves to an evaluate call then Something would be a string literal, and the [ ] pair would be an identifier reference on the evaluate method.
guts say it tries to resolve the identifier in the same order as anything else: local scope > module scope > project scope > refs in priority order > eval
@MathieuGuindon correct. That also means that for a expression on a say, a Worksheet (which I think has its own evaluate member), that evaluate will be the one used, not Global's.
For that case, we need the typelib api.
I thought I'd start with the simpler case of a standard module referencing a evaluate member of a global class.
because I suspect that the finder may need to cache the evaluate members from all classes for easy lookups/inspections
@M.Doerner Because that is where the OnBracketedExpression is called from. The declaration runner has the IProjectReferencesProvider but reference runner does not.
so basically what we're looking at is 1) stop creating Declaration for bracketed identifiers as a fallback; 2) resolve bracketed identifiers as implicit (?) IdentifierReference (?) to whatever Evaluate method is appropriate for the context. Right?
Yes, that'd be one way. But I'm not sure yet if this still needs to be within the reference runner, which why I was asking if it should be considered a declaration rather than a reference.
@MathieuGuindon Correct.
the original method we have will still be the fallback.
We do get a context for string literals though. Although I'm not entirely sure how often we use .GetText() to determine the content of a string literal.
IMO resolving the correct square-bracket expressions to the correct Evaluate call is one thing; resolving say [A1] to a Range (or [Field1] to a table fied) is a wild other.
@CindyMeister OP is asking about an "Else without If" compile error, so there had to be an Elsesomewhere. I'm trying to be helpful and welcoming and empathetic, since apparently Twitter thinks SO is such a toxic place to ask programming questions and explaining to people how to correctly ask questions on SO is "everything that's wrong with tech today". That said I agree I did infer stuff. If that's wrong, OP can roll back or edit to clarify further. — Mathieu Guindon2 mins ago
nah, I posted a 20-tweet thread about asking questions on SO as a quote-tweet response to some thread that was SO-bashing... got pretty ugly, pretty fast.
now for something completely different --- I'm looking at using API that's metered. and it occurs to me that if I make unit tests around the API, that could cost a bit too much, even if we use a small test dataset. Would it be more correct to consider such tests an integration test or treat it as basically untestable?
> Thanks so much for spending time on this! Learning a lot about VBA and Rubberduck The crash event log is attached.
> If you use them in the initialize code, Rubberduck will call it a single time during the test run, but the 2 faked calls become eligible for garbage collection as soon as ModuleInitialize exits. GC is non-deterministic, so it's impossible to predict what the state of the hook will be after ModuleInitialize exits.
OK, good to know. The event here is triggered within module
We have a new homebrew web based system that's a lot more granular and malleable, using the mvc principle works really well in doing most of what access does
in particular the legacy system has a giant memory leak that somehow happens whenever you use the file upload utility in it, it accesses network shares and does a bunch of strung together and improperly escaped command line calls, so things like putting spaces in file names make it die
IDK if that's a VBA thing or Access thing - I have not seen that documented in other VBA applications but I don't have any other host application project that has >1000 modules.
and as I said, it seems to be a soft limit, which makes it especially insidious.
Remember the objective is to test your behaviors in an *unit*, so you want to eliminate all the event handling and dancing with the documents. For a good example of this, see [this blog](https://rubberduckvba.wordpress.com/2017/12/08/there-is-no-worksheet/).
For your unit test to be independent, you will want to be able to invoke the sub directly without using events. Thus, moving your sub to a private sub on Excel worksheet won't do anything for you.
I'm curious how many SO questions on the VBA tag would disappear if there was a requirement to read the "How to avoid using Select in Excel VBA" question before it let you post.
VBA Rubberducking
VBA Rubberducking