Forgot your password?
Sign in with
Article Help Forum
Submit an article or tip
Import GitHub Project
Import your Blog
Ask a Question
View Unanswered Questions
View All Questions
View C# questions
View C++ questions
View Python questions
View Java questions
All Message Boards...
Running a Business
Sales / Marketing
Collaboration / Beta Testing
Design and Architecture
Internet of Things
C / C++ / MFC
ATL / WTL / STL
Objective-C and Swift
Hardware & Devices
Hosting and Servers
.NET (Core and Framework)
Site Bugs / Suggestions
Spam and Abuse Watch
The Insider Newsletter
The Daily Build Newsletter
Most Valuable Professionals
Where I Am: Member Photos
The Insider News
The Weird & The Wonderful
What is 'CodeProject'?
Ask a Question
Bugs and Suggestions
Article Help Forum
Comments by PureNsanity (Top 18 by date)
I haven't done any performance analysis or benchmark testing; however, I can tell you hands down that SciChart blows away other standard charting libraries in that area. SciChart has a good amount available on performance online if you just search their site for it.
Have you tried increasing the OperationTimeout? Or does the call fail immediately?
To tack onto what Richard said... You can have XAML with named content that isn't part of the UserControl. For example, if you have named content within a template. If you're getting that compiler error it's very likely that's the case, but to tell you specifically why you'd have to include your XAML.
I'm not sure if you really need a callback here... You could just create a custom exception then have the client take action based on the exception type.
I understand this may not be possible; however, have you thought of upgrading the container? While I do still view Unity as valuable, it's a much older container implementation. Although I'm personally partial to MEF, Autofac is widely popular and also has Prism extensions. Autofac as a container also has many improvements and features over Unity... Just a thought....
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:
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.
Last Updated 1 Jan 1900
All Rights Reserved.