Hi there. Just referring to your pieces of advice so that you know how to too :-) About integrating .DLL files into .EXE file.
So after few hours and many angry moments it finally works. Using: https://bitbucket.org/wvd-vegt/ilmergegui 1) Installed ILMerge from the link in repo (official MS, admin rights neede even for "user installation"...) 2) Downloaded ILMerge-gui portable 3) just select EXE and all DLL, drop it there 4) specify where to save the merged .EXE file and hit Merge.
I've written a function to remove empty or "" value elements from an array or in other words return an array consisting only of elements containing a value.
Option Explicit
Public Function RemoveBlanksFromArray(ByVal TheArray As Variant) As Variant
Dim temp As Variant
ReDim temp(LBoun...
@QuackExchange to me using a dictionary and returning an array of keys after iterating the original array would be the best option. Will write an answer when at work.
I quickly learned I had to learn about lots of things, and did. Eventually, I was looking for a more complex project than my personal one to expand my skills more.
Chris recruited me, and I worked on it over my next few college breaks.
Was it 2 or 3? I don't remember. One summer and one winter break for sure.
in other news, I'm considering adding a quickfix for the "keep it to yourself" inspection (form controls being treated as public fields), but early analysis shows that this would be essentially a "move member" refactoring, so... I think the best course of action might be to PR the inspection without a quickfix first, then do the refactoring, and then implement the quickfix. A single PR with a refactoring, an inspection and a quickfix would be too large for its own good, right?
Then, I couldn't land an internship because I didn't have a driver's license yet. I almost got one, I think, but they said I needed a license, and I didn't get past the in-person interview.
So, my professor said I could work on this, and Mat just had to agree to fill out a couple forms, and I got to work on it for 500 hours.
And I'm grateful for that. Don't think we could have gotten anywhere close to where we are because of your internship contributions which still is foundational.
@MathieuGuindon I think 3 PRs sounds good. But a bit fuzzy why it would be a "Move Member" refactoring. Isn't that more like "Change accessibility" refactoring?
Yes, "Encapsulate field" makes more sense. Probably can just update the EncapsulateField to handle the control event handlers, so it has different caption but basically same refactoring logic.... right?
so the fix involves adding a property and replacing the external calls with calls for that property
where "move member" comes in, is that the ideal fix would be to pop a dialog and let the user pick controls whose state they want to extract to a new class
so the QF is like two steps: first encapsulate the controls, then move them to a new (or existing) class
oh, no, the inspection doesn't care for event handlers being public (IIRC there's another inspection for that) -- it's all about the controls themselves
and bear with me but I'm not sure I see the use of encapsulating the field unless you are actually moving it to another class. As you say it's public anyway, so Forms("foo").Controls("bar").Visible is legal even if we don't like that.
what we really want is a class that has ThisThing private variable set at the initialization, and we do ThisThing.Visible instead of Forms("foo").Controls("bar").Visible
meh. what we want is for the form to deal with control visibility (i.e. UI concerns), and for some "model" to deal with "control values" -- exposing control values as readonly properties (on the form itself) is already a good step forward, even if the controls are public
so I want the QF to encapsulate the properties and move them to a model class
Exposing that kind of stuff as a properties as an alternative to direct access to the underlying controls would work well for both UserForms and Access form (bound one in particular).
Whether bound Access form needs a model, that's a matter I have not gotten around to.
the results' Properties could hold the metadata needed for that
basically with the QF I'm thinking of, you could single-handedly extract the model off how the form's control values are being accessed from the client code
@Hosch250 I'll also throw in the fact I've had to learn a lot just to learn what it is the code base is doing. You can call me the "Pitch drop learner".
> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4851?src=pr&el=h1) Report > Merging [#4851](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4851?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/2925035f5210cb7f56792554a43f6e44052acb82?src=pr&el=desc) will **decrease** coverage by `0.07%`. > The diff coverage is `69.22%`.
@this Regarding my typeLib API PR, I am a bit unsure whether it is worth merging it before Wayn's PR. It will miss a few things, like all constants, and I am not too sure about the effect on the runtime of the parser.
@M.Doerner I suppose we could ping Wayne to see if he has any ETA. If he thinks it'll be longer still, we might as well just go ahead and merge the PR since it solves other problems. Alternatively, we could create a new branch and see how well your PR and his PR work together & solve problems.
Speaking of uncertainties - do you have any particular preference as to whether my COM commands PR should be merged before or after your refactoring PR?
> @WaynePhillipsEA there is some uncertainty as whether the PR should be merged before @MDoerner 's work in PR #4535 get merged. I know you've been busy so if we can get an idea of when you will finish the pending tasks for this PR to be ready for merging, that'd help us in planning for the next release -- we just had released 2.4.1 and would like those items included in the next release. Thanks!
FWIW I'm holding off any work on Move Member until the refactorings PR is merged. I guess this pretty much means the "public form control access" inspection can be PRd as-is then (needs more tests though)
> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4851?src=pr&el=h1) Report > Merging [#4851](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4851?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/2925035f5210cb7f56792554a43f6e44052acb82?src=pr&el=desc) will **decrease** coverage by `0.07%`. > The diff coverage is `69.22%`.
@this My typelib PR will need some more work before it is ready. However, as far as I understand Wayn's PR, how to treat vba classes will be different after that PR.
My PR originally really was not intended to deal with the problems of the typelibs for vba classes. Its main intent was to wire up the API in the parsing process.
Yeah, and the changes to the VBA class declaration was more of a byproduct than than main focus of Wayne's PR, among few other things. Those would be welcome changes, and I would rather get it in sooner so we can benefit from the changes, not just for the caching COM project PR.
In Access, for example, one can create a form without a code-behind. However, in that case, no VBComponent object gets created. When you set the HasModule property to Yes via Access UI, it will create a VBComponent object with a corresponding CodeModule object.
In VB6, we have resources and few other types that do not have a code modules.
> @bclothier on one hand I'm thinking this needs to be handled by block completion.. On the other it's something that's really a consequence of SCP handling the parens completion here - the line being validated/prettified through SCP is preventing the vanilla-VBE block completion.
Feels like special-casing parameterless procedure blocks in SCP would be an overreach of SCP, and yet while putting that concern with block completion would make sense, it would also leave vanilla completion broken
probably lots... but I don't think that's realistic until declarations have a full inheritance hierarchy... and inspector no longer gets declarations off the parser state
I mean, a class module Foo with a private variable Bar, and a Public Property Get Baz, is already 4 declarations. Probably need a builder to make this convenient, but the way it is, we can copy'n'paste from the GH issue to create a new failing test.
We wouldn't be able to do that with a hand-crafted declaration.
Actually, there is an idea that'll get us the best of both worlds.
was thinking that the Serialize button would e used to enable you tow rite mock code, then create declarations from it. You can then add it to the source code control, and pesto, easy deposit.
IDK, thinking we don't really need enough of them to make a static helper too annoying. Nothing to deserialize or process, just plain declarations ready to consume wherever they're needed
e.g. public static Declaration UnusedVariable(string name)
(of course it's more complicated than that, but you get the idea)
Hm, this is a bit unintuitive: the rename reafactoring tries to rename the containing class if a built-in identifier is selected instead o complaining about the selected identifier being built-in.
I've written a function to remove empty or "" value elements from an array or in other words return an array consisting only of elements containing a value.
Option Explicit
Public Function RemoveBlanksFromArray(ByVal TheArray As Variant) As Variant
Dim temp As Variant
ReDim temp(LBoun...
VBA Rubberducking
VBA Rubberducking