« first day (1305 days earlier)      last day (1875 days later) » 

Duga
Duga
12:01 AM
RELOAD!
[Hosch250/roslyn] 1001 commits. 7422495 additions. 2107260 deletions.
[retailcoder/Rubberduck] 9 commits. 1098 additions. 105 deletions.
[rubberduck-vba/Rubberduck] 19 commits. 4 issue comments. 30391 additions. 6181 deletions.
 
Mat's Mug
Mat's Mug
R.I.P. 2017 (2017 - 2017)
Tweeted by meganamram on December 31, 2017 at 4:33 PM
 
Duga
Duga
12:30 AM
> Closes #32. This PR introduces a new class called PropertyBag, which is a dynamic object working similarly to ViewBag in MVC. I changed the type of IInspection.Properties to dynamic and use this class when setting this property. The reason behind this change is to enable passing any custom information from inspections to quick fixes. Until now Properties was a Dictionary<string, string>, so info-passing options were very limited. In my inspection I use the new type twice: once...
passing a string and once passing a parent context (possibly many levels higher in the parse tree) related to the result.
 
Kapol
Kapol
First PR of 2018 - what do I get? ;-)
3
 
Duga
Duga
[rubberduck-vba/Rubberduck] build for commit 29d38900 on unknown branch: AppVeyor build succeeded
 
Mat's Mug
Mat's Mug
1:09 AM
@Kapol hehe.. 8pm here =)
Thanks for that!
 
M.Doerner
M.Doerner
1:21 AM
Happy new year to all of you!
3
 
Duga
Duga
2:17 AM
 
 
9 hours later…
Duga
Duga
11:15 AM
> A few issues identified in TimerHook.cs;

1) the timerId generated is never stored back to the class _timerId field. Therefore, in Detach(), a zero timerId is passed to KillTimer() and GlobalDeleteAtom().

Subsequently, your timer hook never gets released, and so this can cause the WinAPI to try calling into your managed callback even after the CLR has been unloaded. The callback will be a released memory address after the CLR unload, and so a potential crash situation.

2) GlobalAdd
 
Duga
Duga
11:40 AM
[rubberduck-vba/Rubberduck] build for commit da3fa6d0 on unknown branch: AppVeyor build succeeded
 
 
2 hours later…
Duga
Duga
2:01 PM
 
Vityata
Vityata
2:27 PM
Happy new year everyone! :)
 
 
1 hour later…
WaynePhillipsEA
WaynePhillipsEA
3:30 PM
@Mat'sMug looking at RegisterHotKey. If I may ask; what's the reasoning behind calling Attach()/Detach() all the time to register/unregister the hotkeys? I would've thought it would be easier to register them once, and then when you receive the WM_HOTKEY message, get the foreground window handle, and check the process ID of the hwnd is your app...
By doing this you should be able to move away from subsclassing the main VBE window (as there is no need to listen for WM_SETFOCUS), and instead use RegisterHotKey on an internal hidden window (that we usually call a broadcast window).
I guess it's in case another app uses the same hotkeys
 
Mat's Mug
Mat's Mug
@WaynePhillipsEA I borrowed the mechanics from the Smart Indenter VB6 source... may have been a weird idea lol
 
WaynePhillipsEA
WaynePhillipsEA
I'm not really fond of the system-wide hot keys TBH. I don't think anti-virus products like that sort of thing either
I'd probably use SetWindowsHookEx with WH_KEYBOARD, which should wok on a per-process level rather than global
 
Hosch250
Hosch250
3:47 PM
@Vityata Happy new year!
 
Mat's Mug
Mat's Mug
Hitting the road, bbl
 
 
6 hours later…
Duga
Duga
10:14 PM
> Closes #3662; add explicit logging for errors arising from Win32 API which will not necessarily throw exceptions.
[rubberduck-vba/Rubberduck] build for commit 8b9c4f05 on unknown branch: AppVeyor build succeeded
 

« first day (1305 days earlier)      last day (1875 days later) »