a nice deep-dive into OOP+VBA - whether the MVVM architecture it enables ends up being the backbone of any production app or not.… Continue reading Making MVVM Work in VBA Part 3: Bindings →
> Unfortunately the library that includes the code that won't parse is a ball of yarn that won't even compile now so my suspicion is that RD won't be able to touch it until it will at least compile. I'll work on that problem. If I can get the project group to compile all the projects I'll send a link to a Github repo where you can download it. I'm rather convinced that this is (at least for now) not an RD problem but a compile problem. I'll close this issue and if I make forward progress wit
> Confirmed with the library developer, he doesn't compile the unit test project so I'm blaming the project and not RD. I am going to lobby very strongly that #5604 get merged very soon - I really need that feature!
> Closes #5542 The implementation options are: 1. ForwardObjectMembersToInterface 2. ForwardInterfaceToObjectMembers 3. NoInterfaceImplementation (the current default behavior) 4. ReplaceObjectMembersWithInterface The default option presented to the user is ForwardInterfaceToObjectMembers. The implementation of the PR matches the behavior as described in #5542 with the exception of ReplaceObjectMembersWithInterface. In the case where a member has external references, the...
refactoring retains the referenced member(s) forwarding the calls to the associated interface member (rather than refusing the request (per #5542). This avoids creating uncompilable code and moves the user further towards his/her original intent to completely eliminating the member from the class. In addition, the following improvements are also included: 1. Adds a ConflictFinder to prevent the user from generating an interface class with a conflicting identifier. 2. Prevents the selection...
of Members with underscores in their name to be part of the interface. 3. Uses the Indenter settings via the CodeBuilder
VBA Rubberducking
VBA Rubberducking