VBA Rubberducking

Duga

12:03 AM

REFRESH!

[Minesweeper] 148 Games Played. 96 Bombs Used. 21063 Moves Performed. 5 New Users

[rubberduck-vba/Rubberduck] 1 issue comments

Duga

7:54 AM

[rubberduck-vba/Rubberduck] ZeldaJC starred us

Duga

9:19 AM

[rubberduck-vba/Rubberduck] BenediktCromind created comment on issue #5854: Code Inspection Window

> I tried to reproduce this. I have the same monitor setup as @RSquared64. Here is my version information:
> Version 2.5.2.5958
> OS: Microsoft Windows NT 10.0.19043.0, x64
> Host Product: Microsoft Office x64
> Host Version: 16.0.13801.20864
> Host Executable: EXCEL.EXE

This is how my window looks like:
![image](https://user-images.githubusercontent.com/77499185/134145446-f7cc40bb-669b-47b5-aa85-ba652f0d6059.png)

I don't have the behaviour that the window is off-screen but

Duga

11:06 AM

[rubberduck-vba/Rubberduck] MDoerner created comment on issue #5854: Code Inspection Window

> Both these issues come up from time to time. The general cause is that something went wrong with the VBE's handling of our windows.

Handling the position is entirely done by the VBE. It also persists where a window was open last and tries to use that information to open windows in consistent places. Unfortunately, something seems to go wrong between the VBE and our windows sometimes, leading to very inconvenient window positions.

In this case, what you should be able to do is to activat

Duga

11:30 AM

[rubberduck-vba/Rubberduck] Vogel612 created comment on issue #5854: Code Inspection Window

> This makes me remember the ages old docking bug that sometimes caused a crash when the VBE was sending values that were incorrectly converted to a negative value... Maybe there is some way to correctly deal with these window sizes that also fixes this issue.

FreeMan

3:04 PM

this is odd... Can anyone explain why ByVal loggerName as String is flagged as Parameter Not Used, but the others aren't?

'@PredeclaredId
Option Compare Database
Option Explicit
'@folder Utilities.Logger

'@Ignore ParameterNotUsed
Public Function FormatMessage(ByVal level As logLevel, ByVal loggerName As String, ByVal Message As String) As String
End Function

That right there is the entirety of this particular module. (Yeah, I know...)

this

3:22 PM

is it supposed to be an interface? If so, you probably want @Interface

but that's not answering the original question-- my hunch is that there's a logic error in the ignore directive

Let's put it to test, though.... if you took out the ByVal level as logLevel, what happens to the inspection results?

FreeMan

@this the @Ignore was added after it was flagged.

This is actually the (very empty) implementation of an interface. Remove the parameter and code doesn't compile.

this

O_O

FreeMan

No, wait, I've go thtat backwards. this is the Interface. the Implementation also has the parameter but doesn't use it.

this

(am I missing a Implements statement?)

ah, i see.

hmm what if it's being smart? Remove the Implements then look at how inspection is flagging the interface's FormatMessage.

FreeMan

Weird that the Interface gets flagged - it doesn't know or care if any particular implementation uses or ignores a parameter.

this

3:30 PM

I agree that it's weird to flag an interface -- it might be the result of not having an @Interface annotation, but RD should still be able to infer that from the Implements in the other class module that it's being implemented and raising a inspection on the implementation, not the interface.

FreeMan

Interestingly, even without '@Interface, the CE sees it as an Interface

this

Yes, probably because RD is inferring it's an interface.

FreeMan

@this Even with @Interface, it's still flagging

this

is it the result of the implementation not using that parameter, though?

FreeMan

@this See, even the Duck is picking up on VBA's trait of being "helpful" without telling you about it! ;)

Correct, the (one and only) implementation is not using the parameter.

As soon as I add

this

3:34 PM

Therefore, the bug is that the inspection is flagging the interface, not the implementation.

FreeMan

Dim x As String
x = loggerName

to the implementation, the inspection goes away on the Interface

this

Right that makes sense.

FreeMan

It is also flagged at the implementation (I've got an @Ignore on the implementation).

this

the parameter, not the x that you added, right?

FreeMan

(code was borrowed from Mug, so I didn't wanna get rid of stuff I might use in the future.)

Hi. My name's FreeMan. I'm a code hoarder.

@this correct, without the 2 lines above, it was flagged in the implementation as unused. ATM, the x has three inspections about bad naming & being unused - all expected.

this

3:36 PM

Keep in mind, though, RD isn't omniscient - it can tell you that a parameter's unused, but it can't tell you if that is a bad thing or not. That'll be up to you to say so.

FreeMan

> RD isn't omniscient

since when???

:D

this

hmm. It sounds like it's flagging both interface and implementation.

FreeMan

yes, yes it is.

a smidge excessive, I'd think.

this

well, imagine you have 10 implementations. 2 of them doesn't use it. A result on the interface would alert you that there are unused parameters by some implementations.

FreeMan

I would think that it's not entirely unreasonable that a particular implementation may not need to use every parameter available to it.

this

3:38 PM

but then you'd have to hunt down 2 implementations that doesn't use it.

it'd be helpful if the interface inspection was able to point you to the 2 implementations missing it.

FreeMan

It's tagged as a Warning level inspection. I suppose it could actually be just a Hint or Suggestion...

this

Yep. It's likely not warning-worthy

FreeMan

Well, in general, no, I guess it is worthy of Warning. It's just in this special case that it's not.

this

No, I'm thinking on the implementation, it's a warning. On the interface, it's a hint.

FreeMan

Can the duck differentiate and change the inspection category on the fly?

this

3:41 PM

But the bigger problem is that the interface result doesn't tell you where it's not used.

I think so.

If we aren't changing anything else, I'd sooner remove the interface result altogether --- we already have the results on the implementations itself. The interface result is only useful if we have some way of viewing where it's not used by its implementations.

FreeMan

3:56 PM

Maybe I'll write it up as a feature request

mkay... this is odderer...

I created an example. IExamFoo:

'@Folder("Utilities.Example")
Option Compare Database
Option Explicit

'@Interface
Public Function Foo(ByVal Bar As String, ByVal Baz As Long) As String
End Function

GoodFoo:

'@Folder("Utilities.Example")
Option Compare Database
Option Explicit


Implements IExamFoo

Private Function IExamFoo_Foo(ByVal Bar As String, ByVal Baz As Long) As String
  Dim x As String
  x = Bar
  Debug.Print CStr(Baz)
  IExamFoo_Foo = Bar
End Function

BadFoo:

'@Folder("Utilities.Example")
Option Compare Database
Option Explicit

Implements IExamFoo


Private Function IExamFoo_Foo(ByVal Bar As String, ByVal Baz As Long) As String
  Debug.Print Bar
  IExamFoo_Foo = Bar
End Function

No Parameter Not Used inspections anywhere.

If I modify GoodFoo:

'@Folder("Utilities.Example")
Option Compare Database
Option Explicit


Implements IExamFoo

Private Function IExamFoo_Foo(ByVal Bar As String, ByVal Baz As Long) As String
'  Dim x As String
'  x = Bar
'  Debug.Print CStr(Baz)
  IExamFoo_Foo = Bar
End Function

Now I get the inspection, but it's on IExamFoo, not on GoodFoo or BadFoo

Now I'm not sure if this is a feature request or a bug report or a bit of both...

Oh, wait, I guess it does make sense. IExamFoo says the parameter is available. GoodFoo uses it - all is right with the world. BadFoo doesn't use it, but we don't care - we can't flag it to be removed because it's used on a different Implementation and flagging it on this Implementation would be meaningless.

I suppose the only value in flagging it in the Implementation that doesn't use it would be if that lack of use were in error. In that case it could be a Hint or Suggestion level, and the @Ignore would be useful to future you that its lack of use is intentional

Guess I'll write it up from that angle

Duga

4:31 PM

[rubberduck-vba/Rubberduck] daFreeMan added label feature-inspections to issue #5856: Add a feature to the ParameterNotUsed inspection.

[rubberduck-vba/Rubberduck] daFreeMan added label enhancement to issue #5856: Add a feature to the ParameterNotUsed inspection.

[rubberduck-vba/Rubberduck] daFreeMan added label up-for-grabs to issue #5856: Add a feature to the ParameterNotUsed inspection.

[rubberduck-vba/Rubberduck] daFreeMan opened issue #5856: Add a feature to the ParameterNotUsed inspection.

[rubberduck-vba/Rubberduck] daFreeMan added label inspection-false-negative to issue #5856: Add a feature to the ParameterNotUsed inspection.

Vogel612

5:57 PM

@this no ... well, in a way. The inspection category is kinda hard-configured and the inspection severity is configurable.

@FreeMan I think that would need to be implemented as a separate inspection. It's a good feature request, though.

FreeMan

@Vogel612 Either way...

Duga

6:27 PM

[rubberduck-vba/Rubberduck] maxwinkler13 added label bug to issue #5857: Splash Screen still shows version 2.5.1

[rubberduck-vba/Rubberduck] maxwinkler13 opened issue #5857: Splash Screen still shows version 2.5.1

Duga

7:37 PM

[rubberduck-vba/Rubberduck] Vogel612 created comment on issue #5857: Splash Screen still shows version 2.5.1

> The version displayed on the splash screen is obtained using `GetType().Assembly.GetName().Version`, the one displayed in the About box is injected via the `IVersionCheck` dependency (that in turn requests a `Version`) which finally resolves to `Assembly.GetExecutingAssembly().GetName().Version`.

The solution is to fix that discrepancy inside the [splash screen control](https://github.com/rubberduck-vba/Rubberduck/blob/8b19e2563a4198702ee7ac4718c3198f53cfe3af/Rubberduck.Core/UI/Splash2021.c

[rubberduck-vba/Rubberduck] Vogel612 added label difficulty-01-duckling to issue #5857: Splash Screen still shows version 2.5.1

[rubberduck-vba/Rubberduck] Vogel612 added label user-interface to issue #5857: Splash Screen still shows version 2.5.1

[rubberduck-vba/Rubberduck] Vogel612 added label up-for-grabs to issue #5857: Splash Screen still shows version 2.5.1

Vogel612

mumble mumble might as well just have fixed it myself, right?

wow, apparently nothing changed since I last pulled the repository on my linux machine...

Vogel612

8:12 PM

sigh... and my Diagnosis was wrong...

@IvenBach yo, just FYI ^^ you need to watch out for some things when updating long-running branches: github.com/rubberduck-vba/Rubberduck/commit/…

Duga

[rubberduck-vba/Rubberduck] Vogel612 created comment on pull request #5749: Consolidate resource cleanup

> CC @retailcoder this MR caused #5857 due to an / some incorrect merging in Rubberduck.Core.csproj

[rubberduck-vba/Rubberduck] Vogel612 pushed commit 7b6cdedd to fix/splash-version

Fix #5857 by partially reverting csproj changes

This reverts changes from adecadf and 440992a that incorrectly
reintroduced a specific AssemblyVersion specification in Rubberduck.Core.csproj

[rubberduck-vba/Rubberduck] Vogel612 created branch fix/splash-version

[rubberduck-vba/Rubberduck] Vogel612 created comment on issue #5857: Splash Screen still shows version 2.5.1

> ~sighs~, it seems I misdiagnosed the issue. Ususually GetType().Assembly and Assembly.GetExecutingAssembly() should return the same object (according to the documentation of the latter), which implies that the issue is actually with the way the assembly version is defined and of course within Rubberduck.Core.csproj the AssemblyVersion property is set to 2.5.1. That change was erroneously introduced in a merge commit updating the branch that was merged in the mentioned PR and snuck thro

> This reverts changes from adecadf and 440992a that incorrectly
reintroduced a specific AssemblyVersion specification in Rubberduck.Core.csproj

[rubberduck-vba/Rubberduck] Vogel612 edited comment on issue #5857: Splash Screen still shows version 2.5.1

> ~sighs, it seems I misdiagnosed the issue. Ususually GetType().Assembly and Assembly.GetExecutingAssembly() should return the same object (according to the documentation of the latter), which implies that the issue is actually with the way the assembly version is defined and of course within Rubberduck.Core.csproj the AssemblyVersion property is set to 2.5.1. That change was erroneously introduced in a merge commit updating the branch that was merged in the mentioned PR and snuck throu

Vogel612

@Duga why would ~sigh~ render as ~~sigh~~

this

8:37 PM

@Vogel612 ~sigh~ is struck through on GH. I imagine Duga converted it to ---sigh--- to be struck through.

Duga

8:47 PM

[rubberduck-vba/Rubberduck] build #5961 for commit 7b6cdedd7d @ 2.5.2.5961 build success

[rubberduck-vba/Rubberduck] build for commit 7b6cdedd on fix/splash-version: AppVeyor build succeeded

Duga

9:13 PM

[rubberduck-vba/Rubberduck] build #5962 for commit 8c4cf45e6f @ 2.5.2.5962 build success

[rubberduck-vba/Rubberduck] build for commit 7b6cdedd on fix/splash-version: AppVeyor build succeeded

Vogel612

10:42 PM

@this nah, she didn't. My gripe is more that ~sigh~ isn't struck through in SE markdown (just like *sigh* is bolded in slack, but italic in SE)

long story short: markdown is inconsistent across different services and I hate it

Duga

[rubberduck-vba/Rubberduck] retailcoder closed issue #5857: Splash Screen still shows version 2.5.1

[rubberduck-vba/Rubberduck] retailcoder pushed 1 commit to next

[rubberduck-vba/Rubberduck] web-flow pushed commit fbfff3cf to next

Merge pull request #5858 from rubberduck-vba/fix/splash-version

Fixes #5857

Mathieu Guindon

Woah, had to log back into GitHub, forever-sleeping browser tab authentication cookie expired!

Thanks @Vogel612!

Vogel612

FWIW I haven't checked any of the other csproj files for something like that

and I made the change from my laptop, so I'm utterly unable to verify whether it works as intended (Can't even get a working build)

Duga

10:58 PM

[rubberduck-vba/Rubberduck] Vogel612 deleted branch fix/splash-version

Duga

11:16 PM

[rubberduck-vba/Rubberduck] rubberduck-vba-releasebot prereleased draft prerelease Prerelease-v2.5.2.5963

[rubberduck-vba/Rubberduck] rubberduck-vba-releasebot created draft prerelease Prerelease-v2.5.2.5963

[rubberduck-vba/Rubberduck] rubberduck-vba-releasebot published prerelease Prerelease-v2.5.2.5963

[rubberduck-vba/Rubberduck] rubberduck-vba-releasebot created tag Prerelease-v2.5.2.5963

[rubberduck-vba/Rubberduck] build #5963 for commit fbfff3cfc9 @ 2.5.2.5963 build success

[rubberduck-vba/Rubberduck] build for commit fbfff3cf on next: AppVeyor build succeeded

Duga

11:47 PM

[rubberduck-vba/Rubberduck] 1417 stars vs. [decalage2/oletools] 1731 stars

Transcript for