@this Tried searching for the error message and "NUnit & Nunint3TestAdapater nuget packages and it's all good" as you said should be the answer. Contacted the author and hopefully I get a response. Thanks for your suggestions.
Yeah, I agree that from RD's POV, it doesn't matter but it might be more helpful to the users to pretend that Debug is a module. As you said, satisfies the non-object nature of Debug.
(and that's where I realized the gap w/ the child mock since the Scripting.Drives has no prog ID and thus cannot be created directly)
RE: docs & examples, I would love it if someone else took it up. That would be also be a good way to test the mocking and catch my bad assumptions/preconceptions
TBH, that was also a big roadblock for me to write unit tests in my VBA code -- too many things needs objects and it is not always practical for me to create abstractions and it also helps with documenting legacy code that needs to die
@pond poll regarding unit tests. Arrange Act Assert is the format of tests. Because I’ve been following RD I’m accustomed to Assert.FooBar( expected, actual ) instead of Assert.FooBar( 0, duk.DukGo ) which uses a member access. Is this more of a pond centric convention or is it used by other coders out there as well?
Besides being a strict comparison helping to avoid unforeseen issues with member access is there other reasons why this is done?
@this regarding the Arranger Pattern, for lack of knowing what to call it, would you consider that a subset of a factory method that’s just highly specialized?
@IvenBach I put the actual and expected in variables for debugging convenience. It is sometimes really hard to get at the tooltip in the debugger for member accesses.
You can see the direct comparison in the test result, but sometimes that is not enough.
Version 2.4.1.4627 OS: Microsoft Windows NT 10.0.17763.0, x64 Host Product: Microsoft Office x86 Host Version: 16.0.11901.20218 Host Executable: MSACCESS.EXE
**Description**
I am looking for a tool that can help me refactor controls on an Access form. There is no Rubberduck menu when I right-click on a control on a Access to rename it. (I've seen a screenshot like this for an word/excel userform though).
> Thank you for reporting! You raise up great questions.
1) Rubberduck is a *VBE* add-in and is meant to be host-agnostic. As such it does not directly deal with host. Access forms, reports and controls are a part of Access, not a pat of VBE, and to do something like rename requires interaction with the host, not with VBE -- renaming the contrls in the VBA code only would not be enough.
2) The ability to recognize a control as a control is on our todo list. In particular see [this project
> Thanks for your fast reply and the thorough explaination! Sorry that I missinterpreted Rubberduck, but it is great that a feature like this may be possible in the future :-)
Do you know by chance of a Access add-in which would allow me to refactor Form controls like I intended?
@PeterMTaylor Yeah that'd be one of the goals. The other goal is to set up tests for legacy code without changing the legacy code. Can't really refactor if you can't prove that the refactoring didn't break something.
@IvenBach Yeah. It is kinda similar to the static factory method, except we obviously don't keep it on the class itself because it only applies to the tests, not so much for production use. The idea is that if you author 100 unit tests for a class that only need new duck(), it'd suck if you realized down the stream that you needed to add something to the ctor so it's now new duck(ducklings). For those 100 unit tests you already wrote, they didn't really care if there are ducklings or not.
With the static arrange pattern, you simply add a new overloaded version and have your original 100 unit tests call the parameterless arrange with generic new Mock<Ducklings>.Object passed into the ctor for the Duck's and you can then write new unit tests that inject a specialized Mock<Ducklings> to test something about the interaction between the Duck and the Ducklings
> Unfortunately, no. I know there are add-ins that helps with renaming controls in userforms (e.g. MZ-Tools) but I am not aware of any Access add-ins that helps with the refactoring from Access.
However, I can give you an advice that might help in discovering them -- It looks to me that we have expressions like `Me![Text123]` which makes the code late-bound and therefore unverifiable. If you convert all `Me!` into `Me.`, and strip away the brackets so that it becomes `Me.Test123`, then you c
Basically, to avoid that the amount of tests starts to hamper adaptability of the code, the structure of the tests has to improve as well.
Using an arrange method is the first and öfter the final step.
For classes with more varieties and similar tests, like the quickfixes, we go one step further and use an abstract base class that already contains the main part of the test execution.
@Duga I have my doubts that Me!Whatever is late-bound.
> **Justification** When replying to #5092 I thought we already had a request for this refactoring but was surprised that there wasn't.
The proposal is to have a simple refactor that converts all bang operators into dot operators -- there is no legit reason to use bang operators, especially on `Me` on the LHS. The refactor should expand the expressions (e.g. Access' form's `Me!Foo` should become `Me.Foo` which is more descriptive of what the code is actually doing and more importantly makes
@M.Doerner Well, as noted in the #5093, Access form allows for dotted access to controls directly which beats the access via the collection which is always evaluated at runtime.
I recently inherited a very old and big codebase which unfortunately uses the bang operator and the default generated control names a lot - so there are LOTS of controls named like text1 - text999 on ONE form.
A automatic refactoring process would have been great for that, but I guess I have to manually fix it step for step over time.
> Addendum: the userforms also have the same behavior so it is obvious that there is a feature that enables the container to support member access via dot operator to the collection members. For the refactoring to be most productive, we'll need to be able to recognize when the container (be it Access Form/Report or Userform) can make dotted access and refactor toward that over the collection unlike the case of recordsets.
@MathieuGuindon no, Mug, PR or not, everyone mocks VBA - justified or not
@M.Doerner Umlauts make everything better! :)
In my ApptPlusWebDownloader.cls, I have:
Private Type TInfo
siteID As DownloadDataType
Browser As Browser
LinkKeys As LinkKeys
Url As String
UserID As String
Password As String
CallingLocation As String
Driver As Selenium.WebDriver
IsLoggedIn As Boolean
IsPageLoaded As Boolean
SiteValues As Scripting.Dictionary
SiteValue As String
DestinationPath As String
fileName As String
DeleteExistingFile As Boolean
TimePeriod As DownloadTimePeriod `<-------
End Type
Public Property Get TimePeriod() As DownloadTimePeriod
TimePeriod = this.TimePeriod
End Property
Public Property Let TimePeriod(ByVal Value As DownloadTimePeriod)
this.TimePeriod = Value
End Property
In other code, I have
Dim Downloader As IWebDownloader
Set Downloader = ApptPlusWebDownloader.Create(Chrome, ApptPlus)
Downloader.TimePeriod = Form_DataMove.ApptPlusRunFrequency.Value
but I get a compiler error claiming "TimePeriod method or data member not found". RD can see it and parse it just fine. What the heck am I missing?
Heck, I even restarted Access and did a C&R, just to be on the safe side. Still doesn't like it
I can do ` Downloader.DeleteExistingFile = True` w/o a compiler error...
> Both are default members, yes but last time I checked rs.SomeField is a compile error whereas frm.SomeControl isn't. In the latter case, it's obviously doing some extra to enable the dot access on the member (e.g. adding the controls to the interface dynamically). Recordsets never exhibit that behavior. In the cases of forms/reports/userforms, I suspect that being persisted, they can dynamically update the interface and thus expose the members directly on the interface, whereas recordsets
> Both are default members, yes but last time I checked rs.SomeField is a compile error whereas frm.SomeControl isn't. In the latter case, it's obviously doing some extra to enable the dot access on the member (e.g. adding the controls to the interface dynamically). Recordsets never exhibit that behavior. In the cases of forms/reports/userforms, I suspect that being persisted, they can dynamically update the interface and thus expose the members directly on the interface, whereas recordsets
``` Dim c As ADODB.Connection Set c = New ADODB.Connection c.foo ```
This compiles (but yield a runtime error unless I actually connect to some source that has `foo` as a procedure or something. However, unlike the `frm.SomeControl` case, there is _no_ intellisense downstream from the `foo`. Note that by default, all COM interfaces are extensible -- to disallow dot access on random members, the interface must use the [`nonextensible` attribute](https:
@FreeMan use the codepane dropdowns. select IWebDownloader on the left side, and the right-side dropdown will show you all the members you need to implement
That said - I'm iffy on the idea of exposing properties both on the class and via the interface. I'd rather have a single implementation and do the necessary casting to access the interface.
Not sure if that's the case w/ freeman's code but just wanted to go on the record
correct. ApptPlusWebDownloader.TimePeriod only needs to exist if the TimePeriod property ever needs to be accessed from ApptPlusWebDownloader's default interface - could be the case for a factory method, but then IWebDownloader probably doesn't need to expose a Property Let member for the TimePeriod property.
I'm seriously bumfoozled... In IWebDownloader.cls:
Public Property Get DeleteExistingFile() As Boolean
End Property
Public Property Let DeleteExistingFile(ByVal Value As Boolean)
End Property
Public Property Get TimePeriod() As DownloadTimePeriod
End Property
Public Property Let TimePeriod(ByVal Value As DownloadTimePeriod)
End Property
oh...
now I'm even more confused!
What in the name of all that is Holy was I doing?????
Private Sub Class_Initialize()
LogManager.Log TraceLevel, "ApptPlusWebDownloader.Class_Initalize"
Set this.SiteValues = New Scripting.Dictionary
Set CheckboxByID = PopulateCheckboxByID
End Sub
^ closest I've got to a factory, and I'm directly referencing this.
gonna chuck those unnecessary ones in the bin and make my life easier.
so yeah, no. No point in exposing anything else. You do want to force all access via the interface to avoid accidental use of default instance or whatever
yeah... all those "unnecessary" Get/Lets were the ones I was referencing. Now I need to go add IWebDownloader_ to the beginning of all those now failing to compile call sites.
:/
at least it'll be right now...
wait... this is my factory right here, isn't it?
Public Function Create(ByVal BrowserType As Browser, ByVal WhichSite As DownloadDataType) As IWebDownloader
On Error GoTo ErrorHandler
LogManager.Log DebugLevel, "ApptPlusWebDownloader.Create Browser: " & BrowserType & " Site: " & WhichSite
With New ApptPlusWebDownloader
.CallingLocation = "ApptPlusWebDownloader"
.Browser = BrowserType
Select Case .Browser
Case Chrome
This is what needs the internal ones, because now that I've commented out Public Property Let CallingLocation(), that fails to compile
but, I could change Public Property to Private Property and everything will work and be kopasetic, right?
@this Why "burdening you with choices you shouldn't have to make" instead of "flexible, with a default option that will work for some people but not everyone"? Not doubting what you are saying, I just don't understand yet how you reached your conclusion.
confusion on the CE between my Access project and Battleship: In my project, I see:
When I click the arrow next to the Interface, it expands and shows me the elements. However, in Battleship, I click the arrow next to the Interface and I get:
@puzzlepiece87 that link listed 3 different approaches to do essentially the same thing: start an WPF application. Only one is really enough. I can kind of see arguments for the XAML-only approach as an alternative for where you don't need customization, but given that all ultimately boils down to a variant of the Main with different effects is just needlessly complicating things.
@this That sounds both true but maybe also a natural consequence of WPF being used for sooo many things: console apps, desktop apps, browser apps, etc. It's difficult to make something so powerful without allowing customization in ways that can sometimes lead to what you mentioned above. But you're still correct in a perfect world, probably.
Having choices is fine. Having choices that aren't really necessary isn't fine. Knowing when it's really necessary is the hard part.
and from what I've seen, systems that has less choices work better generally than systems that can do anything but leaves up to you to do all the plumbing.
> **Rubberduck version information** Version 2.4.1.4848 OS: Microsoft Windows NT 10.0.15063.0, x64 Host Product: Microsoft Office 2016 x64 Host Version: 16.0.4873.1000 Host Executable: MSACCESS.EXE _and_ Host Executable: EXCEL.EXE
**Description** In Access, when I click on the "expand" arrow of an `Interface` in the Code Explorer it expands to show me the members. In Excel, it does _not_
**To Reproduce** Steps to reproduce the behavior: 1. Create an Interface, parse the code 2.
still doesn't mean it's a bug that only manifests when it's locked
I would hope that the fact that it's on a network share wouldn't make any difference (!). But I can see how a locked project might cause differences in the behavior because I know we have different code paths for locked projects.
> If macros are disabled in the Excel project, the CE will fail to expand the Interface tree view. If, however, macros are enabled, it will expand just fine.
@MathieuGuindon FYI- the log there may be some weird combination of Excel and Access parsing - not really sure how that works where there are 2 hose VBEs open.
@23fc9a62-56de-47fb-97b4-737890 No. I've had a slight uptick on LI views but no contact. Again using free time to work through my unit testing book. Finally understood [TestCase("FooBar")] attribute.
I can see why it'd be desirable in FP since as noted earlier compiler handles the branching; you just declare the expression without the procedural steps.
I can see Maybe<b> makes sense in a language that doesn't have nullable types. But introducing it in C# feels pointless as long as object references are nullable and there's a Nullable<T> to box up value types.
ok I don't understand wth the OP is trying to achieve here
I've had no problems with getting the class to enumerate 1 collection, but for the functionality I'm looking for, I wanted to enumerate 2. If I understand your answer correctly this is not something that can be done and I will need to find another solution for my second collection, perhaps an array. (I've also updated my question with more information) — Glenn G1 hour ago
So, I'm trying to declare a Const that holds a description for my class, the description will have a few line-breaks/new-lines (just a new paragraph) in it.
The value of which will later be returned trough a Property Get Method.
I'm aware that you can't use function calls like Chr(10) (which is...
So, I'm trying to declare a Const that holds a description for my class, the description will have a few line-breaks/new-lines (just a new paragraph) in it.
The value of which will later be returned trough a Property Get Method.
I'm aware that you can't use function calls like Chr(10) (which is...
VBA Rubberducking
VBA Rubberducking