VBA Rubberducking - 2016-06-07 (page 1 of 3)

« first day (732 days earlier) ← previous day next day → last day (2448 days later) »

12:00 AM

**IApcLegacyEvents::ClassID Event**
Called by APC during project open to determine the CLSID of the host project item at the specified index.
Before a VBA project is opened, the host application should know the number of host project items and the CLSID of each. Then, during project open, APC calls this method to for each host project item in the VBA project.

HRESULT ClassID(long ProjectItemIndex, BSTR* pbstrClassID);

- ProjectItemIndex [in] A long containing the index of the host project item whose class ID is to be returned.

RELOAD!

[Hosch250/Rubberduck] 55 commits. 38328 additions. 23892 deletions.

[rubberduck-vba/Rubberduck] 9 commits. 10 opened issues. 2 closed issues. 26 issue comments. 792 additions. 338 deletions.

[skiwi2/bit-vector] 1 commit. 160 additions. 10 deletions.

[VSDiagnostics/VSDiagnostics] 1 commit. 1 closed issue. 177 additions. 30 deletions.

[Zomis/FactorioMods] 11 commits. 2 closed issues. 1 issue comment. 97 additions. 87 deletions.

> Before a VBA project is opened, the host application should know the number of host project items as well as the type library information to which each host project item belongs

Okay, ..so can we get a drink at that bar?

oh great, document-types that are defined by multiple type libraries

Well APC is installed on my PC, but IIRC, it's just a wrapper atop DLL functions.

@Mat'sMug Solved it.

public static IEnumerable<Declaration> FindBuiltInEventHandlers(this IEnumerable<Declaration> declarations)

Would you believe it? We are calling that from UserDeclarations in the inspections...

Umm, more bugs...

AppEvents_WorkbookRowsetComplete...

Shouldn't that be Application_WorkbookRowsetComplete?

WorkbookEvents_SheetBeforeRightClick

...

12:24 AM

@Hosch250 app event handlers would be objVariableName_EventName, declared WithEvents

Private WithEvents foo As Excel.Application

Private Sub foo_SomeEvent()

@Hosch250 and that would be Workbook_SheetBeforeRightClick

@Mat'sMug Yeah, but how does our code know that?

@Hosch250 ew! lol

@Hosch250 idk, you're the one looking at it atm :-)

.Select(e => e.ParentDeclaration.IdentifierName + "_" + e.IdentifierName)

Before, we just did that.

Works for user code

Not any more it doesn't.

That gives us WorkbookEvents_SheetBeforeRightClick.

12:32 AM

Strip "Events" for built-in ones then

WorkbookEvents has Workbook as a subtype.

@Mat'sMug That won't cut it.

The Worksheet ones are DocEvents.

@Mat'sMug @Comintern I think I know how to solve this.

@ThunderFrame - Who is calling the HRESULT ClassID(long ProjectItemIndex, BSTR* pbstrClassID); ? The VBE or the host application?

WorkbookEvents points to Workbook as a subtype.

@Hosch250 Only variables declared as WithEvents can have the events, and varname + "_" + EventName is an event handler, but varName + "_" + RandomString is just a procedure.

@Hosch250 cool! Use that! :-)

12:36 AM

@Hosch250 - Now that you mention it, it would almost have to. What good is an event if you can't get a typed reference to the caller?

@ThunderFrame yeah but built-in ones... we don't create a fake WithEvents fields for them

@Comintern IKR

@Comintern My question is, will these always only have one subtype, which is the coclass name?

If that is the case, I can fix this inside of 10 seconds.

yes, document-components, ActiveX controls and WithEvents vars.

I'm trying to think of a counter example.

If we're lucky.. it's worth a shot imo

ActiveX controls are out of the equation for now

12:38 AM

OK, I'll do that. It will be better than what we have, at any rate.

As are Ribbon callbacks

Even if there are multiples, wouldn't the CoClass furthest down the inheritance hierarchy still have to be in the subtypes?

@Comintern yeah but then how do you tell which one is the coclass?

Well, we're already collecting those. Just cross-check against the implemented interfaces.

We'd have to store some kind of flag along with the type name

12:41 AM

MdcListEvents doesn't have the subtype.

Meh.. call it an edge case

I don't even know what that is lol

Something that user forms brings in.

Aren't those Listview handlers?

OK, so don't we collect all of the implemented interfaces in the CoClasses?

btw @ThunderFrame:

user image

so it has to be enable all macros right?

Ugh. It has ListBox and ListBox2.

OK, so I just iterate all subtypes and add them.

12:46 AM

I guess that would work

Worst case scenario, I get things like ListBox2_Click...

wait a sec

those are controls?

isn't that already handled??

VS feature request... Holding ESC for 5 seconds force-cancels the debug session.

@Mat'sMug No...

the Stop button tends to do that...

None of the events stuff has been working since I got things being picked up as events.

@Mat'sMug Unless VS locks up due to some threading issue and you can't click the Stop button.

12:48 AM

@Hosch250 form controls' event handlers will be [ControlName_EventName]

RD has huge problem when that when debugging in the inspections.

hence the need to pick up controls as Declaration items, so we can rename the handlers when a button is renamed

Oh, right.

user image

@Mat'sMug - I thought you were done with the localization?

12:52 AM

user image

the assert message comes from the user code :)

hmm "Test Explorer" shouldn't be saying "Test Explorer" in French...

@Mat'sMug The titles don't update when the language is changed.

Ah, so it isn't coming from:

It should be fixed if you reboot RD.

nope

OnAssertFailed.

12:55 AM

"Fail assertion failed" should be translated, indeed... good eye!

@Mat'sMug How should I handle the ListBox_KeyUp events it is giving me?

How do I know that those ones can't be seen by the user code?

[ControlName]_KeyUp

@Mat'sMug Nope.

because nobody subclasses a ListBox in VBA

UserForm_KeyUp is a real thing.

12:58 AM

yes, but not ListBox

Well, how do I know what a control is?

I'd say if it's not a UserForm, and it's coming from the UserForm library, it's a control.

They don't? mrexcel.com/forum/excel-questions/401364-tooltips-listbox.html

gah, of course someone did

I've done that before. Not for tooltips - for custom text colors.

1:00 AM

Isn't there any cleaner way of doing this?

Will it hurt anything if I leave it like this?

wait a sec

Private WithEvents Lbx_events As MSForms.ListBox

Private Sub Lbx_events_MouseMove _
(ByVal Button As Integer, ByVal Shift As Integer, _
ByVal x As Single, ByVal y As Single)

that's still ControlOrFieldName_EventName

and it had to come from a poster named "Jafaar". Obviously an evil wizard.

4

lol

Eh, I'll PR my changes.

It is a wee bit better than before, even if it has this.

Then, TTQW.

Also, this is definitely broken:

var handlers = declarationList.Where(declaration => !declaration.IsBuiltIn
                                         && declaration.DeclarationType == DeclarationType.Procedure
                                         && handlerNames.Contains(declaration.IdentifierName)).ToList();

It returns any procedure in the list of names, regardless of scope.

RD 2.0 is so buggy it is depressing.

Every time I splat a bug, two more get reported.

[Hosch250/Rubberduck] Hosch250 pushed commit a2a3ad0b to InspectionBugs: Fix built-in event discovery

Based on the weekend stats, they are getting reported at the rate of 5 a day.

1:07 AM

@Hosch250 legacy of 1.x

We held it around 255 all last week, then bam, up to 265 by Monday morning.

Half of them are the same damn issue though.

^

Yeah.

dupe-close hammer anyone?

1:08 AM

@Mat'sMug I just dupe-closed a bunch last week about the Project one.

Which one is it now?

[rubberduck-vba/Rubberduck] Hosch250 created pull request #1721: Fix built-in event discovery to merge Hosch250/Rubberduck/InspectionBugs into rubberduck-vba/Rubberduck/next

TTQW.

thanks for all the hard work @Hosch250

Wot TeamViewer session @Mat'sMug

aye. I promised Hosch he'd be making a release build in his internship

1:11 AM

Agreed 👍🏻 you did real good @Hosch250 wear this progress and achievement with pride

besides, we have fewer bugs than yesterday, and more than tomorrow

5

[rubberduck-vba/Rubberduck] build for commit a2a3ad0b on unknown branch: AppVeyor build failed

BUILD FAILURE!

@Mat'sMug Notifications for all Macros is fine, and is more secure. User just needs to remember to click Enable, as they open Outlook.

ah cool

I'd dup close everything that mentions a COM error on shutdown as a duplicate of #1438. That would include #1710, #1633. #1704 and #1719 are probably also duplicate of that one.

1:20 AM

thanks

Gee I love that PowerPoint problem I tweeted yesterday. Accessing the object.Name getter throws an error sometimes, other times deletes the object.

(when it's an error, the error is that it couldn't delete the object)

love the WTF reaction too :)

lol

lol

1:33 AM

interesting. I just noticed I had Excel macro security settings set to the "run all" setting

...setting it to anything else stalls unit testing

did you restart Excel?

yes

(as in Rubberduck restart Excel - kill it in Task Manager)

oh wow, got 2 processes running

^ That's a tiny bug

1:35 AM

RD Restart? Ouch.

@Comintern I suppose proper teardown is going to help with that :)

and nope, no luck. can anyone get unit tests to run in Excel without allowing "all macros" to run?

I would doubt it.

On the "all macros" thing, not the teardown thing.

it should be handled more... well, gracefully. currently stalls the test explorer with a "busy" indicator that just remains there no matter what

Allowing Application.Run to access macros would allow attacks from things like VBScript.

Or basically anything that can call CreateObject.

duck-attack

1:38 AM

Woot!

so, I'm going to document that macro security must be at the least restrictive setting for unit tests to work.

I'm quite surprised this hasn't been brought up by anyone using RD 1.x

or, well, everybody is running Excel at the lowest macro security setting apparently

codereview.stackexchange.com/questions/tagged/quack-attack

hmm - IDK how to make the tag

[tag:tag-name]

There may be a workaround for that if #811 can be closed.

[tag:D'Oh]

1:42 AM

no punctuation allowed ;-)

@ThunderFrame didn't you have to fix #811 to get CorelDRAW to work?

d'oh

8 questions tagged d. None tagged oh.

> In order to get CorelDraw working, this PR also addresses:
#1020
#811

[rubberduck-vba/Rubberduck] retailcoder closed issue #811: Multiple opened instances of the host app break unit testing

I'll take a look later. I have a meeting coming up. But IIRC, there was some code that got the application from the document-type component. That's why the HostApp is overloaded with a vbe argument.

1:46 AM

Hmmm.... does that always return the Application that the VBE is running in?

it should

it returns the comp.Properties("Application").Object

that would do it :)

but as per my statement above, from the SDK, apparently some projects allow for documents from multiple type libraries

I thought that was implemented at some point. Did we pull it out?

I might have to look into setting RD's privilege level to the same level as the logged in user then. That should allow you to do anything you could do via the host.

1:49 AM

@Mat'sMug what was the PR that you referenced for closing 811?

Have you tried it with a release build?

It might not work through the vshost process.

hmm

github.com/rubberduck-vba/Rubberduck/pull/964

^ #964

(beat me to it!)

@Hosch250 not going to merge #1721 right away, a handful of tests are broken

@Mat'sMug Bother.

user image

Lots of others.

2:05 AM

@Comintern I'm running the last build without VS opened... should I make a release build to check? ...making a release build without releasing it would be... ...itching...

I'm not sure if that opens a vshost or not - never done that before with a debug build.

[retailcoder/Rubberduck] ThunderFrame pushed commit e24e5516 to next: Fixes #1711 to run module-specific test methods, for each module

[retailcoder/Rubberduck] retailcoder pushed commit f39821b1 to next

Merge pull request #1714 from ThunderFrame/next

Fixes #1711 to run module-specific test methods, for each module

[retailcoder/Rubberduck] Hosch250 pushed commit c4aea624 to next: Close #1712

[retailcoder/Rubberduck] retailcoder pushed commit aeb361d3 to next

Merge pull request #1715 from Hosch250/Issue1712

Fix Implicit Variant Function Return Type

[retailcoder/Rubberduck] Hosch250 pushed commit 3f7c3cd7 to next: Correctly check param-not-used for events and library procedures/functions

[retailcoder/Rubberduck] Hosch250 pushed commit e09a0735 to next: Fix a couple inspections

[retailcoder/Rubberduck] Hosch250 pushed commit 47ca5446 to next: Fix a few more inspections

[retailcoder/Rubberduck] Hosch250 pushed commit f32c4994 to next: Add a few tests

[retailcoder/Rubberduck] retailcoder pushed commit 7123cac1 to next

Merge pull request #1720 from Hosch250/InspectionBugs

Inspection bugs

[retailcoder/Rubberduck] retailcoder pushed commit 72035d2a to next

Merge pull request #120 from rubberduck-vba/next

sync with main repo

hmm, I think there's a bug with 2 projects having common testmodule and test method names. RD should pick up/run tests across all projects?

2:37 AM

Oh wow. @Mat'sMug I just got that hanging Test Explorer after I had tried to run tests. I went and wrote an email and 20 minutes later came back to Excel. I'd forgotten about the hung test run, so I added a module to each of my open workbooks, and then I noticed a reparse and my debug statements populating the Immediate window... The tests had eventually run, and the Test Explorer unhung itself.

2:55 AM

Took THAT long to unhung? @ThunderFrame

reparsing didn't cut it for me here

user image

not quite right :-/

And if I refresh, the folders are collapsed.

3:34 AM

@ThunderFrame :(

We rely too much on names here, I think.

But wait, that isn't how it is here.

It opens two projects with the same folder names just fine here...

[rubberduck-vba/Rubberduck] ThunderFrame opened issue #1722: Workbook created via SaveAs ends up with HelpFile/ProjectID collision, causes parse problems

> I have 2 workbooks. The 2nd was created by doing a SaveAs from the first. I notice that TextChecker1 has HelpFile value **29288625** and TestChecker2 has helpfile value **29288625**

*So much for one-in-a-million chance*

I start a fresh copy of Excel 2016 32-bit and open TestChecker1, followed by TestChecker2. Only then do I open the VBE.

Rubberduck parses, and Code Explorer shows me:
![Imgur](http://i.imgur.com/Jo0FFID.png)

Notice the absence of TestChecker2, so I close TestChecke

@Hosch250 ^ That is the problem.

@ThunderFrame What is?

It keeps them separate and everything, just like it should.

@Hosch250 Issue 1722

I don't know how you are getting that.

3:44 AM

> The 2nd was created by doing a SaveAs from the first.... And then open them both in a fresh copy of Excel

Ohh...

We need to explicitly check for a collision, then hash the hash, or something.

[rubberduck-vba/Rubberduck] ThunderFrame edited issue #1722: Workbook created via SaveAs ends up with HelpFile/ProjectID collision, causes parse problems

3:59 AM

@Mat'sMug Those failing tests are because we can't load the libraries in the tests.

Or at least, the Win32 method we call, or whatever it is, returns null.

Would it be OK if I just delete those tests?

@ThunderFrame Are you around?

hi

I have a potential fix for 1722, but I want you to try it before I take it any further.

RubberduckParserState, line 86:

if (string.IsNullOrEmpty(project.HelpFile) || _projects.Any(a => a.Value().HelpFile == project.HelpFile))

Please see if that fixes it.

Because the projects are two different instances, they should return two unique hashcodes--especially since the name is different.

OK, 2 secs. Boss asking for something too :-/

OK.

I always forget it isn't 11:08 PM for you too, or whatever my local time is.

Actually, no.

That has the potential for a second collision, however, slight.

This way will fix it--or die trying :P

while (string.IsNullOrEmpty(project.HelpFile) || _projects.Any(a => a.Value().HelpFile == project.HelpFile))
{
    project.HelpFile = (project.GetHashCode() ^ project.HelpFile.GetHashCode()).ToString();
}

OK

4:10 AM

Odds are probably greater than 90 : 1 that that will never execute twice...

Slight edit, get the updated version.

in my workplace, lots of people open a read-only workbook, and save it with a timestamp on a daily basis. IF the template ever opens with write access, Rubberduck would place a projectID in the file that would be copied to all new derivations.

Ouch.

Why re-save a readonly workbook?

Well, we can't do anything about a readonly workbook, AFAIK.

so they have an audit trail of the work they did on any given day.

That fix will change the ID to prevent a hash collision, but that's it. If we can't prevent a hash collision because of readonly...

And while we are at it, we might as well do it right:

while (string.IsNullOrEmpty(project.HelpFile) || _projects.Any(a => a.Key == project.HelpFile))
{
    project.HelpFile = (project.GetHashCode() ^ project.HelpFile.GetHashCode()).ToString();
}

Well under Office, opening the file read-only doesn't mean the document or the object model isn't read-only, it just means you can't inadvertently save over the top of the file you opened. That is, you can't inadvertently change the template.

ie. They open Orders.xlsm as read-only, make changes and then SaveAs Orders20160607.xlsm

4:23 AM

Oh.

Well, maybe this will work.

Night.

night

I'll go with mark3, then...

4:58 AM

@Mat'sMug Macro security isn't required for Rubberduck. The only requirement is that the VBA projects be opened with Macros enabled. IF a user has projects that are defined in Trust Center as Trusted Files, or the files are in Trusted Locations, then the files will open with Macros enabled.

If the user opens a document from an untrusted location, the only way the macros will be enabled is if the user is prompted, on open, to enable macros. That prompt will only appear if the user has the appropriate Security Settings.

IF you're adding code to a new workbook, then you won't be prompted to enable Macros.

5:14 AM

[rubberduck-vba/Rubberduck] ThunderFrame created pull request #1723: Careful assignment of ProjectID - Avoids project collisions to merge ThunderFrame/Rubberduck/next into rubberduck-vba/Rubberduck/next

> All @Hosch250's work

I did get some problems trying to execute tests across both projects, but I suspect that's another issue.

[rubberduck-vba/Rubberduck] build for commit 8d9bc9df on unknown branch: AppVeyor build failed

BUILD FAILURE!

1 hour later…

6:21 AM

WTF @Duga?

6:47 AM

[rubberduck-vba/Rubberduck] ThunderFrame commented on pull request #1723: Careful assignment of ProjectID - Avoids project collisions

> Closes #1722

1 hour later…

7:57 AM

@Mat'sMug My Excel Macro settings are Disable all macros with notification and I have Trust access to the VBA project object model checked... I do have to enable macros each time a workbook opens, unless I'm opening it from a Trusted Location.

2 hours later…

9:38 AM

ooh, nice:

user image

Excel went down in a ball of flames

have killed Excel in Task Manager, and still can't get back to the VBE without an exception.

I suspect I corrupted the settings file?

hmm - actually I think it's @Hosch250's change in my PR

ducks

2

@Mat'sMug don't merge my PR

10:20 AM

[rubberduck-vba/Rubberduck] ThunderFrame synchronized pull request #1723: Careful assignment of ProjectID - Avoids project collisions

It's all OK again. Merge away.

[rubberduck-vba/Rubberduck] build for commit f4964ac4 on unknown branch: AppVeyor build succeeded

2 hours later…

12:04 PM

[rubberduck-vba/Rubberduck] retailcoder merged pull request #1723: Careful assignment of ProjectID - Avoids project collisions from ThunderFrame/Rubberduck/next into rubberduck-vba/Rubberduck/next

[rubberduck-vba/Rubberduck] ThunderFrame pushed commit 70a49e9c to next

Careful assignment of ProjectID - Avoids project collisions

All @Hosch250's work

[rubberduck-vba/Rubberduck] ThunderFrame pushed commit 8d9bc9df to next: Removes old ProjectID check

[rubberduck-vba/Rubberduck] ThunderFrame pushed commit f4964ac4 to next

ensures a helpfile is assigned *before* ensuring it is unique

Fixes NRE bug introduced by prior commit, that prevented new projects
from parsing.

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

Merge pull request #1723 from ThunderFrame/next

Careful assignment of ProjectID - Avoids project collisions

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

1 hour later…

Non-coding Duck

1:31 PM

The Codeless Code: Case 230: All Together Now

posted on June 06, 2016

The Hungry Worm Clan was building a website for a craftsman who made custom farming tools. Young master Zjing was reviewing the code of their three developers. “I do not understand the purpose of the LatestSellByDate property in your shopping cart’s PurchaseItem,” she said to the three. “Shovels and rakes do not expire.” “That property was requested by the Red Pebble Clan,” replied the firs…

2 hours later…

3:09 PM

@Non-codingDuck I'm not sure whether to day Good Riddance or Bad Teaching.

[rubberduck-vba/Rubberduck] Hosch250 closed issue #1722: Workbook created via SaveAs ends up with HelpFile/ProjectID collision, causes parse problems

[rubberduck-vba/Rubberduck] Hosch250 assigned Hosch250 to issue #1722: Workbook created via SaveAs ends up with HelpFile/ProjectID collision, causes parse problems

[rubberduck-vba/Rubberduck] Hosch250 added label bug to issue #1722: Workbook created via SaveAs ends up with HelpFile/ProjectID collision, causes parse problems

@Mat'sMug How do you want me to handle those failing tests?

kill 'em all

[rubberduck-vba/Rubberduck] Hosch250 added label code-explorer to issue #1722: Workbook created via SaveAs ends up with HelpFile/ProjectID collision, causes parse problems

OK.

3:14 PM

[Hosch250/Rubberduck] Hosch250 created branch KillFailingTests

[Hosch250/Rubberduck] retailcoder pushed commit aeb361d3 to KillFailingTests

Merge pull request #1715 from Hosch250/Issue1712

Fix Implicit Variant Function Return Type

[Hosch250/Rubberduck] retailcoder pushed commit 7123cac1 to KillFailingTests

Merge pull request #1720 from Hosch250/InspectionBugs

Inspection bugs

[Hosch250/Rubberduck] Hosch250 pushed commit 961719ff to KillFailingTests: Remove tests requiring us to load an external library

Whoops...

2

[rubberduck-vba/Rubberduck] Hosch250 created pull request #1724: Remove tests requiring us to load an external library to merge Hosch250/Rubberduck/KillFailingTests into rubberduck-vba/Rubberduck/next

[rubberduck-vba/Rubberduck] Hosch250 rejected pull request #1724: Remove tests requiring us to load an external library

?

[rubberduck-vba/Rubberduck] build for commit 961719ff on unknown branch: AppVeyor build cancelled

BUILD FAILURE!

[rubberduck-vba/Rubberduck] Hosch250 synchronized pull request #1721: Fix built-in event discovery

[Hosch250/Rubberduck] Hosch250 pushed 4 commits to InspectionBugs

[Hosch250/Rubberduck] Hosch250 pushed commit c43884f0 to InspectionBugs: Merge branch 'KillFailingTests'

[rubberduck-vba/Rubberduck] build for commit c43884f0 on unknown branch: AppVeyor was unable to build non-mergeable pull request

BUILD FAILURE!

@Mat'sMug Needed to update the old PR.

3:18 PM

[rubberduck-vba/Rubberduck] Hosch250 synchronized pull request #1721: Fix built-in event discovery

[Hosch250/Rubberduck] ThunderFrame pushed commit 70a49e9c to InspectionBugs

Careful assignment of ProjectID - Avoids project collisions

All @Hosch250's work

[Hosch250/Rubberduck] ThunderFrame pushed commit 8d9bc9df to InspectionBugs: Removes old ProjectID check

[Hosch250/Rubberduck] ThunderFrame pushed commit f4964ac4 to InspectionBugs

ensures a helpfile is assigned *before* ensuring it is unique

Fixes NRE bug introduced by prior commit, that prevented new projects
from parsing.

[Hosch250/Rubberduck] retailcoder pushed commit 88cb6c20 to InspectionBugs

Merge pull request #1723 from ThunderFrame/next

Careful assignment of ProjectID - Avoids project collisions

[Hosch250/Rubberduck] Hosch250 pushed commit be9c7b41 to InspectionBugs: Merge branch 'next' of github.com/rubberduck-vba/Rubberduck into InspectionBugs

[rubberduck-vba/Rubberduck] build for commit be9c7b41 on unknown branch: AppVeyor was unable to build non-mergeable pull request

BUILD FAILURE!

@Duga What's all this BS about?

I just pulled Next, so there are not conflicts.

3:50 PM

[Hosch250/Rubberduck] Hosch250 created branch Issue1506

[Hosch250/Rubberduck] Hosch250 pushed commit e9e55460 to Issue1506: Close #1506

[rubberduck-vba/Rubberduck] Hosch250 created pull request #1725: Fix renaming project bugs to merge Hosch250/Rubberduck/Issue1506 into rubberduck-vba/Rubberduck/next

@Duga Forgot to run the tests. Hope they work.

[rubberduck-vba/Rubberduck] build for commit e9e55460 on unknown branch: AppVeyor build succeeded

what's up with #1721?

No idea.

try syncing it

3:58 PM

I'm doing some generic clean-up in that branch to trigger a reparse.

It is 100% synced both ways--I can't sync it anymore.

« first day (732 days earlier) ← previous day next day → last day (2448 days later) »

Transcript for

Jun '167

VBA Rubberducking

This chat has moved to Discord: discord.gg/MYX9RECenJ

antlr com-interop parsing rubberduck vb6 vba whiskey-tango-foxtrot

join this room
about this room

00:00

06:00

12:00

18:00

all times are UTC

site design / logo © 2024 Stack Exchange Inc; legal

mobile