I have the following function that causes a significant visual jittering and lag in my access database - This is a treeview selection based on data in a table (tblDATA) with the fields:
Object | Attribute | Property | Value
I have tried echo and me.painting but figured my actual for loops need to...
'@TestMethod("GuardClauses")
Private Sub Create_GuardsNullBindingContext()
Test.ExpectedErrNumber = GuardClauseErrors.ObjectCannotBeNothing
On Error Resume Next
BindingPath.Create Nothing, Test.Path
ExpectError
On Error GoTo 0
End Sub
'@TestMethod("GuardClauses")
Private Sub Create_GuardsEmptyPath()
Test.ExpectedErrNumber = GuardClauseErrors.StringCannotBeEmpty
On Error Resume Next
BindingPath.Create Test.BindingContext, vbNullString
ExpectError
I think I'm onto something here
I'd like ExpectError to be part of the "expected error" test template, but it kinda wants a Test struct:
Private Sub ExpectError()
Dim Message As String
If Err.Number = Test.ExpectedErrNumber Then
If (Test.ExpectedErrSource = vbNullString) Or (Err.Source = Test.ExpectedErrSource) Then
Test.ExpectedErrorCaught = True
Else
Message = "An error was raised, but not from the expected source. " & _
"Expected: '" & TypeName(Test.ConcreteSUT) & "'; Actual: '" & Err.Source & "'."
End If
ElseIf Err.Number <> 0 Then
Message = "An error was raised, but not with the expected number. Expected: '" & Test.ExpectedErrNumbe…
so uh, I think I have a bit of an over-streamlining issue here
'@TestMethod("Bindings")
Private Sub Resolve_SetsBindingSource()
Assert.AreSame Test.BindingSource, Test.ConcreteSUT.Object
End Sub
'@TestMethod("Bindings")
Private Sub Resolve_SetsBindingPropertyName()
Assert.AreEqual Test.PropertyName, Test.ConcreteSUT.PropertyName
End Sub
actually, the way to test functionality that's already executed in TestInitialize, is to explicitly spell out the test setup - not to just assert the test state
in this case, the Resolve method is invoked in BindingPath.Create
'@TestInitialize
Private Sub TestInitialize()
Dim Context As TestBindingObject
Set Context = New TestBindingObject
Set Context.TestBindingObjectProperty = New TestBindingObject
Test.Path = "TestBindingObjectProperty.TestStringProperty"
Test.PropertyName = "TestStringProperty"
Set Test.BindingSource = Context.TestBindingObjectProperty
Set Test.BindingContext = Context
Set Test.ConcreteSUT = BindingPath.Create(Test.BindingContext, Test.Path)
Set Test.AbstractSUT = Test.ConcreteSUT
@IvenBach re test naming scheme: I'm naming the test module per the SUT (e.g. here BindingPathTests), and the tests each begin with the method being tested followed by an underscore and the expected behavior. So far I've successfully avoided the boring GivenThisThenThat naming scheme =)
In compiled environments when a class depends on an interface in another assembly the only time the assembly youre working on needs to recompile the refenece to the other assembly is when the public interface changes?
@IvenBach this isn't specific to the class/interface -- any kind of changes in the referenced assembly will require the referencing assembly to be re-compiled.
There's an interesting behavior I wasn't aware until RD pointed it out. I'm getting lot of inspection results for this inspection. They all have the same message; Error: Member 'xxx' has a 'VB_VarHelpID' attribute with value(s) '-1', but no corresponding annotation.. The common thread is that those are WithEvents variable. Seems to me Access automatically adds it. I tested in Excel and apparently it doesn't there.
I'm of mind that we should be able to ignore the inspection but only when it's VB_VarHelpID = -1. I don't want to ignore the inspection for other situation (including when it's not -1 for a VB_VarHelpID).
@FreeMan it'd be a problem if we wanted the test modules to implement interfaces. I doubt we have a legitimate reason to do that. But if you don't want to risk that, we can be creative.
Edge case. Refactoring a module variables name rewrites the entire modules contents. Do we currently have the ability to track where bookmarks have been placed? That way we can restore them after the renaming has occurred?
> **Rubberduck version information** Version 2.5.0.20232 OS: Microsoft Windows NT 10.0.18362.0, x64 Host Product: Microsoft Office 2016 x64 Host Version: 16.0.4978.1000 Host Executable: EXCEL.EXE
**Description** As part of renaming the entire modules contents are rewritten. This unintentionally removes bookmarks and breakpoints from modules as part of the rewrite process.
**To Reproduce** Steps to reproduce the behavior: 1. Create a module with a variable. 2. Place a bookmark and
Do we bring up host specific inspection results? Excel.Range.Find(...) reuses the last arguments for LookIn, LookAt, SearchOrder, and MatchByte. Worth bringing to the users attention as this just nipped me.
@IvenBach I did start looking into the in-mem layout of VBA at one point, I suspect there's some real gems in there, but it's wayne-level difficult to unravel.
its marginally easier using the VBA SDK, so you don't have a massive host address space to understand, but it's still... difficult.
In other news, I just signed back up with my university, I go back at the start of october.
Always makes me laugh when people hate on VB*... Why not send that hate where it's needed - Java, Javascript and PHP ;-)
going back to looking for gems in the VBA space though, quite tempted to do some more archeology. Feel like I've forgotten a fair chunk of what I found in the past. I should have written it up on the wiki...
There are docs out there on the interwebs that are rapidly disappearing, each with breadcrumbs. Some only exist on archive.org now
@MathieuGuindon in your article you use Variant for some of the interfaces argument types. Was that done in order to allow whatever type is needed? Whether that’s a String, long, int or even object?
I think I had the realization you didn’t use object because that would exclude value types.
While .Net has everything inherit from object which is why that is .Nets generic type.
VBA Rubberducking
VBA Rubberducking