> Closes #3326 Partially addresses #4096 IMPORTANT: This PR does not update the serialized declarations used by the unit tests. At some point these apparently became stale, so 34 tests are failing with the new declarations. I will PR the new declarations when #4182 is resolved. @Future: If you make any changes that effect the behavior of the COM collection, you HAVE TO update the serialized declarations files for the unit tests. If you don't, it basically invalidates the tests and...
Well damn... The Office 8 interop lib looks pretty broken... tried regenerating from MSO97RT, same cast fail. Might need some help from the IDL \ interop gurus on this one...
> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4189?src=pr&el=h1) Report > Merging [#4189](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4189?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/93f51434821ddf0f6ab13ee3f1e30f1003690bad?src=pr&el=desc) will **decrease** coverage by `0.21%`. > The diff coverage is `0%`.
@PeterMTaylor everything. It's basically that the quoting rules are way too arbitrary and thus difficult to memorize. Sometime you don't quote at all. Sometime you need ' to quote. Sometime you need to use ". Sometime you need to use some different commands (e.g. put in & in front) if you need to embed quotes. I could go on but the overall point is that there is no simple rule to managing the quotes/commands.
It does not help that I'm going from batch to PS (and sometime I'm running batch-like command from PS) which further complicates the quoting issue which was already complicated to begin wtih.
> Thanks to @rkapka for the assistance - there is an issue with space in the path for powershell script. This PR fixes the issue and also fixes the issue with MIDL which is uh, weird about backslash in the path (and it doesn't want to take a full path but a directory and file name separately). Since I was mucking in the script, I took liberty of adding auto-deletions of previous debug registration scripts with hard-coded for 10 files. I also noticed that newer project did not have the...
@Duga @Vogel612 something to keep in mind when you make new project - you need to manually add the analyzer reference to ensure the project is covered. Technically it's overkill since the only project that should have COM stuff would be within the API and Main but we want to catch them all, so...
> At some point, changes were made in either the `ComReflection` namespace that let changed the declarations returned by the `ReferencedDeclarationsCollector`. The serialized libraries that are used by the unit tests were _not_ updated. This means that any unit test that relies on a set of `SerializableDeclaration`s is now suspect.
When I attempted to update them for PR #4189, I was greeted with 34 failing tests and hundreds of lines spamming the output window like these:
> Instead of serializing declarations, would it be better to maintain `.idl` files, which can be compiled without a backing implementation. That then can be unit-tested without going stale since we now have to actually load the type library and can reliably load it since we are now generating it ourselves?
For contributors that don't have C++ build tools (and therefore MIDL compiler), the tests can be set up to fall into inconclusive state. However, AppVeyor has MIDL so we can rely on it to a
Severity Code Description Project File Line Suppression State Warning CS1762 A reference was created to embedded interop assembly 'stdole, Version=7.0.3300.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' because of an indirect reference to that assembly created by assembly 'office, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c'. Consider changing the 'Embed Interop Types' property on either assembly. Rubberduck.VBEditor.VBA C:\Users\Peter\Source\Repos\Rubberduck\Rubberduck.VBEditor.VBA\CSC 1 N/A
interesting...Severity Code Description Project File Line Suppression State Warning There was a mismatch between the processor architecture of the project being built "MSIL" and the processor architecture of the reference "olewoo", "x86". This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and references, or take a dependency on references with a processor architecture that matches the targeted processor architecture of your pr…
> @bclothier That's probably not a bad idea at all, especially given the way we're currently using them in the tests. What makes that an even better idea is that we could finally write unit tests for the ComReflection namespace.
yes i recall conversation this morning about needing C++. I decided to go into features and ensure I have libraries from C++ in and recompile hopefully resolves 401 errors I have now from last resync.
sorry had to close VS for the installer to put in C++ stuff. I will post that response once its finish as my hard disk is very slow and old active 100% most of the time even for swapping memory to disk vis versa.
> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4189?src=pr&el=h1) Report > Merging [#4189](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4189?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/93f51434821ddf0f6ab13ee3f1e30f1003690bad?src=pr&el=desc) will **decrease** coverage by `0.21%`. > The diff coverage is `0%`.
Severity Code Description Project File Line Suppression State Error The type reference cannot find a public type named 'EndOfLineCommentStyle'. Line 20 Position 34. Rubberduck.Core C:\Users\Peter\Source\Repos\Rubberduck\Rubberduck.Core\UI\Settings\IndenterSettings.xaml 20 Error The type reference cannot find a public type named 'CodeInspectionSeverity'. Line 38 Position 25. Rubberduck.Core C:\Users\Peter\Source\Repos\Rubberduck\Rubberduck.Core\UI\Settings\InspectionSettings.xaml 38
> Addressed potential leaky pointers, no longer WIP. Props to @MDoerner - the DisposalActionContainer made that a cake walk, it's definitely going in my tool bag.
> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4189?src=pr&el=h1) Report > Merging [#4189](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4189?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/93f51434821ddf0f6ab13ee3f1e30f1003690bad?src=pr&el=desc) will **decrease** coverage by `0.23%`. > The diff coverage is `0%`.
[rubberduck-vba/Rubberduck]MDoerner pushed commit 99b41b47 to next: Made the major and minor version on AddReferences on the MockProject mandatory to avoid that people forget to set them when they are required.
Fix space issue in the path for powershell Handle space for MIDL compiler Implement deletions of old registry entries (currently set to 10 files) Add analyzer to the new projects
> I'd go 10 steps further with this personally. IDL doesn't have a [Flags] attribute for enumerations like .NET does, but it should be relatively easy to heuristically determine whether or not a set of enum values represent bit masks at a high confidence level. I'd propose adding a custom decoration to those enumerations and basing inspections on _that_ also. I.e.:
> **Mathematical operation on an Enum that doesn't represent flags** > Mathematically operators are being applied to members of
> I know this is already merged but there is one more consideration...
From [the specs](https://msdn.microsoft.com/en-us/library/cc237750.aspx), we see that: > ppFuncDesc: MUST be set to a FUNCDESC structure (see section 2.2.42) that contains the data values associated with the specified member of the method or dispatch method table, or NULL if no such member exists.
It might be that the.NET implementation will throw exception in such cases but I would rather not assume. Therefore, before
> @bclothier - This line specifies the interface contract:
> MUST be set to a FUNCDESC structure (see section 2.2.42) that contains the data values associated with the specified member of the method or dispatch method table, or NULL if no such member exists.
If no such member exists (and `ppFuncDesc` is set to NULL), this return value documentation applies:
> The value of index did not specify the ordinal position of an element in the method table.
@IvenBach Those properties don't have explicit getters and letters in the MIDL, but they're implied. It's a lot like how a Public variable in a class module, looks like a variable, but a consumer of the class can read and write to the variable, so they're really just a shorthand way of writing a property, albeit without encapsulation, in VBA's case.
In VBA, you can check a class' public variable in the OB, and it will say Public foo As String, without indicating that it is a property, other than the icon. But if that class is an interface, and you create a class that implements the interface, you'll notice that the VBE creates both a Property Get and a Property Let implementation. You'll also find, if you inspect an instance pointer, that there are 2 pointers for each public variable - one for the Get, and one for the Let.
> Another note about properties. Publicly declared variables in the declarations section of class objects (class, form, etc) are actually properties generated by VB at runtime. IIRC, the first declared is actually the &H1C offset, not the first method in the class. But been ages since I looked at that scenario and have opted for writing Get/Let properties vs. using publicly declared variables in classes since I learned that tidbit.
> > [AddressOf for Class Methods (and other VTable exploration)?]vbforums.com/…)
> As per a recent discussion in chat about Objects being capable of having Get, Let and Set procedures, it seems that declaring a Public variable as Variant in the interface, will result in the implementation requiringGet, Let & Set implementations. You can't, optionally add a Let for an Object returning variable. By contrast, a Property declared as Variant only requires implementations for the Property p
> RD's fix for this will also need to take renaming the interface, and *all* of the relevant property procedure implementations - right now, Rename only renames the property procedures implementations for property procedures defined in the interface, and not the public variables.
Likewise, renaming a public variable in the interface, does not currently result in renaming of the associated property procedures in the implementations.
> RD's fix for this will also need to take renaming the interface, and *all* of the relevant property procedure implementations - right now, Rename only renames the property procedure implementations for property procedures defined in the interface, and not the public variables.
Likewise, renaming a public variable in the interface, does not currently result in renaming of the associated property procedures in the implementations.
> Extending [this](https://github.com/rubberduck-vba/Rubberduck/issues/818#issuecomment-344881734), how about blocks of Markdown? ``` Sub Foo(Bar As String) '@description = "This does the Foo with the Bar" '@documentation = " ' ### Remarks ' ' Not with a Bar, but a Beep '" Beep End Sub ``` This assumes the possibility of multi-line annotations.
I've come across a couple of scenarios where I'd like a robust method to change the path (blah.blah.blah.myObject) to an object or routine, and I wonder if this is possible with Rubberduck
First scenario: I have a lot of calls to some routine Bar() in my code. I've decided to make that function...
> @zspitz, I guess it's just an extra Interface implementation for each description text format/renderer. There's a risk that we're jumping the shark by offering too many formats, and given the limitations of the VBA codepane and character-sets, I'd be more inclined to stick with XML as at least special characters can be represented with escaped entities, can be readily transformed, is in keeping with .NET documentation, and building snippets will be easier.
> Tried running RD on a fresh install of Windows 7 SP1 (no MS Office). Fails at startup as it's unable to cast Office COM components (such as CommandBarContol) to the corresponding Office.v8 RCW interface.
> We don’t want to reinvent anything here, assuming this 3 yr old feature request ever gets implemented. VB.Net style doc comments so the existing Sandcastle tooling can be leveraged.
> Dumb question: do the library paths for the freshly serialized declarations agree with those specified in the `MockVbeBuilder`?
I think, if you update the serialized declarations by new ones generated with a different location of the libraries, the values in the `MockVbeBuilder` have to be updated as well.
> @comintern there's already an issue for `'@Flags` on project-level Enums, so this would tie in nicely:
see: #3375
The problems come with enums like `VbMsgBoxStyle` - where there are flags *and* extra members that are already the result of bitwise operations like `vbDefaultButton4` , or they're repeated, like `vbDefaultButton1` and `vbApplicationModal ` ```text typedef [uuid(ed822011-6d7f-11cf-b949-00aa004455ea), version(0.0)] enum { const int vbOKOnly = 0, const int vbOKCancel =
> The issue is that the refactorings need to work off an accurate representation of the codebase. Otherwise, it can end up doing wrong things to the codebase, so for that, parsing is necessary.
It's not impossible to bypass that requirement but in order to do that, I think we have to revise the parsing strategy. At the moment, parsing will bail out at first encounter of error, so it is possible that we won't have most up to date parse tree for a particular module. This is much bigger change
> There is another potential issue - there may be enums that contains an union. For example, assume we have this enum from some other library that renders in VBE as:
``` Public Enum IAmReallyFlagsPinkyPromise ModeOne = 1 ModeTwo = 2 BothMode = 3 End Enum ```
The `BothMode` is basically a `ModeOne Or ModeTwo`. Even if it was originally written as `BothMode = ModeOne Or ModeTwo`, there's no guarantee that it won't retain that information once exported into a type library. It woul
> To be honest, our parser can parse quite a lot of broken code. It mostly breaks on incomplete structures like multi-line if blocks without an `End If`. Since the `Implements` statement is a full statement, the parser will not complain.
In case, we end up in an error state, the refactoring should abort anyway.
However, I would propose to solve the major part of this nuisance in another way: why not create an `AddInterfaceImplementation` refactoring? That could ask for a name for the new
> Using a command like `ThisWorkbook.VBProject.References.AddFromFile "C:\Program Files (x86)\Common Files\microsoft shared\VBA\VBA7.1\VBE7.dll\3"` (note the index numeral, at the tail of the path), it's possible to add a `Reference` that isn't the default TLB for a file (in this case, the `VBInternal` TLB is referenced), and that reference need not be registered. VBA happily allows this, but Rubberduck is unable to successfully parse the type library.
> @ThunderFrame I'm not sure that these would really be a problem. VbMsgBoxStyle can be determined to be set of flags, so in my head, simply using Or to join them shouldn't trigger the inspection noted above. Perhaps a second inspection for semantically stupid flag use (it would need a better name than that)? For example there isn't really a reason to do something like vbOKOnly Or vbApplicationModal. Or maybe (once we're evaluating expressions) generalize that to any bitwise expression
@ThunderFrame Oh, it's there too. Although if Candy Crush ever triggers a reboot on my machine, watch the for me in the news, because I'd be driving to Redmond...
> I like the direction @MDoerner is going here. I do want to point out a different scenario, however.
Suppose we have a interface `IFoo` and two classes `FooOne` and `FooTwo` that both implements the `IFoo` interface.
We certainly can use the `AddInterfaceImplementation` to create implementation when we create the `FooOne` and `FooTwo` classes. However after that, if we add a new method to `IFoo`, it has to be then implemented in both `FooOne` and `FooTwo`. If we try to parse, we cannot co
@this The question was: will the result be a variable with declared type Long and value type Long or a variable with declared type Long and value type Integer?
That is actually more interesting when assigning a Single to a Double variable. There it has implications on comparison operations.
Public Sub t()
Dim i As Integer
Dim l As Long
Dim v As Variant
Debug.Print LenB(i), VarPtr(i)
Debug.Print LenB(l), VarPtr(l)
Debug.Print LenB(v), VarPtr(v)
i = 1
l = i
v = i
Debug.Print LenB(i), VarPtr(i)
Debug.Print LenB(l), VarPtr(l)
Debug.Print LenB(v), VarPtr(v)
v = l
Debug.Print LenB(v), VarPtr(v)
v = &HFFFFFFFF
Debug.Print LenB(v), VarPtr(v)
End Sub
> @MDoerner Not a dumb question (and yes, I'm an idiot) - they're different. I'll update after work and if everything is kosher I'll get the tests updated and open a new issue for @bclothier 's suggestion.
> @bclothier let's repeat that again: The missing interface implementation is not actually a problem for the parser we have. It's only if we disallow overriding the compilation warning that we get a problem here.
The Parser does not actually compile the VBA code it parses. With quite some extra work, it could conceivably do that, but I'm rather confident when I say that that's a rather complex venture to embark on. The Parser doesn't **need** the code to be compilable in all cases. It just ne
> As per one of the queries in https://stackoverflow.com/questions/51358346/replace-path-to-function-or-object-with-rubberduck , it would be nice if Rubberduck could refactor identifiers to be qualified, so that their origin/scope is clearer, and/or so that new identifiers can be introduced without adjusting the intended scope of the existing identifier usages.
If I have a public variable name `Foo`, and a public function named `Bar` in `Module1`, and I have usages of `Foo` and `Bar` littered
> Sorry - didn't mean to imply that the parser depends on the code being compilable in order to tell us that something implements something else. The primary reason behind the compilation check was because a uncompilable code is most likely a unparsable code. However, the `Implement` falls outside the overlap between parsability and compilability of the code.
Unfortunately, there is no way for us to know why a codebase won't compile; all we get back is a Boolean value indicating whether we s
> #3033 could be remotely related, that said, the System-Requirements in the Wiki state that Windows Vista or later is required, as such this isn't necessarily something that we want to fix
> The https://stackoverflow.com/questions/51358346/replace-path-to-function-or-object-with-rubberduck question alludes to a situation where you have 2 or more enums or types that you'd like to merge, or existing enums/types that you'd like to split into multiple enums/types.
Eg. I have 2 enums for ScrollingPosition, `prHorizontalScroll` and `prVerticalScroll`:
```vb Enum prHorizontalScroll scrollLeft scrollRight End Enum
Enum prVerticalScroll scrollTop scrollBottom End En
@M.Doerner to be fair MS was in a difficult position. With so many people unwilling/unmotivated to update/upgrade, it made it difficult for software vendors to utilise newer technologies because of reach. we might all pay the price with restarts, but Win10 does have some pretty impressive stats on adoption of the latest build, which makes development easier and cheaper.
@Hosch250 for some reason it feel broken to me if you have to update OS to fill a security hole. If the OS was shipped locked down, where the user had to explicitly enable a feature that is a security risk, then it would be less of an issue.
@this and has there ever been, and will there ever be such a thing as a locked down OS? it's too hard when there are hardware issues like Spectre and Rowhammer
@Hosch250 Again, a good OS should ensure that the user is aware of any changes or when some code could be executed in some context. That's all I'm saying.
@this i don't have to install anything - visiting a webpage (even a reputable webpage that allows 3rd party ads can be dangerous), opening an Office document, inserting a USB, etc. All are risky, and yet I'm not installing anything
despite our best intentions, we're leaking memory, and crashing the host. it's hard to avoid buffer overflows and all the rest of the holes that don't appear to be holes. Some of the holes being discovered today have been open for decades, despite thousands of hours of vetting
@this take out my network cable, drives and ports. and while you're at it, get rid of pebkac
Yes, all those things are true, and I never thought otherwise. My point is simply this: don't allow arbitrary code execution from remote source and you've made most holes unreachable.
that's why social engineering is the most popular method they use to reach those holes, no?
@this This is why I haven't been able to work from my VM host's filesystem in Windows 10. Making it so obnoxious to actually use an operating system that it provokes the user to disable all of the shiny "security" features is IMHO counter-productive. If the UX is "I need to shut this down to work", that's a problem.
@this maybe I'm conflating all of the NSA scandals. Point is, state-level intrusion of your system/pc/device/phone must be assumed, if you're an entity of interest.
On the flipside, you know the task is hard when you've got 3rd party companies offering iPhone cracking services, where even Apple doesn't supposedly know how they do it
@ThunderFrame When you think about it, all you have to do is watch me long enough and you will know me well enough. Heck, Google probably knows more than NSA does. :\
I've come across a couple of scenarios where I'd like a robust method to change the path (blah.blah.blah.myObject) to an object or routine, and I wonder if this is possible with Rubberduck
First scenario: I have a lot of calls to some routine Bar() in my code. I've decided to make that function...
VBA Rubberducking
VBA Rubberducking