« first day (1153 days earlier)      last day (2027 days later) » 
00:00 - 19:0019:00 - 00:00

7:04 PM
@Mat'sMug I apologize my friend, but I have another question for you. You around?
 
7:42 PM
@shadowofsilicon what's up?
 
I got the unit test(s) working like I would expect them too (more or less..)
But, I am having problems with the ExportAllCommand : https://github.com/shadowofsilicon/Rubberduck/blob/Export_Import_All/RetailCoder.VBE/UI/Command/ExportAllCommand.cs#L61
 
@Mat'sMug Are you suggesting removing all instantiated loggers? I was thinking being able to remove a selected one only, but then I realized that I .Register one by creating a Logger and passing it in, but I don't keep the Logger around, so I don't know its name to kill it off.
Also, I'm not yet at the point of wanting/needing multiple loggers in a single app. Not sure of the value or logistics of that either...
 
ExportAllCommand creates a FolderBrowserDialog that is shown during OnExecute... But, I want to give it a .RootFolder based on the active project at Execution time. When I step through it, I can see that _folderBrowser is changed; but the dialog that appears at _folderBrowser.ShowDialog() is not changed
 
@shadowofsilicon I don't understand. What do "changed" and "not changed" stand for?
 
When I step through and mouse over _folderBrowser I can see that the properties have been updated to what I set them to at lines 59 through 61. But when the dialog appears, those changes are not in effect.
 
7:52 PM
Also an unsaved project will give you an empty string. Consider making the root My Documents in that case.
@FreeMan you can have one output ERROR level and up to the debug pane, and another one output TRACE and up to a text file
 
For example, although it appears via the code window that I successfully changed _folderBrowser.Description to "asdf", the dialog that appears still has "Select a folder to Export All..." in the window title, and the location is set to the default Documents library.
@Mat'sMug Yes, of course. I remember something about make it work, then make it right... ;)
 
Also project is already a reference to the active project. Why fetch it again to get its filename?
Anyway is the dialog disposable?
If that's the case then you should have the factory as a field, not the dialog
Then do
using(var dialog = _factory.Create(foo)) {...}
 
I think I have a new leead regarding the tear down problems: we never dispose of the HostApplication.
 
That way you get a fresh new instance everytime
 
In other words, we never release the COM handle.
 
7:59 PM
@M.Doerner huh, is it not IDIsposable?
we're binding it in a non-disposed scope?
e.g. TransientScope
(the default)
We had HostApplication before 2.x though
 
We are not binding it.
 
@Mat'sMug ah! Is my assessment of the .Remove and .Clear functions reasonably correct? i.e. .Remove isn't possible because we don't have the logger.Name to be able to remove just one?
unless, of course, I store them off somewhere...
 
We call Dispose from the finalizer, but that never really runs.
I have put a Debug.WriteLine in there and I get no output before the crash.
 
Interesting
@FreeMan I'd just have a Clear method. KISS.
 
Maybe, we have been relying on Ninject for something it was not set up to do.
 
8:06 PM
Using statement.... C#MindBlown =)
 
But we get a host app from where? No binding means we can ctor-inject it anywhere, so... we have a factory method in the VBE wrapper that spits out host app instances that we never clean up?
 
@M.Doerner never!!!
 
@shadowofsilicon every disposable wants a using scope =)
 
I see that now... Reading the Fine Manual on using =)
 
See, shit happens when you don't clean up properly!
4
 
8:09 PM
@Mat'sMug like the dog who keeps peeing on the carpet in the same spot every time?
 
I guess you could say that
 
So, I don't have to "clean up" or call Dispose or anything after the using statement, because the IDisposable will be disposed at the end of the using block? Is that correct?
 
Duh check: When one uses a cast that immediately precedes accessing a member (foo)bar.buz the precedence is the cast before the . (dot accessor)?
 
I don't know wth you mean with "too obvious". Agreed, global variables aren't exactly nice, but document variables are just as global and just as easy to modify- no idea what you're trying to obfuscate and why, but I doubt there's any purpose to it. And yes, you can put variables in add-ins... but now I regret suggesting that. What are you trying to do????? — Mat's Mug 12 secs ago
walks away slowly
@shadowofsilicon correct
@IvenBach try it (and be disappointed). You need parens there, so.. nope. Member access has precedence.
 
I added the disposal of the HostApplication to the shutdown code in Extension. Unfortunately, I still get the error in combase.dll.
 
8:18 PM
@Mat'sMug Below is the example I'm working on.
public class Program
    	{
    		public static void Main()
    		{
    			var horse = new Animal() { Name = "Ed" };
    			var type = horse.GetType();

    			//var property = type.GetProperty("Name");
    			var method = type.GetMethod("Speak");

    			//var value = property.GetValue(horse);
    			var value = (string)method.Invoke(horse,null);

    			Console.WriteLine(value);
    		}
    	}

    	public class Animal
    	{
    		public string Name { get; set; }

    		public string Speak() { return "Hello"; }
The (string) cast is superfluous and was what wasn't making sense to me. Since WriteLine implicitly invokes ToString() AFAIK. It just returns a string. Tested it with Console.WriteLine(value.GetType());
I like being able to walk through and dissect examples in order to figure out the answer to questions I have. So much better than being spoonfed all the time.
 
@Mat'sMug The .ShowDialog and the checking of DialogResult will be within the using block, right?
 
@shadowofsilicon yes
 
> Rubberduck isn't getting fully unloaded, even when unloaded manually by the user, with toolbars, menubar entry, and dialogs still remaining.

Not only does this cause a series of unhandled exceptions dialogs to be shown for the exact same exception when attempting to reload Rubberduck, but it may also be a root cause of the issue with Access, Excel, etc. crashing on exit, and sometimes automatically restarting, after VBE with Rubberduck was opened.

I attempted to debug this, I also noti
 
@Mat'sMug ...And it's doing the same thing.
 
@Duga Isn't this listed as a know issue and strongly recommended against?
 
8:30 PM
@FreeMan yes, and it's indeed strongly related to the crash on exit. SlimDucky unloads without issues.
And reloads
@shadowofsilicon what's the FolderBrowserDialog doing in its ctor?
 
1
Q: Manipulating data into a certain format

bananaI have a data sheet with 5 columns and roughly 350 rows. I copy paste it into another sheet and the macro formats the data into something I can use. It ends with 12 columns and roughly 10 more rows than original. The code works but it runs slowly and worse, after it finishes, Excel becomes reall...

 
> It may be that just fixing this incomplete unload issue
No shit
indeed we need to get RD to fully unload... and that's the hard part.
 
@Mat'sMug With regards to string interning, are properties or the value of the property interned as well?
 
@Mat'sMug It shouldn't be there?
 
8:38 PM
???
 
The lack of unloading the menu items is due to the fact that the corresponding code has been commented out.
 
> Issue 1: To be fair, unloading/reloading RD is a [known issue](https://github.com/rubberduck-vba/Rubberduck/releases?after=Rubberduck-v2.1.1973) and it's recommended that you do not do that.

I agree that issue 2 is a major annoyance and have asked about it several times. I've been told that it's up to the VBE to place the tool bar and that RD has no control over it. If you know otherwise, I'm _sure_ the devs would be thrilled to hear about the method for doing so.

Issue 3: See Issue 1
 
@Mat'sMug My understanding is that ExportAllCommand recieves an instance of IFolderBrowserFactory when loaded by Ninject... is that correct?
 
> Issue 1: To be fair, unloading/reloading RD is a [known issue](https://github.com/rubberduck-vba/Rubberduck/releases?after=Rubberduck-v2.1.1973) and it's recommended that you do not do that.

Issue 2 is a major annoyance and have asked about it several times. I've been told that it's up to the VBE to place the tool bar and that RD has no control over it. If you know otherwise, I'm _sure_ the devs would be thrilled to hear about the method for doing so and will make the requisite changes.
 
@M.Doerner LOL
@Duga Wow, I felt really defensive as I wrote that up, and I've really got no skin in the game (as yet).
 
8:43 PM
 
@FreeMan Agreed. Even I felt annoyed when I read that issue, and I'm as new as they come lol
 
@Duga I guess he likes us, though.
 
@Duga We are not even using an ElementHost. I think we should though.
 
9:00 PM
TTFN
 
> @daFreeMan to be fair, the incomplete unloading (never mind the crashing) *is* quite likely the reason why unload+reload is a problem.

I want to say something about the RD commandbar though. It's *much* more than a button and a status label; on a parsed project you get context-sensitive information right there, including the kind & type of identifier you're on, and if there's a docstring or a `@Description` annotation (or `VB_Description` attribute), you get that, as well as the number of r
> That said, not experiencing the crashes on my machine makes it pretty damn hard to debug them.
 
@M.Doerner we are... docked inside a UserControl :)
 
9:16 PM
Yes, but we could fill the UserControl with an ElementHost that hosts the WPF Control and hanldes all the WinForms WPF interaction.
 
> Thanks for getting back so quickly on this.

@retailcoder
Btw, what is the known issue number for reload issue? You linked to a release version.

## Issue 1:

I'm not that concerned about about reloading.
I'm concerned that Rubberduck is failing to even hide, let alone properly dispose of, WPF elements, toolbars, menu, etc. even when manually unloading the add-in.
If it can't do so then, even with no tool windows/dialogs shown, then I doubt crash-on-exit could be resolved.
The fail
 
@Nick_Craver Whoever still uses ninject needs to be fired, hasn't been updated in years and everyone should know how bad it is
 
Hm, we have not been caching the HostApplication. So, I have been disposing the wrong object.
 
> Issue 5: Unhandled Exceptions

@retailcoder
You mentioned this is something being looked into with SlimDuck.

Do you mean just fixing exceptions, or specifically the addition of AppDomain.UnhandledException, etc. handlers as a fallback in worst case?
Such global handlers (ideally in addition to adding more try-catch's, in WndProc, etc) may possibly help avoid crash-on-exit if you fully handle there. But, at very least, you could use them to avoid showing repeated not-very-user-friendly
> Issue 5: Unhandled Exceptions

@retailcoder
You mentioned this is something being looked into with SlimDuck.

Do you mean just fixing exceptions, or specifically the addition of AppDomain.UnhandledException, etc. handlers as a fallback in worst case?
Such global handlers (ideally in addition to adding more try-catch's, in WndProc, etc) may possibly help avoid crash-on-exit if you fully handle there. But, at very least, you could use them to avoid showing repeated not-very-user-friendly
> Issue 5: Unhandled Exceptions

@retailcoder
You mentioned this is something being looked into with SlimDuck.

Do you mean just fixing exceptions, or specifically the addition of AppDomain.UnhandledException, etc. handlers as a fallback in worst case?
Such global handlers (ideally in addition to adding more try-catch's, in WndProc, etc) may possibly help avoid crash-on-exit if you fully handle there. But, at very least, you could use them to avoid showing repeated not-very-user-friendly
> Thanks for getting back so quickly on this.

daFreeMan
Btw, what is the known issue number for reload issue? You linked to a release version.

## Issue 1:

I'm not that concerned about about reloading.
I'm concerned that Rubberduck is failing to even hide, let alone properly dispose of, WPF elements, toolbars, menu, etc. even when manually unloading the add-in.
If it can't do so then, even with no tool windows/dialogs shown, then I doubt crash-on-exit could be resolved.
The failure
> Thanks for getting back so quickly on this.
@daFreeMan
Btw, what is the known issue number for reload issue? You linked to a release version.

## Issue 1:

I'm not that concerned about about reloading.
I'm concerned that Rubberduck is failing to even hide, let alone properly dispose of, WPF elements, toolbars, menu, etc. even when manually unloading the add-in.
If it can't do so then, even with no tool windows/dialogs shown, then I doubt crash-on-exit could be resolved.
The failure
> Thanks for getting back so quickly on this.

@daFreeMan

What is the known issue number for reload issue? You linked to a release version.

## Issue 1:

I'm not that concerned about about reloading.
I'm concerned that Rubberduck is failing to even hide, let alone properly dispose of, WPF elements, toolbars, menu, etc. even when manually unloading the add-in.
If it can't do so then, even with no tool windows/dialogs shown, then I doubt crash-on-exit could be resolved.
The failure t
> Issue 5: Unhandled Exceptions

@daFreeMan

You mentioned this is something being looked into with SlimDuck.

Do you mean just fixing exceptions, or specifically the addition of AppDomain.UnhandledException, etc. handlers as a fallback in worst case?
Such global handlers (ideally in addition to adding more try-catch's, in WndProc, etc) may possibly help avoid crash-on-exit if you fully handle there. But, at very least, you could use them to avoid showing repeated not-very-user-friendly
> Issue 5: Unhandled Exceptions

@daFreeMan

You mentioned this is something being looked into with SlimDuck.

Do you mean just fixing exceptions, or specifically the addition of AppDomain.UnhandledException, etc. handlers as a fallback in worst case?
Such global handlers (ideally in addition to adding more try-catch's, in WndProc(), OnDisconnect(), etc) may possibly help avoid crash-on-exit if you fully handle there. But, at very least, you could use them to avoid showing repeated not-
 
@Mat'sMug @Hosch250 Thanks for having me start with reading the mind-numbing boring basics stuff. I keep RubberDuckin' my way through examples and answering my own "wtf is that, how's that even work" questions shortly digging through MSDN. #WarmFuzzies
 
9:32 PM
> All dockable toolwindows are essentially a WinForms `UserControl` with a fill-docked WPF `ElementHost` - what you're seeing in that stack trace is probably one of these dockable toolwindows unloading, as most toolwindows have WPF toolbars (inside that ElementHost). We're considering skipping the `UserControl` part and using the `ElementHost` directly, but I doubt that will make a difference other than reducing the depth of the Window layouts (which can't hurt, TBH).

Menu items are 100% COM,
> @retailcoder
Yea, I can sympathize with difficulty of debugging and fixing without being able to reproduce.

When it came to Excel and other apps, crashes were still occurring, but I only noticed them recently when checking Event Viewer, since there was no error box shown, and no auto-restarting the app, unlike Access.
(On that note, anyone know why WERFault handling of Access crashes is so different vs Excel and other Office apps...?)
Do you happen to see any such error entries in Ev
 
@Mat'sMug @Duga When unloading RD, the windows do not get garbage collected because they have a GC handle that they only free when receiving a WM_DESTROY.
Since we never get that message as the VBE prefers to not destroy windows until it shuts down, these handles are only freed on shutdown.
 
@Mat'sMug Self-flagellating there sir?
 
> Right, same case for manual vs on-exit unloading, but I was thinking may be easier to debug with manual unload, and followup reload possibly too.
Though I thought someone had mentioned in #3018 comments something about crash-on-exit possibly involving some timing-related issues.

Is there any possibility of JIT creation of tool windows, either whether with or without continued NInject usage? That would avoid the crash-on-exit in many cases, and possibly help pinpoint,
Also, can you entirel
> Right, same case for manual vs on-exit unloading, but I was thinking may be easier to debug with manual unload, and followup reload possibly too.
Though I thought someone had mentioned in #3018 comments something about crash-on-exit possibly involving some timing-related issues.

Is there any possibility of JIT creation of tool windows, either whether with or without continued NInject usage? That would avoid the crash-on-exit in many cases, and possibly help pinpoint.
Also, that would redu
> We're not the ones hiding and resizing toolwindows - that's the VBE's own doing!

I'm running Office 2010, 32-bit at work and 64-bit at home, same exit code 0 on both (I don't have MS-Access), and also in Sage 300 ERP.

Creating the toolwindows the first time they're needed would definitely speed up the startup, but then there would be a lag the first time it's opened... not sure it's a win. Getting the UI out of Ninject's hands sounds like a plan though - but then manually injecting the d
 
9:58 PM
@Mat'sMug Did I get that correctly that the CommandBar is COM-based?
In that case, not unloading it might be the reason why the combase.dll throws.
 
> Many times I will open and use VBE without showing, let alone using, any Rubberduck tool windows.
More importantly, I can't even click on a tool window from Rubberduck menu in order to show it until I click on Pending in toolbar and wait for all the parsing.
So I think the delay wouldn't be very noticeable or even occur at all unless someone has all windows always shown at startup (in which case, it doesn't matter, as first thing one does probably won't be to use addin tool windows).

On t
 
10:18 PM
> The Dockable and Hide context menu items are missing from context menu shown when right-clicking on toolbar Ruberduck tool windows.
Because of this, if user ever right-clicks on the docked tool window's docked mode titlebar and unchecks > Dockable, then the tool window gets moved to a document tab, and, unlike all built-in or other add-in tool windows, there is no way to change it back to Dockable *ever*, even after unloading, restarting Access, clicking menubar entry for the window, etc.
> Rubberduck's VBE toolbars are the only toolbars ones which don't persist where they were placed or whether they were hidden. MZ-Tools, other addins, built-in toolbars, etc. all do so correctly.
Also, Rubberduck seems to be the only one to create its own toolbar row, even when there is sufficient space in existing toolbar row.

If you try moving the toolbar to a different row or in between 2 other toolbars (from add-ins and/or built-in ones) you restart Access, Excel, etc. you will see it go
> @daFreeMan, @retailcoder

> Issue 2 is a major annoyance and have asked about it several times. I've been told that it's up to the VBE to place the tool bar and that RD has no control over it. If you know otherwise, I'm sure the devs would be thrilled to hear about the method for doing so and will make the requisite changes.

See Issue #3215 I just created. Toolbar's failing to persist position and visibility only happens with Rubberduck, not other addins.


Also, I just reported issue
 
10:46 PM
@Mat'sMug What would I have to do to make RD not create its command bar?
Hm, all the CommendBarControls on the RubberduckCommendBar have id 1.
 
11:12 PM
All the CommandBarControls we create with the help of the CommandBarFactory have the same id 1. That cannot be right. Moreover, this means that we are not cleaning up the buttons from the command bar sinse we cannot find them by id.
TTGTB
Btw, I added a try catch block around the shutdown. This had no effect; the crash happens in the combase.dll long after the shutdown procedure.
 
> In all likelihood we're crashing before the VBE gets to persist commandbar position/visibility, because that is also something I can't repro.
 
@M.Doerner yeah, it's Office interop
@M.Doerner thanks! 'night!
 
11:31 PM
I guess this sums up today pretty well:
The expectations of widely adopted opensource projects are indistinguishable from most software businesses.
 
@Mat'sMug IDK - There's a certain degree of apathy with LOB apps. Oh, that'll take 2 years, and budget, and effort, and politics.... I'll just hack it up in VBA and move on.... 2 years later, the VBA hack is a critical business risk. With OSS, people expect huge leaps to occur in quick succession.
 
Still, that whole thread rings a bell
@_inc0_ @kelseyhightower Depends. I know a VBA plug-in build by C# devs that don't all do VBA =)
@kelseyhightower There are differences. Community rarely make features from user requests. Most of the time they cr… https://twitter.com/i/web/status/892759459059032064
 
11:49 PM
@Duga I'd like to hear what the main players think about seeing issues like this. I agree with PowerAccess that window persistabiliy needs to be improved, but I chose not to create an issue given how many other, more important, improvements need to be addressed first.
 
> this lack of persistence is probably related to the tear-down issue.
 
00:00 - 19:0019:00 - 00:00

« first day (1153 days earlier)      last day (2027 days later) »