I wanted to bring one of my favorite #cartoons to life, so here's Wile E. Coyote continuing his quest to catch the Roadrunner in AR.
#LooneyTunes #madewithunity #ARKit https://t.co/juh3u0UuDw
@HackSlash inspections are basically just queries against the parser state, and/or parse tree traversals; the simplest inspections simply query/filter declarations, and the more complex ones involve walking parse trees, evaluating expressions, and whatever they need to do.
The hard part is coming up with a way to make that easy to do
ParseTreeInspection inspections are the ones involving a "listener"; the inspector initiates a traversal of each module's parse tree, and all inspections "listen in" for specific nodes being hit, and act accordingly
> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/3975?src=pr&el=h1) Report > Merging [#3975](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/3975?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/67c765707768cc330d9ed1202de38f7e7af9aea5?src=pr&el=desc) will **decrease** coverage by `0.07%`. > The diff coverage is `15.09%`.
> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/3975?src=pr&el=h1) Report > Merging [#3975](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/3975?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/67c765707768cc330d9ed1202de38f7e7af9aea5?src=pr&el=desc) will **decrease** coverage by `0.07%`. > The diff coverage is `15.09%`.
> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/3975?src=pr&el=h1) Report > Merging [#3975](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/3975?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/67c765707768cc330d9ed1202de38f7e7af9aea5?src=pr&el=desc) will **decrease** coverage by `0.05%`. > The diff coverage is `12.7%`.
does any one know why the Tools -> References doesn't always list all available DLLs? (the library is registered and works but one must browse to the TLB file manually and only then it will show up in the list of the references)
@this it comes down to client support. most clients will be fine with providing a dual implementation.
but for something like vbDotNetLoader, it's much harder to generate vtables at runtime, with the appropriate function stubs etc, so vbDotNetLoader simply doesn't support vtable binding, and so dual source interfaces aren't compatible with it.
@this is it registered in HKLM? IIRC the references dialog list only looks at HKLM not HKCU
@DainIronfootIII: How would we track that? Easilly I think? You have a way to save information about something even when RD is closed (settings and so on) so when someone writes TODO and it will firstly appear, after refreshing, on TODO Explorer, it would write a datetime for that time. When refreshed again, it could compare the string with existing and if it's the same, the datetime will stay. If it's modified, it would write the newer one? I don't know how exactly the TODO works. But if it's not persistent (no ToDo when RD is firstly run) what about saving somewhere the String or Hash (fo…
> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/3975?src=pr&el=h1) Report > Merging [#3975](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/3975?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/85d75346282060886013aad30c4a93b5b304b8f5?src=pr&el=desc) will **decrease** coverage by `0.07%`. > The diff coverage is `0%`.
> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/3975?src=pr&el=h1) Report > Merging [#3975](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/3975?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/85d75346282060886013aad30c4a93b5b304b8f5?src=pr&el=desc) will **decrease** coverage by `0.07%`. > The diff coverage is `0%`.
@this Simple explanation: you moved the RootComWrapperFactory into that folder, which caused the folder coverage to drop because the file has less coverage than the previous folder coverage.
> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/3975?src=pr&el=h1) Report > Merging [#3975](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/3975?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/85d75346282060886013aad30c4a93b5b304b8f5?src=pr&el=desc) will **decrease** coverage by `0.07%`. > The diff coverage is `0%`.
> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/3975?src=pr&el=h1) Report > Merging [#3975](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/3975?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/85d75346282060886013aad30c4a93b5b304b8f5?src=pr&el=desc) will **decrease** coverage by `0.07%`. > The diff coverage is `0%`.
@DainIronfootIII So maaaaaaybe in a long future :-) But the thing with line or the same text is true... I forgot about that :-) Thanks for the reaction though.
> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/3975?src=pr&el=h1) Report > Merging [#3975](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/3975?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/85d75346282060886013aad30c4a93b5b304b8f5?src=pr&el=desc) will **decrease** coverage by `0.07%`. > The diff coverage is `0%`.
> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/3975?src=pr&el=h1) Report > Merging [#3975](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/3975?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/85d75346282060886013aad30c4a93b5b304b8f5?src=pr&el=desc) will **decrease** coverage by `0.07%`. > The diff coverage is `0%`.
> Same as you. Okay, I didn't know about this. But that shouldn't remove the blank line if there is a single one, doesn't it? I think.
So. When I tried Vertial Spacing = 2, here's what happens. From 2 blank lines it will remove the first one. On another run it will remove the second. As it is on video. BUT when I try it for the third time, it will create not 1 blank line but 2.
@Duga @mansellan / @MathieuGuindon just throwing it out -- if it doesn't feel justified to create separate implementations, it might be that Export is the wrong concept here? In this context, we are really interested in getting the attributes for the parse pass, after all.
that's the thing: it kinda does feel justified. The AttributesRewriter was written with a specific implementation of IVBE in mind, which means to adhere to OCP a new implementation should be written, against another IVBE implementation
the hairy reality view may barge in and say "can't do that cos that blows up VB6 so you gonna export temp anyway! You and your puny theories & principles! MWAHAHA!"
This discussion makes clear to me that there are circumstances where one shouldn't try to decouple but rather make the coupling (where it is required) explicit.
See, that's what I'm getting at. We would prefer to not have to write implementation for everything so if we can have IDataTable use some generic implementation that's always workable for various database engines but if there are implementation details that leaks through, then we must provide provider-specific implementation for IDataTable..... right?
@this currently we have VBA.Export to export and VBA.SaveAs doesn't exist. then we have VB6.Export doing nothing and VB6.SaveAs doing what Export would do. the suggestion is to remove Export and move it to SaveAs, so VBA.SaveAs exports and VB6.SaveAs does what it does, and there's no need for an Export method anymore, and everyone has an implementation for SaveAs
really I think this can be done w/o AvalonEdit. It's simply that it shouldn't be a "quickfix" but more like we should always push the rewritten file with our injected stuff
not sure. in any case in order to bring the attributes into our avalon code panes we'll have to parse the "attributes pass" tokens anyway, so really it's the "code pane pass" that'll have to go
@WaynePhillipsEA can you confirm if type library will in fact expose all attributes? Or are there some exceptions (perhaps some VB specific attributes)?
yes, in the end, code pass pane should not needed. ATtributes should be the Gospel.
but it's useless to implement a @DefaultMember annotation if we're going to end up with VB_Attribute UserMemId = 0 visible in the code panes anyway, no?
I'd rather right-click the procedure and pick "Make this the class' default member" in some hypothetical Rubbereduck > Member Attributes menu, and have RD add the corresponding attribute values
hi. ITypeLib doesn't expose everything. it exposes everything important from a COM perspective. One attribute that comes to mind is VB_ProcData. That's not accessible from ITypeLib, as it is an internal VB thing
(it's really annoying they didn't really bother documenting all VB attributes. At least I never found a real comprehensive list; all other source I found are basically guessing basing on observations)
Yeah makes sense. VB is bigger than just COM. For those attributes, I think we just need to basically ignore (but preserve) while using typelib API for checking the more important attributes.
basically, most attributes you should find directly in the ITypeInfo. For anything else, we can probably find one of the undocumented members of the TypeLib API to access it.
@MathieuGuindon IDK if we parse it properly but if we do, then sure. It's only an implementation away.
@WaynePhillipsEA given that we'd have to read the source file w/ attributes, seems safer to use that as the source than trying to use undocumented method. We can stick to the documented stuff for comparing the state to handle cases where users may have accidentally blown away the customized attributes. (without having to re-export to find out)
our parser is probably picking it up as a member attribute named VB_ProcData.VB_InvokeFunc with a value of "A\n14", and then we're not doing anything with it
worst-case we've got a bit of cleanup to do... eventually
in the mean time I think it's good-enough; as I said breaking OCP here isn't much of a problem anyway, unless we're planning to extend support to yet-unknown IVBE implementations
@MathieuGuindon In C#, can you catch an exception and throw another exception with the previous exception included as the "root cause" for the new exception? If so, is that common practice?
@this that's not quite the same I think - that relates to the project output. 2000 and XP office had developer editions that could compile standalones for COM add-ins etc
I don't think by that much. The real failure is with them consistently failing to provide a meaningful migration path that didn't involve scrapping everything and starting all over.
you are right. It compiles but gives unexpected results. Exports the sheets in my tool not the workbook containing 50 sheets. I am unable to install your plugin because of restrictions placed by company on installations. — Majid5 mins ago
@Majid FYI if it's any relevant or helpful, the installer doesn't require administrator privileges and can install per-user. Don't install it under-the-radar against company policies, but know that if the restrictions are about admin privs then v2.2 (latest, and subsequent 2.2.x pre-release builds) can be installed without worrying about that. — Mathieu Guindon10 secs ago
I also would think it'd make for a maintenance nightmare. The more you lock down things, the greater the IT burden becomes, and you just end up with a shadow IT.
VBA Rubberducking
VBA Rubberducking