Comments by PureNsanity (Top 18 by date)

When changing just the build properties, you may need to rebuild the project. Not going to put this as a solution because I have never actually bothered to take the time to research the validity, but for my projects it's what I recall needing to do (and am doing now).

I'm going to take a guess... Is this because an application isn't closing out properly? And you want to kill any stranded/hung application when you start up a new instance?

Are you talking about using the filtering capabilities that Excel has? I'm not sure what adding a column has to do with filtering, but if you are talking about the rich filtering capabilities then you've got to use a third party library or build them yourself. If you need to do simple filtering based off a text box or other value, then the CollectionViewSource is the way to go.

Is there a reason you have to use, or are limited to, named pipes?

The OP said:

Quote:OP said:
The application I am writing has a configuration step in its startup

I would not consider any startup or Bootstrapper code to be VM.

There's also a lot easier ways to create glue from control to control, and between VM and control than proxies... While a proxy can be a good way to solve it in some instances, DependencyProperties, Converters, and Commands are made for that without having to manage an additional proxy class.

I'm letting you know without the information provided it's impossible to tell - you would only be guessing. I'm not trying to tell you about all the ways, just saying I need to see the requested information or I won't be able to tell you.

Can you provide a sample strJson that is deserializing to null?

There are a lot of potential reasons why a WPF style won't get applied as expected. Any changes to style applied directly to the element will have highest precedence, so if you're not seeing that happen I'd start there. Could you provide a snippet with the TextBox and ContextMenu XAML?

Correct. Mixed it up. Wanted to acknowledge that but will delete the answer since it's off. Thank you.

Don't forget the Observable.Interval. If you're using Rx anyway I feel it's the optimal choice.

That error is likely going to be deep in the call stack. When debugging make sure to have the exception settings set to throw all exceptions so hopefully while debugging you can see where this is originating from.

DockPanel, Border, and Grid are all bounded so those won't be it. If you're using VS 2015 it has a visual tree inspector built into the debugger, but if you're using previous versions tools like WPF Inspector can help readily identify the offending object. StackPanel is probably one of the most common ones, but another that could be counter-intuitive is the ScrollViewer. A ScrollViewer is actually unbounded... If you're looking up the visual tree and you're not sure which control is or isn't, one easy way to test is by setting the height of the containers to a fixed value going up the tree. Set the value as a fixed value, test, and move up the tree. Whenever you move up and it goes from fixed height to unbounded growth, you know a container underneath it is an offending container. You may have to go through this process multiple times up to the root window.

Reason for my vote of 1 \n You need to revisit your knowledge on IoC. It's not a "phenomenon" and all the techniques you listed aren't what makes it IoC. There's a huge gap in actually explaining what it is and the various ways it's implemented in modern techniques.