Oh, that was mine. I had a blonde moment and forgot that when I call CodePane.Window.Caption it has to get the Caption by sending a WM_PAINT message. So... if I have vbe.CodePanes.Cast<CodePane>().FirstOrDefault(x => x.Window.Caption.Equals(caption.ToString())) in the message pump it recurses.
> Working on 118f532 in Excel 2010 The code explorer shows an empty window. I get a message Parser Error When opening the result window it is empty. Opening the result window several times I get multipl tabs in the window 
> Changes: 1. Add support for foreign identifiers (#1521). Only the first "level" is considered and simply treated as a normal identifier. 2. Speed up all parsers by rewriting the grammar (#1502). The 65k comments example parses in 400ms here. The parser tests run in 2secs now. The preprocessor tests in 1sec. Modules in smaller test projects are usually parsed in <100ms. If the faster approach fails, it falls back automatically to the slower approach. This way even if there's a combination...
that requires the slow approach it won't fail. It does get logged however so we can fix it (currently simply using Debug.WriteLine). 3. Integrated expressions into the main grammar. There's no separate expression grammar anymore. Because of that valueStmt and rules like "implicitCallStmt_InStmt" are no more. There's no need (in most cases) to reparse expressions anymore either. Please review and test with as much code as possible. All tests pass but since quite a few things have changed there...
> I don't know what's up with this, but if you get a parser error on the very first parse, the code explorer will be empty, and there is nothing we can do about it.
> No problem! Please tell me how long the parser/preprocessor tests take on your system. I wonder how long they take on @grleachman's PC. Hopefully under 1 minute...
> @Hosch250 we'll have to do something about refreshing the parser errors tab instead of making a new one everytime the parser error button is clicked.
> The latest changes might have helped with this issue. @joshuader6 can you give it a try again? Or at least give a quick summary of what you tried to rename?
> The parser should be a lot faster now. The comments example mentioned in the first post takes about 500ms to parse here now. @ThunderFrame (or anyone really): Can you use the latest version and tell me how long it takes?
> @Hosch250 had the idea of linking up members and the interfaces/interface members to implement since that would make a lot of things easier. Currently the class declarations have the supertypes/subtypes they implement but the members don't have anything like that.
> "TypeOf Is" expressions are split up into "type of" and "is" operations and I got the hierarchy wrong. I thought it's type of expression -> relational op but it's relational op -> type of. Here's the fix plus tests.
This is interesting - VBA's For loop can get confused if you're using a Step that doesn't get initialized. This code will exit, and outputs 0, 1:
Private Sub ForStepWierdness()
Dim current As Integer
GoTo InsideLoop:
For current = 1 To 10 'Step 2
InsideLoop:
Debug.Print current
Next
Debug.Print current
End Sub
But if you uncomment the Step 2, the loop iterater must never get initialized - it just falls into an endless loop. The current variable never gets updated.
> Related to #1541 and #1504 Changes: * Added logging for files (rollover at 5MB) * Only one log file now, not one per "logging class" * Added log to debug/output window * Tests only log to debug/output window * Removed EventId from event log * Added example in identifier resolver * Added "Detailed logging enabled" to general settings. The idea is that the user can enable detailed logging which logs events with Log Level Debug+Trace. Otherwise only Info and above is logged. Also renamed...
the Event Log Source as specified in #1504. Does the installer have to be changed? Anything special in the config file that has to be done? The default is "detailed logging enabled"=false, that's why every developer has to enable the setting first. This is only an idea to get something out there, if there are ideas to make it different I'll change it.
It makes me think that when it's compiled, the Step is treated as a function that gets called by Next to increment the loop variable. If you jump past it, it doesn't get initialized, but neither does the default "add 1" increment.
This code would seem to confirm that:
Private Sub JumpIntoLoop()
Dim jump As Integer
Dim current As Integer
Dim wentTo As Boolean
jump = 1
For current = 1 To 10 Step jump
InsideLoop:
Debug.Print current
Next
Debug.Print current
jump = 2
If Not wentTo Then
wentTo = True
GoTo InsideLoop
End If
End Sub
Basically, in the list of declarations, it would be nice if a member that overrides an interface member has a link to the declaration of the interface's member.
I know of some people who use git pull --rebase by default and others who insist never to use it. I believe I understand the difference between merging and rebasing, but I'm trying to put this in the context of git pull. Is it just about not wanting to see lots of merge commit messages, or are ...
Ah, I think I get it. Commit locally and when it's ready to push, do pull -rebase... right?
When syncing I mean
Of course VS doesn't do that when you sync
@Hosch250 I'm pretty sure I saw you write a couple more things you learned last week. As I said I won't be able to send you back the report until Tuesday, feel free to fine-tune it by then :-)
@Comintern that would surprise me given WPF must be hosted in a WinForms interop container... but damn that'd be SICK!!
@Hosch250 and its remarkable how many people refuse to use them.
If I load the addin after IDE is loaded a load of panes go from visible to invisible. Can these panels/panes whatever they are can have a default state of not visible
For your example. How long does it take to parse... That is not an Assert.That() failure. It's pure debug dross
dross being relative of course.. we do need it at certain times, but it doesn't really provide use in every day running
So anyway, I merely commenting on the fact that in using Ninject, there really shouldn't be a need for extensive logging messages of the Debug.Print sort that I have been seeing. IE Debug.Print("method in")... Debug.Print("Method Out")
If I want to debug.Print (CanExecute <>Method : failed
Anyway my opinion is only my opinion
IMO : Debug.Print("method in") is not a high value log. Do I really want to see the method call chain for the entire application. And If I really do want to do that I can use Ninject to apply a log on start and end of every function anyway, without having to write a debug into every single method.
Yep. But AOP frameworks mangle with the compiled code, which I take issue with. DI interception does the same thing but yiu execute the code that you actually wrote
@Duga Yeah, this is just something I'm not keen on, you're using a static logger, you'll have no options now. You might want to add something with a little more finesse later, but you won't be able to.
but what can I say hey, I've just pushed 584 changed files :)
@gleachman tbh I'm ambivalent about losing the UI and only extracting Sub procedures... otoh your work is so much more solid than the pile of mud I had...
I'll try to resolve the conflicts and merge it tonight. I'll merge @awgaya's PR first and then pull everything. PR-freeze until @gleachman's work is merged, guys
@Mat'sMug I love testing. I only write with testing. So I'm only too happy if the only thing I contribute to this project is testing.... So long as no one minds me pulling classes to pieces, and increasing the accessability of loads of private methods
@Mat'sMug . I'm meaning unit testing, not black box testing.
you don't have to freeze PR's because of my merge. I only impact like 4 common classes. The other 560 odd are CRLF changes. In fact why don't I just rebase and then merge again
VBA Rubberducking
VBA Rubberducking