« first day (616 days earlier)      last day (2564 days later) » 
00:00 - 12:0012:00 - 00:00

12:01 AM
RELOAD!
[Hosch250/Rubberduck] 6 commits. 125 additions. 44 deletions.
[retailcoder/Rubberduck] 6 commits. 6959 additions. 6954 deletions.
[rubberduck-vba/Rubberduck] 16 commits. 10 opened issues. 9 closed issues. 49 issue comments. 73246 additions. 67869 deletions.
[Zomis/Duga] 19 commits. 3 opened issues. 1207 additions. 402 deletions.
[Hosch250/Rubberduck] Hosch250 pushed commit 3c6c93d3 to BugBlipper: Add Indenter Settings tab, adjust the instructions based on the selected tab, use "Todo" in all resx values rather than "ToDo". This should be standardized one way or another across the enti
 
So, these Unit Test settings are really a bunch of boolean values.
Well, most of them.
 
12:23 AM
Which do you like best?
 
heyo
Is it just the two of them?
 
Three.
 
As in, is there only two options?
 
The buttons, the checkbox, and the combobox.
Yes.
 
I would say definitely no on the checkbox, because you may not know what the reverse is
 
12:25 AM
That is what I was thinking.
The radio buttons seem OK, but I think they look weak.
 
I'd say the dropdown
 
The combobox looks stronger, but I'd rather not use it for some reason.
 
Radios take up heaps of space and rarely look nice
 
Space isn't an issue.
 
it'd look confusing if you stacked 10 comboboxes in a column, but that looks good
 
12:27 AM
There are going to be a bunch of others just like this.
Assert/permissive assert.
Module init/cleanup.
Test init/cleanup.
Whether a new module should include a new method by default.
I wonder if there are any other options.
Maybe a dropdown that can't be closed?
I guess that would be a listbox that had to have a selection.
 
I like the dropdown
"Assert" would be "Strict" vs "Permissive"
 
OK.
I'll stick a bunch of dropdowns and see what happens.
 
You can use a checkbox list area that you can scroll too IIRC
Like the one in the top-left here
 
I think there should be two groupboxes; one for the assertions (ealry/late binding to Rubberduck.tlb, use strict/permissive assertions), another for the module template options
 
Sure.
 
12:38 AM
Hmm they're all module template options anyway
@Quill it looks like you are trying to make a UI for a Windows app. Would you like to pass a UX review?
</clippy>
 
That's the colour of success
 
1:13 AM
Please, teachers: stop telling kids they can only get good marks when commenting code. Simple code can almost always be self-documenting.
Why's Hungarian notation bad? adjBecause adjHungarian nnotation vmakes nreading ncode adjdifficult. >:D http://stackoverflow.com/a/112080/419956
 
@Mat'sMug @Quill @RubberDuck
How's that?
 
looks good, if you want to fit it in one thing without scrolling, you could reduce the padding between the items
 
1:32 AM
@Hosch250 hmm what do the bottom 3 look like as checkboxes?
 
Only VBA could make DateSerial(0,0,0) = DateSerial(100,0,0) = DateSerial(2000,0,0) #Y2K
2
 
Looks good @Hosch250.
i.e, it looks a hell of a lot better than that awful informs thing I made.
 
@RubberDuck That's only the beginning ;)
@Mat'sMug What do you mean?
 
@Hosch250 maybe the title bar and the top pane could be merged?
 
Maybe. I think I'd rather leave them part of the other thing because some of them might have several title groups, like R#.
 
1:38 AM
I don't like that the labels are "asking questions", and I mean the yes/no ones could be checkboxes
 
I disagree about the checkboxes.
 
@ThunderFrame if it were a WPF window, yes. But it's a winforms form
 
Only one can be selected, so they are radiobuttons.
You mean like:
 
No, I mean [x] Include a stub test method in new test modules
 
Yeah, I just figured that out.
Took me a second, that did.
 
1:42 AM
Needs better captions and a bit more margins, but I like it
 
Now I just need to write titles and stuff and localize them.
Notice the instructions ;P
 
lol, the kind of thing that slips into a release build :-)
 
Seriously?
 
Not really
 
I think it would be caught in this small of a program.
 
1:44 AM
Love it!
 
OK. That seemed too easy.
 
Well that's just collecting config settings.. none of it is implemented yet
The instructions could say that these settings only apply to newly created test modules, not existing ones
 
[Hosch250/Rubberduck] Hosch250 pushed commit 4b304eb9 to BugBlipper: Unit test settings window layout.
 
Yeah.
 
I don't think there is a property to determine if a VBProject is in design mode. But you can determine the design mode, if the VBProject (or any of it's components) is selected, AND the Design Mode CommandBarControl is pressed. There are other VBE properties that are seemingly only readable/writable (and methods that are executable) by interacting with the CommandBars. It would perhaps be worth encapsulating those members?
 
1:46 AM
Is Rubberduck a "small program"?
 
Last time I tackled the settings config, it seemed like there were three layers of abstractions with duplicate logic everywhere.
No, I mean the settings config.
I think that may need a bit of cleaning up too.
 
@ThunderFrame I think that could be a property of the VBE itself, no?
 
Also, I'm completely not sure how to introduce the default settings into that thing.
@Mat'sMug Compared to VS, Windows, Office, R#, and most other programs, yes.
 
Start with the existing way and refactor? :-)
 
It is probably as big as MS Paint, anyway.
 
1:48 AM
...
 
Not a native property, AFAIK. Or are you suggesting I extend?
 
@Mat'sMug What's all that about?
The UI of MS Paint isn't big, but those image creating algorithms are quite complex.
 
An empty form has more functionality than MSPaint.
 
@ThunderFrame Not for free-hand drawing red circles.
 
@Hosch250 well, the parser generated code isn't exactly simple either ;-)
 
1:50 AM
True.
Well, probably bigger than MS Paint, but still a small program.
 
Design mode applies to the project, IIRC.
There doesn't seem to be a way of determining if Macros are disabled, for a particular project. The closest thing I can find is trying to exit design mode, and catching the error.
 
Oh design mode, in the host app?
What's design mode in the VBE anyway?
 
> I think I've made this reproducible. Open 2 projects, 1 from an untrusted location (and don't enable Macros), and 1 project with Macros enabled.
If you have any item in Untrusted.xlsm selected/active, then Application.Run does not work, even if explicitly referencing a method in Trusted.xlsm.
That means that Rubberduck's Application.Run methods will fail, unless the active project has Macros enabled.
It also means that any test methods that RubberDuck finds in a macro-disabled project, cann
 
Yeah, design mode is a feature I never used, and never knew what it was until today. Design Mode stops all code from running, including events. If a project is opened with Macros disabled, then the project cannot exit design mode.
 
2:07 AM
> There's potentially a side issue here. If you have 2 or more projects that share project name, test module name and test method names, then Application.Run potentially can't know which project you mean, so I think we might have to select the project or component, before we try to use Application. Run
 
That ready?
 
> Hold on a second.

This:

try
{
AssertHandler.OnAssertCompleted += HandleAssertCompleted;
duration = _hostApp.TimedMethodCall(_qualifiedMemberName);
AssertHandler.OnAssertCompleted -= HandleAssertCompleted;

result = EvaluateResults();
}
catch(Exception exception)
{
result = TestResult.Inconclusive("Test raised an error. " + exception.Message);
}

Is blowing up?
[Hosch250/Rubberduck] Hosch250 pushed commit e56fc280 to BugBlipper: Localize unit test settings.
> I think that means we need properties to determine the Macro-Enabled status and design mode of a project. I think we also need a method to select a project.
 
@Hosch250 add a "Test module template" heading above the checkboxes, and yeah pretty much!
well done @Hosch250, good job there - again!
 
> hmm..

This line:

AssertHandler.OnAssertCompleted -= HandleAssertCompleted;

May never run, if an exception is thrown. The handler should be removed in a `finally` block. But to bring everything down with it? in a `try` block that `catch`es *every throwable exception type*? ...something else is going on.
> @retailcoder I'm not sure it's that block that fails. Will check tonight.
> Last night, I did step over the COM exceptions coming from Application. Run, and oddly, sometimes test Explorer said my tests had passed.
 
2:19 AM
hmm I meant just a bold heading like the ones above the dropdowns, ...but I don't hate this at all
 
[Hosch250/Rubberduck] Hosch250 pushed commit 29d5d729 to BugBlipper: Add label, remove unnecessary scrollviewer
 
Want to look at it both ways?
 
sure
 
huh, the "Run" button in the test explorer currently says #RubberduckUI.Run
@Hosch250 that
beautiful
 
2:24 AM
[Hosch250/Rubberduck] Hosch250 pushed commit b263cbfb to BugBlipper: Make header one level lower.
 
I can't set up the VM until the settings are set up.
Guess I'll do the indenter settings now.
@Mat'sMug I know the problem.
 
now, "Test method binding mode" should be "Rubberduck.AssertClass binding" (and "Rubberduck.PermissiveAssertClass binding" when the other dropdown is "permissive assert")
 
Change Header="{Resx ResxName=Rubberduck.UI.RubberduckUI, Key=RubberduckUI.Run}" to Header="{Resx ResxName=Rubberduck.UI.RubberduckUI, Key=Run}"
I'm not going to start that until after the settings are done.
Actually, I'm going to get the three old windows to save.
 
cool. "Test method assert mode" could be just "Type safety", checkbox labels lose the "Include" and the question marks, and "initialization\cleanup" would be "initialization & cleanup"
oh and "when creating new modules" is already stated at the top, I'd drop it too
less is more
 
@Mat'sMug In the save, is it important to only save once, or can I have each view save individually?
 
2:39 AM
so, 20 panes, 20 open/write/close of the config file?
 
Only 5 for now, but that is the problem I was thinking of.
Let's see. How to keep this pretty..
I could go the way of the old inspections and have the parent pull the data from the children.
Oh, here is one possibility.
Let's say I pass the _config file by reference.
Then, I can call UpdateConfig() for each VM.
They will all assign the fields they are responsible for, and then I can call _configService.SaveConfiguration(_config, langChanged); from the parent.
@Mat'sMug How does that sound?
 
hmm
 
Only one open/write/close.
On the other hand, passing by ref seems funny for some reason.
Or, I wouldn't even need to call UpdateConfig(). I could just have everything update when something is changed.
That might be a bit overkill, though.
 
you (should?) have a model for each view; expose that POCO as a property of each VM
 
Yes, I have a model for each view.
 
2:46 AM
the VM needs to know about it
 
Yes, I'm going to make a VM interface for all those VM's to implement.
Yes, I am going to handle it in a VM either way.
 
nice
 
Either the VM of the child or the VM of the parent. I want to do it in the child VM.
So, do I update once on OK, or do I update as things are changed?
 
@Hosch250 you're working in BugBlipper?
 
The later will be less work just now, but the first, I'm not sure.
@RubberDuck Yeah, I forgot to create a new branch.
Is something up?
 
2:48 AM
Update once on OK I'd say. What if they cancel?
 
anyway you iterate your VM's and collect their Model into an enumerable that you then iterate to gather all config changes and write to disk.
 
Oh, duh.
 
hey @RubberDuck
 
Nope. Just curious to see your work. =;)-
 
Take a peek.
I have everything committed.
@Mat'sMug That's the problem - I can't quite do that and have it implement an interface.
Everything is all sorts of different types.
That is the only reason I am considering passing the _config by reference - that way, it gets updated automatically.
@RubberDuck Are you going to mention it in the reference?
 
2:51 AM
@Hosch250 you don't need to pass it by reference - you don't want to do it either
 
Yeah, but how do I get the data from the VM?
 
let the VM update the properties
 
None of it is the same data type, so I can't just use an interface.
 
it's the same reference, you'll see the modified properties in all copies of the pointer
 
What properties?
Oh, OK.
So, just do void UpdateConfig(), and I'll see the the changes everywhere?
Sounds sweet.
 
2:52 AM
should work
as long as you don't reassign the reference anywhere
hence passing it by value
 
Sure.
Really, I am currently passing the configService().
 
> If no assertions are made, it makes complete sense for the test to just pass IMO. Step one in TDD is to write a failing test, and you can't write one without making an `Assert` call. That's completely by design.

That code block is in [`TestResult TestMethod.Run()`](https://github.com/rubberduck-vba/Rubberduck/blob/next/Rubberduck.UnitTesting/TestMethod.cs#L23-L43), it's where all test methods run - the only place `TimedMethodCall` is ever called, is in that specific code block. If an except
 
So, can I just do configService.LoadConfig() everywhere, or do I have to pass the config itself?
 
load it once
everyone needs to be referring to the same object
sounds like a good case for a unit test that goes Assert.AreSame(expected, actual);
 
OK.
 
2:59 AM
I'm gonna write it Saturday morning @Hosch250. I already blocked the time off.
 
Great. Thanks.
Wait a sec, @Mat'sMug, what about UpdateConfig(out config)?
That is guaranteed to update the same object.
 
> I remember having this at one point:

Add
Add test module
Add test method
Add test method (expected error)

I figured clicking "Add" then "test module" would read just like that ;-)
 
@Hosch250 no. the only thing that's guaranteed is that config will be initialized when the method returns.
 
Huh?
 
that's what out does
 
3:05 AM
Configuration newConfig;

foreach (var vm in SettingsViews.Select(v => v.Control.ViewModel))
{
    vm.UpdateConfig(out newConfig);
}
That wouldn't work?
 
it might. but it's not guaranteed
 
OK...
 
vm.UpdateConfig is free to give you the object it wants
 
That doesn't matter.
 
vm.UpdateConfig(newConfig);
 
3:07 AM
It still comes down to the object getting the updates one at a time and having them at the end of the loop, right?
@Mat'sMug That passes by value, so it won't get the changes.
Oh wait, Configuration is a reference type.
 
except that ^^ guarantees that newConfig will still be the newConfig reference you think it is, when UpdateConfig returns
yes, of course! :)
 
@Mat'sMug It still wouldn't matter because I'm not worried about the instance.
But you are right.
 
what's UpdateConfig doing with newConfig?
 
config.UserSettings.ToDoListSettings.ToDoMarkers = TodoSettings.Select(t => new ToDoMarker(t.Text, t.Priority)).ToArray();
 
ok
there could be a ToMarker(ToDoSetting) method, it could read TodoSettings.Select(ToMarker).ToArray();
 
3:15 AM
Was wondering why nothing was working. Turns out my OK button binds to my Cancel command and vice-versa.
 
lol
 
Merge pull request #1068 from retailcoder/CodeExplorer

Grammar fixes
Merge pull request #1069 from retailcoder/CodeExplorer

fine-tuned numeric tokens (closes #753)
[retailcoder/Rubberduck] autoboosh pushed commit 6f38e2cc to next: allow date tokens as per VBA specification 3.3.3 (fixes #1073)
Merge pull request #1074 from autoboosh/dateliteral

allow date tokens as per VBA specification 3.3.3 (fixes #1073)
[retailcoder/Rubberduck] autoboosh pushed commit 1ec0af8b to next: enable "apply quick fix" if one is available (fixes #1075)
Merge pull request #1076 from rubberduck-vba/quickfixfix

enable "apply quick fix" if one is available (fixes #1075)
Update VBA.g4

added to changelog
 
@RubberDuck How do you like it?
 
Merge pull request #31 from rubberduck-vba/next

sync with merged PR's in main repo
 
like what?
the config settings window? it's awesome!
 
3:24 AM
The code.
 
15 mins ago, by Hosch250
config.UserSettings.ToDoListSettings.ToDoMarkers = TodoSettings.Select(t => new ToDoMarker(t.Text, t.Priority)).ToArray();
this?
oh geez
 
No, he asked which branch I was working it so he could inspect the code.
 
I hadn't even realized it's RubberDuck you were ping'ing
 
config.UserSettings.CodeInspectionSettings.CodeInspections =
    InspectionSettings.SourceCollection.OfType<InspectionSetting>()
        .Select(i => new CodeInspectionSetting(i.Name, i.Description, i.Type, i.Severity))
        .ToArray();
I like that ;P
 
I'd make a method group for the new CodeInspectionSetting part I think
but yeah
 
3:29 AM
I just realized I don't need my custom TodoSetting class, I don't think.
 
bingo
 
3:41 AM
Anyone know a good OSS way of converting RTF to XML?
 
nope
 
 
2 hours later…
5:24 AM
[Hosch250/Rubberduck] Hosch250 pushed commit aca14a0e to BugBlipper: Clean up settings. Make it actually save.
 
I can trash all the other settings now that these ones can fully replace them!
 
[Hosch250/Rubberduck] Hosch250 pushed commit 38813e22 to BugBlipper: Trash the old settings!
 
@Mat'sMug @RubberDuck The old settings are officially gone in this fork!
 
awesome!
bring it!!
 
@Mat'sMug Can you handle sticking the unit test settings into the config?
 
5:28 AM
does it build?
 
Yes.
I haven't built the VM behind it though.
I need three bools and two enums, or something.
 
I thought the model was the setting class itself?
 
Once the settings are in the config, I'll build the VM behind that view.
No, the unit tests view doesn't actually do anything.
I am going to build my VM around the settings config.
 
ok
 
[Hosch250/Rubberduck] Hosch250 pushed commit 59dd8aaa to BugBlipper: Remove unacessed fields
 
5:34 AM
And the marker interfaces are all gone.
Oh boy, did I break the unit tests deleting the old view.
I guess it is my turn, @Mat'sMug.
 
lol
new specs, new tests ;-)
 
@Mat'sMug Does the default config not save English as the default language?
NVM, wrong variable.
That's what I get for copy/pasta.
2
 
5:57 AM
@Mat'sMug I think I found a bug in the inspections.
Resetting doesn't work because the default config returns the user-defined severities rather than the original severities.
 
@Hosch250 because the inspections are InSingletonScope
but don't go and change that
 
It looks like you go and pass a copy to a different list.
Thing is, the inspections all have reference semantics, so...
 
huh?
 
In the configuration loader.
public CodeInspectionSetting[] GetDefaultCodeInspections()
{
    return _inspections.Select(x => new CodeInspectionSetting(x)).ToArray();
}
 
the default severity for inspections is defined in the constructor
 
6:01 AM
private readonly IEnumerable<IInspection> _inspections;

public ConfigurationLoader(IEnumerable<IInspection> inspections)
{
    _inspections = inspections;
}
configInspections = MergeImplementedInspectionsNotInConfig(configInspections, _inspections);
config.UserSettings.CodeInspectionSettings.CodeInspections = configInspections.ToArray();
 
eek
 
So, they have reference semantic and are the same elements because of something in Merge...().
 
default severity is defined in the constructor
constructor is only ever called once
 
Trouble is, we are reading the updated value in GetDefault...().
 
yes
the default severity needs to move
 
6:04 AM
So, that really should be a get-only property.
 
yes
 
I definitely do not have time to handle that tonight.
I'll create an issue.
 
ok
 
> The inspections severity needs to become a public field as well as being assigned to the base in each and every inspection. It should look something like this:

public CodeInspectionSeverity Severity { get { CodeInspectionSeverity.Warning; } }
public FunctionReturnValueNotUsedInspection(RubberduckParserState state)
: base(state, Severity)
{
}

This is very easy, but also very monotonous. You'll need to update the `InspectionBase` ctor:

protected Inspect
 
That look good?
 
6:10 AM
> I think this is good the way it is.
[Hosch250/Rubberduck] Hosch250 pushed commit d216041e to BugBlipper: Sort-of implemented reset. Bug in code inspection severities (see #1079)
[Hosch250/Rubberduck] Hosch250 pushed 37 commits to BugBlipper (only showing some of them below)
[Hosch250/Rubberduck] retailcoder pushed commit 95c679e0 to BugBlipper: closes #862 (support for currency literals)
Merge pull request #1068 from retailcoder/CodeExplorer

Grammar fixes
[Hosch250/Rubberduck] retailcoder pushed commit 105d146f to BugBlipper: fine-tuned numeric tokens (closes #753)
Merge pull request #1069 from retailcoder/CodeExplorer

fine-tuned numeric tokens (closes #753)
[Hosch250/Rubberduck] autoboosh pushed commit 6f38e2cc to BugBlipper: allow date tokens as per VBA specification 3.3.3 (fixes #1073)
Merge pull request #1074 from autoboosh/dateliteral

allow date tokens as per VBA specification 3.3.3 (fixes #1073)
[Hosch250/Rubberduck] autoboosh pushed commit 1ec0af8b to BugBlipper: enable "apply quick fix" if one is available (fixes #1075)
Merge pull request #1076 from rubberduck-vba/quickfixfix

enable "apply quick fix" if one is available (fixes #1075)
Update VBA.g4

added to changelog
[Hosch250/Rubberduck] Hosch250 pushed commit 2347cd06 to BugBlipper: Merge branch 'next' of github.com/rubberduck-vba/Rubberduck into BugBlipper
> This can't be right: we need to be able to `set` this value; I don't see why it couldn't just be an auto-property:

public CodeInspectionSeverity Severity { get; set; }

The constructor would just pass the hard-coded default down to the base constructor:

public FunctionReturnValueNotUsedInspection(RubberduckParserState state)
: base(state, Severity.Warning)
{
}

Instead of assigning `_severity` in the same class. The idea is basically to have 2 severity
> There is no `_severity` field in the same class. The current implementation is:

public WriteOnlyPropertyInspection(RubberduckParserState state)
: base(state)
{
Severity = CodeInspectionSeverity.Warning;
}
 
@Mat'sMug ^
 
> Right, an auto-property.

The base class could have this:

public CodeInspectionSeverity DefaultSeverity { get; private set; }
 
We just use the base Severity everywhere.
 
what's the "base severity"?
and we don't
 
public virtual CodeInspectionSeverity Severity { get; set; }
 
6:24 AM
ah
 
@Mat'sMug There is no other record of severity, so we do.
That isn't a bad idea, though, to set a DefaultSeverity in the base - it is simple, anyway.
 
yes
@Hosch250 yeah I misread "base severity" ;-)
 
/// <summary>
/// Inspection severity level. Can control whether an inspection is enabled.
/// </summary>
public virtual CodeInspectionSeverity Severity { get; set; }

private CodeInspectionSeverity _defaultSeverity;

/// <summary>
/// Default inspection severity level.
/// </summary>
public CodeInspectionSeverity DefaultSeverity
{
    get { return _defaultSeverity; }
    set
    {
        _defaultSeverity = value;
        Severity = value;
    }
}
How's that?
 
that's in the base class? field can be readonly
no need for a setter, the default is the hard-coded default
: base(state, CodeInspectionSeverity.Warning)
 
But we can't hardcode a value because it is in the base class.
DefaultSeverity = CodeInspectionSeverity.Warning;
 
6:29 AM
you pass it through the constructor
 
Simple search/replace.
Oh, OK.
Do I do this?
protected InspectionBase(RubberduckParserState state, CodeInspectionSeverity severity)
{
    State = state;
    DefaultSeverity = severity;
    Severity = severity;
}
/// <summary>
/// Inspection severity level. Can control whether an inspection is enabled.
/// </summary>
public virtual CodeInspectionSeverity Severity { get; set; }

/// <summary>
/// Default inspection severity level.
/// </summary>
public CodeInspectionSeverity DefaultSeverity { get; private set; }
And then:
Oh, I'm in the wrong class.
I need to be in IInspectionModel.
 
InspectionBase implements it, no?
the interface only needs to expose the getter,
your code is good
 
But the config uses IInspection, so I can't see the default.
 
except you don't need to assign Severity in the ctor, it gets overwritten milliseconds later when the settings are loaded into the instance
hmm that reminds me of a CR post
 
Oh, OK.
 
6:37 AM
one of the two interfaces needs to go
 
Boy, you have this reaaallly abstracted.
Inpsections implement InspectionBase, which implements IInspection, which implements IInspectionModel, IComparable<IInspection>, IComparable
 
InspectionModel needs to be merged with IInspection
 
I have to go to bed, and you probably should too. Work on this later.
 
yeah
 
6:38 AM
Good night.
 
 
4 hours later…
10:35 AM
> In my case, for 1.4.3.27555 version

Dim mn As Integer
mn = 0

For Each VBComp In VBProj.VBComponents

Doesn't help. I have no colons now before line in error.

So, may be this is yet another issue.
> @sshikov 1.4.3 is not receiving updates or parser fixes. If you want to benefit from the latest fixes and features (and bugs), then you'll need to build from the GitHub source.
 
11:17 AM
> Does it matter in this case? I mean that proposed fix (to remove colon) doesn't help.

So, I'm not yet sure that fix for #861 is relevant in this case. Another bug may exists in 1.4.3.27555, and this issue is **not** duplicate for #861.
 
00:00 - 12:0012:00 - 00:00

« first day (616 days earlier)      last day (2564 days later) »