« first day (755 days earlier)      last day (2425 days later) » 
00:00 - 19:0019:00 - 00:00

12:01 AM
RELOAD!
[Hosch250/Rubberduck] 10 commits. 1622 additions. 900 deletions.
[retailcoder/Rubberduck] 27 commits. 11909 additions. 10761 deletions.
[rubberduck-vba/Rubberduck] 9 commits. 2 opened issues. 5 closed issues. 42 issue comments. 3855 additions. 3336 deletions.
[skiwi2/ArbitrageClient] 4 commits. 73 additions. 6 deletions.
> Thanks for the help, but those two lines are useless--I'd need the full stack trace (or at least the first two lines would be better than the last two lines). At this point, I have no idea what is going on with any of this...
 
sigh
 
> @retailcoder extra-long weekends are great. I highly recommend requesting an extra day off far in advance. ;)

@Hosch250 that's too bad, sorry about that. I was being lazy and not logging in to github on the windows machine and typing instead. I won't have access to a windows comp until Monday so I'll take a screenshot then.

Have a good weekend you two!
 
12:30 AM
@Mat'sMug I figured out why the UI isn't always right.
RubberduckUI.Culture gives the culture as the culture of the current thread.
So, there are two alternatives. A) set the culture of each thread in the process when the language is set.
B) pass the config everywhere and use the selected culture.
I'm not satisfied with either--do you have any other ideas?
Isn't there any way for us to just have the set culture as a static string somewhere so we don't need to load it from the disk constantly?
We could set the value when the settings are changed, for instance, and just read it the rest of the time.
Ugh, VS is slow tonight.
Actually, no need.
Change RubberduckUI.Culture with CultureInfo.CurrentCulture.
NVM, that doesn't work after all...
It only works at first during the load, which is why some are localized and some aren't.
@Mat'sMug Let me know what you think about:
public static Culture Culture { get; private set; }
In GeneralSettingsViewModel.
We can set it every time the language changes, and get it from anywhere without loading the settings everywhere.
I'm going now, TTYL.
 
Seems like at first I was swamped with incomplete features. Next I was swamped with difficult parser/resolver/grammar/COM collector bugs.
Now I'm swamped with bugs I can't reproduce, and when I do, I don't get any reliable information on the cause.
 
^ MS would consider that an RTM trigger
 
First effort on the MS replacements.
I'm not sure I like the test ones.
 
1:34 AM
@ThunderFrame Me too.
Right now, I'm just trying to get logging in.
 
2:09 AM
@Comintern me neither, but it's otherwise pretty damn good-looking.. I say go with it!
 
Second go is more along the lines of the VS ones.
I think I like those better.
 
Oooh shiny!!
@ThunderFrame dang, that website needs some lovin'
 
Do the WPF icons get compiled into the Resources.resx file?
I should probably make sure I'm not missing anything...
 
@Comintern they should be. That's where we're loading them from :-)
 
Perfect. I'll sort out the unused ones and drop some appropriate license txts in the directories.
 
2:20 AM
Cool!
> Rubberduck.Setup.2.0.3b.exe (5.32MB) - Downloaded 53 times.
Last updated on 2016-06-24
Download rate seems to be accelerating. Ah, Twitter. Where a picture is worth a thousand downloads.
I wonder if and to what extent MS has spotted us
Bugs that are impossible to reliably reproduce are plain evil. We’re playing a game of “where does a network packet fall off the earth?"
@Hosch250 ;^)
 
[rubberduck-vba/Rubberduck] Hosch250 pushed commit 938c8bfb to next: Give Source Control a menu.
[rubberduck-vba/Rubberduck] Hosch250 pushed commit bcc960b3 to next: Merge branch 'SourceControlBugs' of github.com/Hosch250/Rubberduck
[rubberduck-vba/Rubberduck] Hosch250 pushed commit 6cb49415 to next: Localize new menu
[rubberduck-vba/Rubberduck] web-flow pushed commit 2d4a23ae to next: Merge branch 'next' into SourceControlBugs
Merge pull request #1940 from Hosch250/SourceControlBugs

Give source control a "Manage" menu
[rubberduck-vba/Rubberduck] build for commit 2ef9bf6d on next: AppVeyor build succeeded
 
2:56 AM
0
Q: Make Macro Work Faster

P.AlvsGood Day! I just to ask if there is any alternative way to make my macro work fast? I only use Record Macro. what my macro do is Find The Word "JOBSPECIALTYCODE" in the sheet then select and delete. then move to next sheet. just like the image a provided PLEASE CLICK Sub aHaveProgess() ' ' ' ' ...

 
3:12 AM
@Mat'sMug - Apparently the ? is an isolated error!
last I looked, there were thousands.
 
Huh!
 
 
1 hour later…
4:17 AM
> ![crash on red x exit](https://cloud.githubusercontent.com/assets/6796503/16476712/f3e3a0e4-3e81-11e6-828c-f9fe4f847c37.PNG)
![project identified](https://cloud.githubusercontent.com/assets/6796503/16476714/f4034ce6-3e81-11e6-9fd5-e93a6fcc31ad.PNG)
![rd ready](https://cloud.githubusercontent.com/assets/6796503/16476713/f3ffd480-3e81-11e6-847d-4c657a9c5ced.PNG)

Installed newest version of Rubberduck
Open excel
Open VBA editor
close vba editor from red x
close excel from red x
crash...
 
5:13 AM
-2
Q: Execel Formula How to Plot Work Hour Per day

P.AlvsIm came here to seek some help with my Execel Formula. Please Check this Image for more details PLEASE CLICK In my Document i state the number of report that i have and the time i recieved it and the deadline. just to monitor how many days and hour to finish that. i make some file like this. I u...

 
 
6 hours later…
11:42 AM
> @Hosch250 that's the failing Debug.Assert call in the sink handler for project removed; Debug calls don't get compiled into a release build. How about we replace it with a conditional early return?
 
12:05 PM
> Ah! See, by avoiding both whenever possible, I've not learned the finer distinctions.
 
12:20 PM
:( Why do my most WPF queries end up in "You can't do this", I thought WPF was great
2
107
Q: How to apply multiple styles in WPF

MojoFilterIn WPF, how would I apply multiple styles to a FrameworkElement? For instance, I have a control which already has a style. I also have a separate style which I would like to add to it without blowing away the first one. The styles have different TargetTypes, so I can't just extend one with the...

For example ^^
And there's a @QuackExchange here? :o
 
@skiwi So you can apply multiple Styles in WPF.
 
Only now I need to get it working, WPF is quite hard to get to work, but once it works it's more predictable than JavaFX
 
1:02 PM
@skiwi Quack!
 
1:28 PM
> Ah! See, by avoiding both whenever possible, I've not learned the finer distinctions.

It would still be a nifty feature to find all `Workbook` variables in scope and present them as Quick Fix options. Just not under `Quick Fix All`, since that would likely create chaos...
 
2:26 PM
@Duga It doesn't fail for me, @Mat'sMug. If you can reproduce it, why don't you figure out what's up with it being null?
Also, @Mat'sMug, I know how we can catch and log any error in the commands in a single place without using interception.
I thought of it last night.
 
CommandBase
 
Yup.
We rely on that anyway, so this is my idea:
We only implement CanExecute and Execute in that class.
Each class to implement CommandBase has to provide a void ExecuteImpl(object) method, and optionally provide a bool CanExecuteImpl(object) method.
Execute looks like this:
 
@Hosch250 You don't like them interceptions
 
@Hosch250 if that Debug.Assert call sporadically fails in debug, then its condition will sporadically fail in release. I can't reliably repro either, but when that assertion fails, it would let the exception they're getting be thrown. Let's just exit the sink handler then, and remove that debug call
 
public void Execute (object obj)
{
    try
    {
        ExecuteImpl(obj);
    }
    catch (Exception e)
    {
        // log/alert for problem
    }
}
@Mat'sMug Well, I'd say leave the call in, but exit too for release.
 
2:31 PM
@Hosch250 try a templated method
i.e. you make Execute call an abstract method that inheritors have to implement
 
@Mat'sMug Exactly.
ExecuteImpl is abstract, and CanExecuteImpl is virtual.
 
ok
 
And all Execute/CanExecute calls will be routed through CommandBase.
 
yeah that works
@Gareth I don't know what to say to convince him of the goodness anymore :(
 
I guess I'm a hopeless case for now.
 
2:35 PM
@Hosch250 not hopeless. you hopped into the DI train :)
 
It's a loss of a really interesting research topic.
 
DI
e
 
@Mat'sMug Just curious, but why is this virtual?
public virtual string ShortcutText { get; set; }
R# says it doesn't need to be.
 
then it probably doesn't need to be :)
@Gareth that just stuck Metallica's Creeping Death into my head for some reason
 
2:38 PM
so just backing that up... Where is this virtual string ShortcutText? R
 
> DI! By my hand! I creep across the land code, killing first-born men useless junk
 
:)
 
@Gareth CommandBase
 
wonders why a method on a Base class might be virtual github.com/rubberduck-vba/Rubberduck/blob/…
 
technically it's a property :)
but yeah a virtual auto-property in an abstract class, looks like a freakin' typo :)
 
2:42 PM
@Mat'sMug Can I remove this marker interface?
public interface INavigateCommand : ICommand { }
public class NavigateCommand : CommandBase, INavigateCommand
 
if it doesn't break double-click navigation anywhere, sure
 
Actually, I don't think I will (at least just yet).
We use that to signal what needs to be injected.
 
that marker was a lazy work-around for ... yeah that ^
you could replace it with a custom attribute, and adjust the bindings
 
@Hosch250 just trying to think this through. A virtual property in an abstract class. What are the alternatives
 
@Gareth Just remove the virtual?
 
2:47 PM
virtual, abstract, none
 
Basically, we were saying that if the derived class needed to set up a custom set action, for example, they could.
We don't need it for this bit, so I just made it a normal property.
 
technically it's an abstract Base class, so you create a Concrete implementation, not a derived class
 
> Locally-scoped variables (i.e. "locals") can only be declared with `Dim`; module-scoped private variables (i.e. "fields") can be declared with both `Dim` and `Private`.

`Private` makes a field's scope explicit, but `Dim` not so much. *Public* fields can only be declared with the `Public` keyword (in a class module - in a standard code module, `Global` can be used with the same meaning as `Public`, but we already have an inspection for that), which makes `Private` the go-to keyword for decla
 
so when you remove the virtual you end up with a concrete none overridable implementation of a property in an abstract Base Class
 
which is totally fine, no? abstract class != interface....
(to an extent - you don't want a crap ton of concrete implementation in a base abstract class anyway)
 
2:53 PM
I'd go with the virtual, or make it abstract, but that is because I come from the school of thought of Composition of classes
 
abstract would be annoying IMO. it can be implemented as an auto-property in all implementations.
removing virtual is a breaking change (but then, there are no overrides so we're fine)
might have been made virtual just because abstract would have been annoying, and virtual leaves the flexibility for derived types to override it if they ever need to
 
Yes, and that's a fine reason to leave it just that way
just because resharper says it doesn't have to, doesn't mean the abstract-ness of the commandBase can't be expressed by way of the virtual-ness of that property
cheers chaps. Stimultation conversation
 
cheers!
 
@Gareth OK, R# calls it derived.
OK, I'll stick virtual back in.
 
yeah, it's pure inheritance at play - "derived" is correct.
 
3:01 PM
OK, how exactly do you want RD to behave for a fatal error?
Just display an error message box telling them to restart the host (for now, anyway, until we get restarting RD working)?
Nothing more, and if they fail to do so, it is their own problem?
 
aye, user needs a message, the exception needs to be logged, and forbidden to bubble further up the stack and bring down everything before the user can do anything.
@Hosch250 yes
 
Yup, that's what I'm doing right now, except the message.
 
and if/when it crashes, we can say "TOLD YA!"
2
but it's not going to crash, because we're not going to let it
 
We need to get things out of the UI and into commands.
 
I'm pretty sure it's going to solve more problems than it's going to create
 
3:03 PM
After I commit this, I'm going to do the Source Control commands, but there are a lot of other things that could be commands.
 
yes
 
OK, now for the big test. I'm going to deliberately insert a throw in one of the commands to see what happens.
 
ooh
 
2016-06-30 10:11:45.2615;DEBUG;Rubberduck.UI.Command.MenuItems.ParentMenus.ParentMenuItemBase;(46415386) Executing click handler for menu item '&Code Explorer', hash code 9624530;
2016-06-30 10:11:48.6571;FATAL;Rubberduck.UI.Command.CommandBase;System.InvalidOperationException: I can't crash RD anymore :(
   at Rubberduck.UI.Command.CodeExplorerCommand.ExecuteImpl(Object parameter) in C:\Users\hosch\Documents\Visual Studio 2015\Projects\Rubberduck\RetailCoder.VBE\UI\Command\CodeExplorerCommand.cs:line 27
 
> 10:11:48.6571;FATAL;Rubberduck.UI.Command.CommandBase;System.InvalidOperationExc‌​eption: I can't crash RD anymore :(
lol
 
3:15 PM
[Hosch250/Rubberduck] Hosch250 pushed commit 2865aac5 to logging: Catch crashes in commands.
 
I'm going to use anonymous types for the first time today.
The source control commands use the Provider in the VM as well as a bunch of other data only relevant to that command.
I'm going to package it up in an anonymous type and pass it to the command, then use dynamic typing to get the data out because I don't have the type.
 
> nitpicking, but I'd rather it be catch (Exception exception), be it only for consistency.
 
@Hosch250 you can't pass anonymous types around
 
My other option would be to create 5-10 types just to hold a couple pieces of data, and that doesn't seem clean.
 
@Hosch250 For the "first time, today" or "for the first time today". "Let's eat, grandma!" -- commas are important! :)
 
3:19 PM
@Mat'sMug You can if you cast them to object.
 
so you have object in a public interface??
 
@FreeMan Hey, it is the first time today.
Well, maybe it won't work.
 
Or, as my wife saw posted on FB: "I'm going to help my Uncle Jack off the horse". Capitals are important, too!!
 
LOL
 
3:20 PM
@Duga I chose not to do that because we never mock it.
 
And, now that I've provided the days entertainment/requirement for eye bleach, it's time for my lunch run. TTFN
 
In fact, if this happens in a test, something pretty serious is happening.
@Duga No problem.
 
> The logger should be passed into the base class from the derived constructor. Otherwise the "current class" is always going to be CommandBase.
 
in The 2nd Monitor, 52 secs ago, by Zak
@Mat'sMug Funny story. My antivirus identified the RubberDuck installer (2 alpha H1) as adware.
 
@Duga Does it particularly matter, but sure.
 
3:23 PM
yes it does. the logger's name is used in NLog for namespace-filtering log entries.
 
Oh, OK.
Do you still want IMessageBox?
I thought it didn't matter if I used the wrapper because it should never happen in a test one way or another.
NVM, I already changed it.
 
so one day we decide to move all these implementations into their own assembly, which doesn't reference the WinForms dll's.
that coupling is nocive
 
OK.
So, like this?
public AboutCommand() : base(LogManager.GetCurrentClassLogger()) { }
Or should I just make it a protected abstract field?
 
nah
 
Nah to what?
 
3:29 PM
lol, IMO a protected field is just like a public one, it stinks.
 
OK.
 
if anything you can expose the logger with a protected virtual getter
 
TBH, though, I have a hard time seeing the difference between an auto-implemented property and a field.
 
a field is a field, a property is a property
you can't override a field
 
Oh, that's the difference? Makes sense.
 
3:31 PM
a field is an implementation detail. give me encapsulated fields or give me death.
 
Like this?
protected virtual Logger Logger { get; }
 
> There's something not right with having both Execute and ExecuteImpl public, it makes the interface ambiguous. I'd like to see public abstract Execute and private ExecuteInternal, but I can't think of a way of making it work ATM.
 
@Duga I made ExecuteImpl protected.
 
@Hosch250 protected virtual ILogger Logger { get { return _logger; } }
@Hosch250 ah, good
 
Oh, so this way the children can use the same logger.
Makes sense.
 
3:42 PM
It does leak the NLog logger through though :-/
well, only to derived types, so not too bad
 
Oh, I didn't realize DelegateCommand derived CommandBase.
That means every single place we use a command in Rubberduck now catches all exceptions.
public DelegateCommand(Action<object> execute, Predicate<object> canExecute = null) : base(LogManager.GetCurrentClassLogger())
@Mat'sMug That doesn't look quite right.
It also doesn't feel quite right to put it in the ctor.
 
it's a static method, used in static context... what's wrong with it?
 
Oh, I didn't make it static anymore.
 
huh??
LogManager.GetCurrentClassLogger() is static
 
Logger isn't static.
Oh, OK.
@Mat'sMug It has the same problem as just declaring it in CommandBase.
 
3:55 PM
how?
the logger will be named after the derived type, not CommandBase
 
It shows the namespace of DelegateCommand, not `ChangesViewViewModel, for example.
@Mat'sMug I just got graded on my reports for weeks 3, 4, 5, and 6 (and probably 7 within the next few minutes).
 
oh, lol.. then the parameter needs to move up the inheritance hierarchy
 
However, I can't log into my U account because I had to change the password four days ago, and forgot the new one.
And somehow the security questions on my account got cleared, so I can't reset my password...
I guess I need to call the help desk.
 
or hack into it
mwahaha
 
LOL, I could probably do a SQL injection.
I wonder what would happen if I dropped the student's table.
 
3:59 PM
the attack attempt would get logged and you'd get in trouble?
 
@Hosch250 Nothing, there's no students left that could get angry
3
 
@Mat'sMug I'd have to drop the log database too.
Fortunately, this is the last time I'll have to do this.
 
@Hosch250 you're assuming the logs get written to a database...
 
@Mat'sMug You're assuming the database still exists at the point assumed logging would want to log...
Ugh, I thought I found a good MVVM tutorial, msdn.microsoft.com/en-us/magazine/dd419663.aspx but look at the code blocks
 
wow that's dumb
 
4:09 PM
markwithall.com/programming/2013/03/01/… has a background I can't stand :D
 
> Currently, the only quick-fix we offer when a `ByVal` parameter is assigned, is to pass the parameter `ByRef`. It being the only fix available, it's also the default fix for that inspection, and applying it changes the semantics of the code and can introduce bugs.

The default fix should be **Introduce a local variable**, that turns this:

Public Sub DoSomething(ByVal foo As Integer)
'some code
foo = 42
End Sub

Into this:

Public Sub DoSomething(ByVal fo
 
Goodness, I'm glad that's the last time it will happen.
My new password will last until I graduate.
 
if you remember it :)
 
I wrote it down.
Straight 100%'s so far.
This week, I'll be able to write about learning about intercepting and being reminded about the stack trace of exceptions changing.
 
aka "proper way to rethrow an exception in .net"
 
4:17 PM
@Mat'sMug Guess what I just found?
We have exactly 101 usages of DelegateCommand in 14 files.
 
your old password?
oh
 
Poor me. I have to copy/paste the logger 101 times.
 
perhaps we should rename it Dalmatian then
 
Already done. Go R#!
I used Change Signature and told it to use the specific value of LogManager.GetCurrentClassLogger().
 
[Hosch250/Rubberduck] Hosch250 pushed commit 6b984212 to logging: Use logger from parent command class.
 
4:23 PM
@Mat'sMug What do you think about exposing the culture as a static value in the general settings class?
 
not now
 
I don't think much of it, but it is the cleanest way of getting the selected culture without reading from the disk all the time.
 
sort of
 
Right, that I could think of.
 
we need to define a proper ambient context
 
4:24 PM
I thought about putting it in a separate class, but I don't like that idea at all.
Oh wait, I do like that idea.
I'll just listen for settings changed and updated privately.
When I first thought of that, I thought I'd have to make the setter be internal at the very least.
 
So, @Mat'sMug, what do you think about exposing all the settings through this class?
We shouldn't have to do I/O every time we run the inspections and stuff, we really only need to change the settings when we change them.
 
[Hosch250/Rubberduck] build for commit 6b984212 on logging: AppVeyor build succeeded
 
the settings, the parser state/tree/whatever, static arrays of specific keywords/tokens/types, all these would be part of the "ambient context" I'd say. And once that's done, then it can stop being injected everywhere, it's "ambient". and we can still control it in tests.
actually.. disposable stuff can't go on there
@DmitryGolubets: If you think logging is an essential aspect of your class make that obvious and inject it using constructor injection. If its for tracing input values and logging exceptions (I treat logging and tracing as fundamentally different things!) use decorators or interceptors. But never hide a dependency! That will bite you rather sooner than later. Always. — Sebastian Weber May 21 '12 at 12:49
I need to re-read the chapter about ambient context to better weight the pros and cons before I make a decision
 
4:41 PM
OK, do I have permission to create a class injected with the settings config that exposes the language to everything for now?
 
sure
 
4:52 PM
Oh, I just learned about filters on exceptions.
try
{
    var config = _configService.LoadConfiguration();
    _cultureInfo = CultureInfo.GetCultureInfo(config.UserSettings.GeneralSettings.Language.Code);
}
catch (CultureNotFoundException)
when (_configService != null)
{
    _cultureInfo = RubberduckUI.Culture;
}
I won't leave it there, but that's interesting.
 
5:04 PM
[rubberduck-vba/Rubberduck] build for commit 6b984212 on unknown branch: AppVeyor was unable to build non-mergeable pull request
BUILD FAILURE!
 
Is there a reason private variables in C# always shart with an underscore, they already have the camelCase vs PascalCase distinction with properties
 
consider
    private int foo;

    public void DoSomething(int foo)
    {
        this.foo = foo;
    }
with private int _foo; you don't need to qualify this.foo, you can just do _foo = foo;
 
Well okay, but it just is hungarian notation if you ask me
 
and when you start qualifying fields in one place, you kinda have to do it everywhere, and then yuo start having redundant this qualifiers everywhere, and it gets annoying and then I refactor/rename all the fields
@skiwi it's not intFoo, it's _foo. the underscore says "I'm a field" just like camelCase says "I'm a local" and PascalCase says "I'm a public interface member"
if Hungarian, then it's Hungarian done right
at the end of the day it's just a naming convention
IsEnabled is Hungarian, IDisposable is Hungarian. Not all Hungarian is evil.
2
 
5:20 PM
Hmm ok
Where is the best place where I can see MVVM in action in Rubberduck?
The tutorials are still a bit vague
 
depends what "best" means
FindSymbolViewModel would be a nice simple example
the View
the Model
(I think... I'm never too sure wtf the "model" is supposed to be anyway)
 
I'll try to make something nice on my screen, though I'm still having some trouble understanding it
 
@Mat'sMug Those are the supporting classes.
Like, the different data classes to support your view.
 
I guess when I am adding a purchase in my application, it should consist of the individual fields I need to create that purchase?
 
Something along that line.
 
5:34 PM
 
@Mat'sMug I figured out why some of our localization is messed up.
 
Merge pull request #1940 from Hosch250/SourceControlBugs

Give source control a "Manage" menu
[Hosch250/Rubberduck] Hosch250 pushed commit 2bfc4f4f to Issue1397: Fix some localization
 
Cool!
 
First, we load the Ninject module. Then we load our localization.
The Ninject module instantiates a bunch of stuff with the thread culture before we set the culture to use.
Basically, we need to set our UI before we do anything else.
 
[Hosch250/Rubberduck] build for commit 2bfc4f4f on Issue1397: AppVeyor build succeeded
[Hosch250/Rubberduck] Hosch250 pushed 13 commits to logging
[Hosch250/Rubberduck] Hosch250 pushed commit 3934359a to logging: Pull with conflicts
[rubberduck-vba/Rubberduck] build for commit 3934359a on unknown branch: AppVeyor was unable to build non-mergeable pull request
BUILD FAILURE!
 
5:43 PM
@Mat'sMug Restart that, will you?
I resolved the conflicts, and the branch is fully up-to-date with next.
 
Ugh, I tried making a new PR, but it detected that it had already tried to run the tests. GitHub says it is mergeable.
@Mat'sMug The other PR didn't even get queued on AppVeyor.
 
[Hosch250/Rubberduck] build for commit 3934359a on logging: AppVeyor build succeeded
[rubberduck-vba/Rubberduck] build for commit 2ef9bf6d on next: AppVeyor build succeeded
 
@Mat'sMug The variables are read only because you can neither change them in the viewmodel?
(or view)
 
[Hosch250/Rubberduck] build for commit 3934359a on logging: AppVeyor build succeeded
 
5:52 PM
@skiwi well, they don't need to be mutable in any way
 
@Mat'sMug Can you help?
AppVeyor says that my PR is non-mergeable even though GitHub says it is mergeable.
And the other PR didn't even get picked up, but it re-ran the tests for an older PR that was already merged...
 
I did run the tests on both.
 
[rubberduck-vba/Rubberduck] Hosch250 pushed commit 2865aac5 to next: Catch crashes in commands.
[rubberduck-vba/Rubberduck] Hosch250 pushed commit 6b984212 to next: Use logger from parent command class.
[rubberduck-vba/Rubberduck] Hosch250 pushed commit 3934359a to next: Pull with conflicts
Merge pull request #1945 from Hosch250/logging

Logging
 
1944 has conflicts now ..ugh
 
5:54 PM
Resolving.
Just one.
Just a using directive.
 
[Hosch250/Rubberduck] Hosch250 pushed 3 commits to Issue1397
Merge pull request #1945 from Hosch250/logging

Logging
 
OK, AppVeyor picked this one up.
 
[Hosch250/Rubberduck] Hosch250 pushed commit f9a71652 to Issue1397: Pull with conflicts
 
Off to lunch, BBL.
 
[rubberduck-vba/Rubberduck] build for commit e6b454e7 on next: AppVeyor build succeeded
[Hosch250/Rubberduck] build for commit f9a71652 on Issue1397: AppVeyor build succeeded
[rubberduck-vba/Rubberduck] build for commit f9a71652 on unknown branch: AppVeyor build succeeded
 
6:25 PM
@Mat'sMug I think you'd better review that other PR too.
 
00:00 - 19:0019:00 - 00:00

« first day (755 days earlier)      last day (2425 days later) »