|
So I'm missing most of my cerebral material this morning. :/
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
I'm new to the unit-testing world and want to know how I can improve and write better tests 
|
|
|
|
|
Buy a book on the topic, find tutorials, and practice.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Any recommended book?
|
|
|
|
|
|
|
You're welcome
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
|
I have been researching a solution to this and have not found an answer so I thought I would ask it here.
I have an application that derives from System.Windows.Forms.TreeNode for a few of the classes. I want to create a "lockable" tree node for the base nodes of my tree which ensures that programmers don't accidentally (or purposefully) modify the nodes once they are "locked" because the base nodes are "immutable" while the rest of the tree is not. However, since I cannot derive from TreeNodeCollection and there is no c# equivalent of the C++ const method contract (that I have been able to find for properties), I am having trouble coming up with a way to prevent the following from happening:
someInstanceOfMyLockableTreeNodeClass.Nodes.Add("newNode")
The only thing I can think of is possibly hiding the original Nodes Property (using the new keyword) with a less accessible one (if that would even work). The problem is that I would no longer be able to access the node indexer either... so I would have to create a less intuitive wrapper for that as well. Is there a different approach that I could use?
|
|
|
|
|
You'd have to write your own. If you make the TreeNodes private, I'll simply use reflection to add my nodes (not accidentally, ofc).
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Before I switched to using the Integral UI TreeView (Lidor Systems) [^], I used the following strategy to wrap the native WinForm TreeView in a way that let me do multiple selection:
1. a UserControl 'TreeXHost in which a WinForm TreeView 'WFTree is docked 'Full: 'WFTree is set to DrawMode 'OwnerDrawText. WFTree is declared 'private.
1.a when 'TreeXHost loads: the instance of the WinForm TreeView, is passed into a class 'TreeX, a pretty standard tree implementation.
2. in 'TreeX : event handlers are wired up for all the TreeView events
2.a a variety of Dictionaries and Lists were used to keep track of state and enable custom node (not inheriting from WF TreeNode) <=>to WF Node lookup:
public Dictionary<string, Node> AllNodes { set; get; }
public Dictionary<string, TreeNode> AllTreeNodes { set; get; }
public Dictionary<TreeNode, Node> TNodeToNode { set; get; }
public Dictionary<Node, TreeNode> NodeToTNode { set; get; }
public List<Node> DisabledNodes { set; get; }
public List<Node> SelectedNodes { set; get; }So the basic idea was to isolate the WinForm TreeView completely, and present an API to use that behind the scenes inter-oped with the WinForm TreeView.
There were several reasons I chose not to sub-class the WF TreeView or TreeNode: of course, the issue/danger of exposing the "can't inherit from" TreeNodeCollection; the need to add some complex annotations to each node; ease of writing a serialize/deserialize facility, etc.
Yes, indeed. it got tricky: I ended up canceling every WF TV Event I could in the 'Before... Event Handlers; in the DrawNode Event you need to color the Node, or otherwise alter the TreeNode appearance based on its state. A design issue was whether disabling/enabling a Node with a non-empty TreeNodeCollection should recursively disable/enab;e every Node "under" it: I decided that was necessary. Not to mention issues of drag-drop
It got so tricky I went looking for a 3rd. party Treeview that I could afford ... and, I found the IntegralUI TreeView that was (and, still is) quite remarkable
Hope this is helpful.
«... thank the gods that they have made you superior to those events which they have not placed within your own control, rendered you accountable for that only which is within you own control For what, then, have they made you responsible? For that which is alone in your own power—a right use of things as they appear.» Discourses of Epictetus Book I:12
modified 4-Feb-18 1:09am.
|
|
|
|
|
Thanks for the info! It was helpful for future reference. For my current solution, I decided to use the hiding technique after evaluating my code and realizing I was over-complicating what I needed to do (due to having a separate artificial "node" class where I didn't need one).
But yeah... the capabilities of your link look promising if I need a more robust tree in the future. I am curious about the filtering though. Do you know if the filtering capabilities allow for you to hide or show nodes of a certain type?
|
|
|
|
|
@primem0ver One further comment:
If you implement, as I described, a kind of parallel tree class which manages an internal WF TreeView, then hiding Nodes is relatively simple, but:
The trade-off is that you'll have to re-render the WF TreeView every time you hide nodes, or show hidden nodes: imho, depending on frequency of hide/show calls, and your hardware, that might result in lower performance.
«... thank the gods that they have made you superior to those events which they have not placed within your own control, rendered you accountable for that only which is within you own control For what, then, have they made you responsible? For that which is alone in your own power—a right use of things as they appear.» Discourses of Epictetus Book I:12
|
|
|
|
|
Ok. That actually sounds fine. It won't be a big deal because the hiding of nodes is not depending on searching which can change as you type. It is dependent on what kind of nodes the user is trying to view... (almost like a file type filter) so changing that is not something that happens every second.
|
|
|
|
|
I'm working on an article for CP about a set of useful generic hierarchy extensions ... stay tuned.
As part of the article, I will show an example of hiding Nodes, and re-showing them, on demand.
cheers, Bill
«... thank the gods that they have made you superior to those events which they have not placed within your own control, rendered you accountable for that only which is within you own control For what, then, have they made you responsible? For that which is alone in your own power—a right use of things as they appear.» Discourses of Epictetus Book I:12
|
|
|
|
|
Suppose I need to capture the listView message and on the form have three listView, the variable m.Msg distinguish the listView1, listView2, listView3, ... and when run output message m.Msg variable in the attachment: http://www.mediafire.com/file/weab5ppsb355kc1/out_WndProc.doc
protected override void WndProc(ref Message m)
{
Debug.Print("out if: " + m.Msg);
if (m.Msg == WM_NOFITY)
{
Debug.Print("in if: " + m.Msg);
}
}
|
|
|
|
|
I currently run into the problem to update WPF controls from a worker thread.
After searching on Google for hours I hope to get an answer here.
Situation:
- I do have a GUI
- The GUI has a viewmodel attached to it
- The videmodel contains all properties for the binding. This contains int, float, bool and string property values as well as an int[] array.
- All properties look like this:
private volatile string _InputTypeString = "";
public string InputTypeString
{
get { return _InputTypeString; }
set { _InputTypeString = value; OnPropertyChanged("InputTypeString"); }
}
- All of the controls are bound to the viewmodel via XML bindings
- When I do not use the GUI updates, my Code runs fine for hours and as soon as I update the GUI I run into problems within a couple of minutes.
What I have tried:
What I have already tried:
- make all variables of the property objects volatile
- delegates via
Action b = delegate { windowmodel.Frame_Current = FrameX };
Application.Current.Dispatcher.Invoke(b, DispatcherPriority.Normal);
- locks
lock (windowmodel.AudioLevelArray)
Any idea how to get the GUI related properties thread-safe?
|
|
|
|
|
For most properties, what you've got should already be safe to update from a background thread, even if you remove the volatile modifier. WPF automatically ensures that the bindings are updated on the UI thread.
You might run into problems updating collections from a background thread, but there's an easy workaround in .NET 4.5:
WPF 4.5: Observable Collection Cross-Thread Change Notification - Pete Brown's 10rem.net[^]
If it's still not working, then you must be doing something odd. Post the full details of the error you're getting, and the relevant parts of the code it relates to.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
How have you defined your ViewModel? You haven't created it as a DependencyObject have you? If you have, your properties have to have thread affinity.
This space for rent
|
|
|
|
|
I have the example below, I want to cancel LINQ how to write ?
static void Main()
{
List<int> list = new List<int>();
list.Add(7);
list.Add(11);
list.Add(13);
bool exists = list.Exists(element => element > 10);
Console.WriteLine(exists);
exists = list.Exists(element => element < 7);
Console.WriteLine(exists);
}
|
|
|
|
|
The only Linq code you have in there are calls to Exists. That is a "monolithic" function, and can't be cancelled in a "normal way" once it is started.
But with that little data, you aren't going to have long enough to cancel it anyway! 
What are you trying to do that you think you need to do that?
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
List<T>.Exists[^] is not a LINQ method.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
If you want to quickly see where in your code Linq is required: comment out the using System.Linq; statements in your code. Then, compile, and see where the error messages occur.
«... thank the gods that they have made you superior to those events which they have not placed within your own control, rendered you accountable for that only which is within you own control For what, then, have they made you responsible? For that which is alone in your own power—a right use of things as they appear.» Discourses of Epictetus Book I:12
|
|
|
|
|
You don't even need to compile. Intellisense will light your code up like a Christmas tree.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
True, John, but the "benefit," if you have a lot of code ... perhaps scattered around many classes/code edit windows ... is that error messages when you try to compile are handily broken out for you, and all you gotta do is double-click on one to jump to the context/place where that error occurred.
Maybe I'm missing something here ? I never have the OP's problem thanks to ReSharper which flags a missing system library/dll, and will offer to load it for you the moment it's needed.
cheers, Bill
«... thank the gods that they have made you superior to those events which they have not placed within your own control, rendered you accountable for that only which is within you own control For what, then, have they made you responsible? For that which is alone in your own power—a right use of things as they appear.» Discourses of Epictetus Book I:12
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
