FWIW the reason is because the installer isn't creating the \Plug-ins folder, and RD is creating it at run-time assuming it has permission to do so
i.e. it's a legit bug, trivial to fix
other than that, we used to have crashes on open given incompatible configuration settings between versions - not likely if that was a first-timer install
I have an OOP question. I'm (still) working on Controls, and I want to mimic the obect model of a UserForm, whereby, UserForm.Controls returns all of the controls on a form, but if one of those controls is a "container" like a Frame, then UserForm.Controls("Frame1").Controls returns all of the controls in that container. A container can contain another container (and so on), so you might end up with UserForm.Controls("Frame1").Controls("MultiPage").Controls("Frame2").Controls
I'm wondering about the best way of structuring that.
Were it me, I'd have only single collection of controls, then for each container controls, another collection that references controls contained in the original collection.
IOW, the containers' collection points back to the single collection.
@this yes, it's illegal. You can't use a control identifier that isn't a child of the container. That is, you can't do ChildFrame.Controls("ParentFrame"), but you can do ParentFrame.Controls("GreatGeatGrandChildControl")
waitaminute -- I'm not talking about reaching the parent controls. I'm talking about reaching the grandchildren....
My concern was that if reaching grandchildren are legal, you might need to provide access to the grandchildren (and further down) to make API more "familiar".
@this yeah, so storing controls at the container level, and if you request the controls of a parent container, the property recursively enumerates all of the child controls and containers.
VBE also allows userform1.controls("Frame2").Parent
FWIW x2: my rule when I need to access the parent or child Access.Form is to use a explicit variable, so that I can get compile-time validation of member access to the forms' controls. If API encourage that, all the better, I think.
If there were a common interface like EditableControl that I can use instead, I'd be over it.
But no, all I have is Control interface that includes all editable control that can contain Value and other non-editable controls. :\
With Access form, there are explicit instances so that it's easy to cast and thus achieve compile-time validation of its member access. I personally despise those fugly Forms!MyForm!MyControl syntax used by everyone else.
OK, so if I keep all controls in a collection at the top-most container I'll need to pass that collection by ref, as I recursively parse the child containers?
My earlier suggestion was only that each children collection refer to the controls already stored in a single collection at the top level. So the children controls' collection only need to store a ref back to the parent. Not sure if that's the best thing to do.
> This PR removes the Component property from QualifiedModuleName. This means that the QMNs no longer carry any reference to a COM wrapper and can be freely used as a keys corresponding to modules. To still provide access to componants given a QMN, I introduced the ProjectsRepositoryimplementing the interfaces ÌProjectsProvider` (readonly access) and ÌProjectsRepository` (aditional refresh capabilities). It saves a reference to the VBProjects COM wrapper aquired from the ÌVBE`passed...
to it through the contructor. Then, it loads dictionaries of all VBProjects, VBCompoonents collections, VBComponents and ICodeModules in the VBE. Several methods provide access to the entire collections with the projectIds/qmns attached or per projectId/qmn. On refresh and disposal, the appropriate wrappers get disposed. I refactores the RubberduckParserState to use an IProjectsRepository passed in through the constructor to perform its projects management. (The same is true for...
the IProjectsManager.) Moreover, I expused the repository as an IProjectsProvider on the RubberduckParserState for easier access by other functionality. Using the IProjectsProvider, I went on and replaced all uses of QualifiedModuleName.Component. (In a few places, accessing the component was actually unnessesary.) In order to make the tests for the repository work I had to perform some changes on the mock wrappers. In particular, the code module mocks can now be accessed on the...
MockProjectBuilder and the Equals and GetHashCode methods have been set up to mean reference equality instead of only retorning the default value of the return type. This PR is still WIP since I still have to merge the latest changes to next. This may take a while since I first have to update VS to be able to compile again after the merge. Moreover, there are some binding exceptions now whenever I parse. I would like to find out what broke there before merging this PR. Since this PR...
touches a lot of parts of RD, I would very much appreciate a review.
VBA Rubberducking
VBA Rubberducking