« first day (2262 days earlier)      last day (35 days later) » 

12:01 AM
[rubberduck-vba/Rubberduck] 2 opened issues. 12 issue comments.
[Zomis/FactorioMods] 3 commits. 1 opened issue. 1 closed issue. 4 issue comments. 8 additions. 1 deletion.
[Minesweeper] Games Played: 156, Bombs Used: 80, Moves Performed: 22316, New Users: 9
3 hours later…
2:44 AM
for anyone who is wondering, I finally got a definitive answer to a discussion we had long ago on here --- if a COM object implements only the IUnknown, then it cannot be assigned in VBA to an Object. Such COM object absolutely requires a type library. It can be assigned to an IUnknown variable but it's basically useless because you can't invoke any of the object's methods as a IUnknown.
1 hour later…
3:45 AM
> Code is updated per the comments. Retained the IModuleRewriterExtensions class rather than modify IModuleRewriter.
7 hours later…
10:40 AM
Q: Similarity between words

Davide ToninI'm writing a method that writes the code for a loading routine. Given an object from the database, I want to put its properties in the right control on a userform. I have the list of the properties and I have the names of the controls. For each property, I want my code to search in the controls'...

1 hour later…
12:01 PM
@MathieuGuindon Do you want to include #5555 in the release as well? If yes, have a look and merge if OK.
2 hours later…
1:46 PM
[rubberduck-vba/Rubberduck] BZngr pushed commit 92388aa1 to next: Merge remote-tracking branch 'refs/remotes/rubberduck-vba/next' into next
[rubberduck-vba/Rubberduck] BZngr pushed commit 053fbf02 to next: Merge branch 'rubberduck-vba/next' into next
[rubberduck-vba/Rubberduck] BZngr pushed commit 723bbaca to next: Merge branch 'rubberduck-vba/next' into next
Add declaration and newline removal methods

Extends the IModuleRewriter.Remove() method to clear residual blank
lines between the removed declaration and the next declaration.
Supports VariableDeclarations and ModuleBodyElementDeclarations
removals. Also improves Variable declaration list handling.
Remove blank lines left by declaration removals

Incorporates IModuleRewriter extension method to clean up newlines left
by declaration removals. Removes EncapsulateFieldRewriteSession wrapper
class that previously handled declaration removals.
Remove blank lines left by declaration removals

Incorporates IModuleRewriter extension method to clean up newlines left
by declaration removals.
[rubberduck-vba/Rubberduck] BZngr pushed commit bbf30317 to next: Merge branch 'rubberduck-vba/next' into EncapsulateField_ClearBlanklines
Address PR #5555 comments

Retains use of IModuleRewriterExtensions class.
Merge pull request #5555 from BZngr/EncapsulateField_ClearBlanklines

Clean-up blank lines left behind by EncapsulateFieldRefactoring and MoveCloserToUsage
@this what was that particular case again?
That's affecting the Moq wrapper PR?
If it means we have an intrinsic limitation, then so be it - if everything else works good-enough, we can have it!
@MathieuGuindon I don't think so - it was for something different relating to inspecting whether we can safely ignore assignments like Set myObjectVariable = someIUnknownVariable in an inspection
> The type involved in the cast is defined by MZ-Tools; Carlos explains it in the linked issue, but the problem is ultimately that the IDE is loading two .net-based add-ins, and the two are marshaling COM types into .NET types, and if one "wins" then the other "loses": you can try configuring the MZ-Tools add-in to not load at startup and try to load it manually after Rubberduck finished initializing, but basically in order to fix this interaction we have to "shim" the .NET runtime itself [or
@Duga makes me wonder if we should iterate all loaded add-ins before the first parse, and message + unload if we find MZ-Tools loaded?
I'll mention it under known issues in the release notes
2:23 PM
not sure we will get that far
Good point
Makes me wonder how RD even started up in the first place
2:46 PM
8,997: v2.5.0 will be over 9000 downloads when 2.5.1 is announced
3:09 PM
my, VS updates are getting quite bloated
1 hour later…
4:37 PM
[rubberduck-vba/Rubberduck] build for commit ec44dc17 on unknown branch: AppVeyor build succeeded
6 hours later…
10:25 PM
@Duga Just in case...#5556 was intended to get into this release - It is still in the PR queue. Ok to merge after #5559? - or should it precede #5559?
should precede if it's to go into the release
[rubberduck-vba/Rubberduck] build for commit e5bf57be on unknown branch: AppVeyor build succeeded
@Duga very much hoping that Net 5 will solve COM automation. There's a heck of a difference between net46 and netcoreapp3.1 (which is what I target at work), RD is missing out on a lot of modern optimisations atm.
Span and Memory especially could help solve some of our memory problems, even absent LSP.
10:48 PM
@this do you have a link to the relevant netcore issue? My google-fu is weak.
> @retailcoder just a ping to remind that PR #5556 was targeted for this release...it is still in the PR queue. My understanding is that its merge should precede this PR.
@mansellan the primary thing we're waiting for is the COM Shim mess though
@Vogel612 Won't be needed in future, check chat history. Net core (soon 5) dispenses with AppDomains, just keeping a nominal one for back-compat. COM interop changes with core; instead of every add-in sharing a single mscoree.dll, they each get their own entry point, which should provide COM isolation without shims.
hence not wanting to get involved with shims when Net 5 is due out in 3 months :-)
Add DefaultPropertyValueParamIdentifier property

Exposes a single method for generating a default Let\Set RHS
property parameter IdentifierName.
Change default property RHS parameter identifier

Generates a property RHS parameter name based on the value of the
property's IdentifierName.
Move Property RHS Parameter Resource

Relocate and reformat the 'value' resource string from
Resources.RubberduckUI to Resources.Refactorings.
[rubberduck-vba/Rubberduck] BZngr pushed commit 1b9073d8 to next: Merge branch 'rubberduck-vba/next' into CodeBuilder_ChangeDefaultRHSParam
Address #5556 Review comments

Renaming per suggestions. Also, clean-up of commented code and removal
of non-required 'using' directives.
11:03 PM
Merge pull request #5556 from BZngr/CodeBuilder_ChangeDefaultRHSParam

CodeBuilder - Provide 'casing friendly' default property RHS parameter name
> @BZngr thanks for the heads-up, saw it earlier but mind slipped and, well here we are 😄
@this sorry I meant the netcore issue for the missing Automation support?
that was promised for Net 5
hmm, either I'm misremembering things or it's another issue.
github.com/dotnet/runtime/issues/13374 suggests that late binding is already possible provided you are willing to manually write the TLB yourself.
> Unfortunately I don't think we're going to get to this for 5.0 either. Moving to 6.0.
@this oh man...
ok, so worst case: COM Automation is not going to be happening any time soon in Core. Not necessarily a problem - if we want to use modern constructs (especially in memory management), that's mainly of benefit for lexing, parsing and analysing, not front-end interaction. So those can be solved with LSP, back-end on (whatever), front-end stays on net fx.
no, you can do automation right now
you just can't get type library easily
if you write the IDL manually & compile a TLB and it's compatible, then it should work.
one thing i'm still fuzzy is creating a dual implementation. In the Core the ComInterfaceType.Dual is not available (nor is ComInterfaceType.IDispatch)
hmm ok, I misunderstood when you said "Automation is due in Net 5", I guess you meant TLB generation. Whatever, it's still a front-end, interop-y kinda problem. Split out the back-end, problem goes away anyway?
COM only applies to front-end...
you can't latebind without the IDispatch.
Sure, so keep the front-end in NetFx for now, it's the only bit that cares about IDispatch.
11:30 PM
If Net 5 is not going to be ready to solve these problems, maybe we should prioritise front/back split. Then the front-end can be slim - interact with COM, send/receive LSP messages.
(I say this as someone who hasn't PR'd in a couple of years, I realise...)
Also, this looks interesting
> You can now perform unlimited undo/redo operations within the IDE (up from a maximum of 20 by default)
binary patching, mind...
> Minor adjustments to VB6.exe's assembly code required to force the IDE to render bitmaps in full 24-bit color depth instead of 4-bit by default.
wait, if that only affects IDE, maybe that's OK
if it patched the runtime files, that's bad
I know... but the thing is, we're doing some pretty intense things too. We've always shied away from patching, but... The VB6 IDE exe hasn't changed in ~20 years...
Oh yeah agree, runtime is off limits
yeah. and there's the other project that Mat found a while ago that basically redoes the VB6 IDE grounds up
(paid software, tho)
And if we limit patching to VB6, never VBA, version headaches go away?
MS ain't never touching the VB6 IDE again...
11:41 PM
I think given that in order to even run VB6, you must have admin privileges so those users who aren't admins are long ago SOL
In that case, it hardly matters for the users still rocking their VB6 IDE.
for those just using VBA, the lack of admin privileges might be a big problem.
Well... not entirely true. Out of the box, VB6 will bitch if you launch it without admin. But there are workarounds (probably implemented by about 13 people in the world...)
hmm but can you install it w/o admin?
Yep. It needs admin if you want to debug COM servers, because it's exe "sprouts" COM interfaces when you run say an ActiveX dll.
For standard Exe, not so much of a problem
It's a complete hack...
Oh OK. Last time I installed VB6 the instructions emphasized the need to use admin to successfully install
Well, considering that VB6 predated the registry redirection & UAC....
I think VB6 is the reason MS gave up on COM for user code...
Probably when they tried to add threading
11:46 PM
Splitting into front-end and back-end will not help regarding the add-in isolation issue. The fromt-end will still have iterate the projects and listen to the VBE events.
Yes indeed, wasn't suggesting it would, crossed wires. Split would allow most of RD to move to Core is all.
Was hoping all of it could move to core at Net 5, doesn't seem like it can
Maybe. I think the safety is the main obstacle. COM specifications says too little about safety, and there are lot of conventions that is not part of the programming language itself. That's why .NET is comparably much easier -- you can set conventions as part of the code and enforce it. With COM (or anything C++), the consumer must read lot of documentation to use it properly and hoping that there's no undefined behaviors.
I think you know more about it than I do :-)

« first day (2262 days earlier)      last day (35 days later) »