False error on properties: "Error: Object variable is assigned without the 'Set' keyword"

[BCVolkert]

Rubberduck version information Version 2.5.2.5906 OS: Microsoft Windows NT 10.0.19043.0, x64 Host Product: Microsoft Office x86 Host Version: 16.0.14026.20308 Host Executable: WINWORD.EXE

Description With:

        Option Explicit
        Sub Test()
        Dim lPTitleFontColor As OLE_COLOR
        lPTitleFontColor = &HA00000
        Debug.Print lPTitleFontColor
        End Sub

Rubber Duck > Code Inspections yields: "Object variable 'lPTitleFontColor' is assigned without the 'Set' keyword."

With:

        Option Explicit
        Sub Test()
        Dim lPTitleFontColor As OLE_COLOR
        Set lPTitleFontColor = &HA00000
        Debug.Print lPTitleFontColor
        End Sub

O365 Debug > Compile Project fails with "Compile Error: Object required".

This happens on all of the variables in my real project declared to be OLE_COLOR

To Reproduce Steps to reproduce the behavior:

1. Compile

       Option Explicit
       Sub Test()
       Dim lPTitleFontColor As OLE_COLOR
       lPTitleFontColor = &HA00000
       End Sub

2. Rubberduck > Code Inspections flags an error = "Object variable 'lPTitleFontColor' is assigned without the 'Set' keyword."
3. Compile

       Option Explicit
       Sub Test()
       Dim lPTitleFontColor As OLE_COLOR
       lPTitleFontColor = &HA00000
       End Sub

4. O365 VBE will not compile the statement.

Expected behavior RubberDuck should accept that "Set" is not required when the data type is OLE_Color. I suspect that there are similar cases for other data types; but, that is getting outside my limited circle of competence.

Screenshots Attached

Logfile No Logfile was present in %APPDATA%\Rubberduck\Logs

Additional context Nothing special. I was able to reproduce the error with the code described above.

I also tried Code Inspections > Fix > Selected Occurrence. That produced "lPTitleFontColor Set = &HA00000" which is a syntax error. Not a big deal; but, something that may be a clue for you.

[Vogel612]

For completeness sake: Can you reproduce the issue when assigning one of the named colors like vbRed as the value?

The fix resulting in broken code is somewhat critical, especially since the way it fails suggests a deeper issue with rewriting than I'd like.

[retailcoder]

Curious what the RD commandbar says OLE_Color is. If it says (Enum) (it's an enum, yeah?) then something weird is going on, because while Enum and Type members have tripped us before (they're easy to forget), I'm pretty sure the resolver has them properly covered by now. Maybe the inspection is trying to do the resolver's job by filtering intrinsic data type names (leaving out enums and UDTs)? If the RD commandbar says OLE_Color is an object type, then the bug likely isn't in the inspection but the COM library collector - in that case it could also be the OLE library defining the type in a way we're not correctly picking up.

The quick-fix bug is somewhat related, but really its own separate thing (that's indeed critical, since "fixing" code usually shouldn't result in uncompilable code).

[BCVolkert]

I get the same behavior with vbRed.

You guys are quick! !

[MDoerner]

I think OLE_COLOR is a bit special and a hack in the VBE. It cannot be found in the object explorer, but still appears in autocompletion. It essentially seems to be an alias for Long that leads to a different behaviour of the VBE's properties window.

I guess our best bet here is to add a custom enum definition in the VBA library for this 'enum'. (Although you can use the values from the ColorConstants enum, e.g. vbRed, OLE_COLOR is not restricted to named members.)

[BCVolkert]

CommandBar without Set: "variable:OLE_COLOR" CommandBar with Set: "variable:OLE_COLOR" OLE_COLOR is "stdole2.tlb;OLE_COLOR(alias:Variant)"

Summary: Same information with and without.

If this is not what you wanted to know, provide a hint and I'll try again.

Thanks for your interest. Bruce

[BCVolkert]

I'm sure you guys are on top of it; but, this may provide some help. https://docs.microsoft.com/en-us/openspecs/office_file_formats/ms-oforms/4b8f4be0-3fff-4e42-9fc1-b9fd00251e8e

I found it to be a bit weird too. To be honest it's in a chunk of code from the internet that I've been using for a DatePicker in Excel and would like to clean up. The simple variation I provided produces the same behavior as the original source.