|
This is weird. Just copy-pasted your code.
- VS 2013
- .net 4.5
- debug and release
Works as expected.
Best,
John
-- Log Wizard - a Log Viewer that is easy and fun to use!
|
|
|
|
|
Hi, thanks for replying. I think I know what the problem is. In my actual code I set the size of the array to 10 but inserted data into only three of the elements.
So my question is how do I test for null values when converting an array to a dictionary. Thanks for your help.
modified 16-Mar-16 18:29pm.
|
|
|
|
|
The most obvious solution would be to use List<Product> instead of Product[], and then use Products.Add(...); to populate the collection.
List<Product> products = new List<Product>;
products.Add(p1);
products.Add(p2);
products.Add(p3);
"Fairy tales do not tell children the dragons exist. Children already know that dragons exist. Fairy tales tell children the dragons can be killed."
- G.K. Chesterton
|
|
|
|
|
Just add a where clause in your code like this:
Dictionary<int, Product> productlist = products.Where(b => b != null).ToDictionary(p => p.ProductSkew, p => p);
This will ignore all the null products and convert the rest into dictionary.
|
|
|
|
|
Thank you Mathi, your solution works great. Also I will keep everyone else's suggestions in mind as they are all very valuable, thank you all.
|
|
|
|
|
MadDashCoder wrote: Dictionary<int, Product> productlist
Maybe it's because it's just a code sample but here you don't actually make use of the dictionary as such because you don't use its keys - a list would suffice. If it actually has to be a dictionary then I'd suggest you don't name it productlist 
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
MadDashCoder wrote: Product product = new Product();
product = item.Value;
There's no point creating a new Product if you're just going to throw it away on the next line. Just use:
Product product = item.Value;
MadDashCoder wrote: ProductSkew
I think you meant to write ProductSku - a Stock Keeping Unit. "Skew"[^] has a totally different meaning. 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
The fixed size array is a nono, this is where you should use some kind of a collection, probablye the List<Product> Matt already suggested.
But if you know beforehand you will need a Dictionary (not sure you do!) maybe you could stuff the fresh products in the dictionary right away?
PS: your Product class deserves to have a constructor that takes the basic values as parameters...
PS2: ... as well as a ToString() to return a formatted representation of itself.
|
|
|
|
|
Message Removed
modified 16-Mar-16 12:40pm.
|
|
|
|
|
I use:
private int _MyProperty
public int MyProperty
{
get { return _MyProperty; }
set { _MyProperty = value; }
}
private int myField;
public void MyMethod(int myField, int myProperty)
{
this.myField = myField;
_MyProperty = myProperty;
}In other words, I only use this when I need to pass the current instance to a method, or need to disambiguate two identical names. And anything starting with "_" is a backing field for a property.
This is (I believe) consistent with the recommended naming practices (which I can't find at the moment, damn it!)
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
OriginalGriff wrote: This is (I believe) consistent with the recommended naming practices
Hasn't been that way for a while I'm afraid. MS recommend against using the underscore[^].
This space for rent
|
|
|
|
|
That pretty much contemporary with the Net 1.1 version - if you look at the bottom it's copyright 2005!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
|
I do not know what a Valley Girl is, but it sounds from the context as though it is a derogatory statement implying a sexist viewpoint. Not appropriate for this site.
However, at the risk of being called a Valley Girl, I use this for all class member etc. I only use unadorned (i.e. not prefixed by scope + '.') for method local variables (ones that disappear when you exit the method / property) and global variables (NO! PLEASE DON'T USE GLOBAL VARIABLES! (unless you have inherited some code from the 1960s)). Anything associated with the class is prefixed by this, anything associated with another object is prefixed by the object variable name. This (no pun intended) ensures that everything is explicit. Never give future readers / maintainers the option of misunderstanding. OK, my source code may be a bit bigger with all of the this's but that is a small price to pay for clarity.
|
|
|
|
|
And if you refactor a field starting with "_" in VS it automatically removes the underscore:
private int _MyProperty;
public int MyProperty
{
get { return _MyProperty; }
set { _MyProperty = value; }
}
If you don't start with an underscore you get Yeuch!
private int MyProperty;
public int MyProperty1
{
get { return MyProperty; }
set { MyProperty = value; }
}
So I guess that MS's right hand isn't talking to it's left hand again... 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
They are two different issues.
"This" can reference any field, property or method.
"_" is simply a prefix used to indicate (by past convention) that this is a "private field", regardless of whether it is a backing store or not.
It was a shorter version of the C/C++ convention which used "m_..." for its "members" (and which still finds its way into other languages).
"_" always implies "local to this instance" (and therefore "this" is assumed).
But that's just me 
|
|
|
|
|
|
Forgot to add that "_" also tells me it's not a "local variable" or "parameter", since they would otherwise all have the same name (using conventional camel-case rules).
|
|
|
|
|
MS doesn't follow their own naming conventions...
All my class members are PascalCase, all parameters/local variables are camelCase. So I don't need the this-keyword to initialize a class member from a constructor parameter and I don't use it anywhere else either. The leading underscore I only use if I happen to need an "explicit" backing field for a property.
I like it like this because: Looking at the first letter instantly tells you if it's a class member or a local identifier. No syntactically unneccessary visual this-clutter or underscore-clutter with the mentioned exception where it actually serves a purpose.
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
|
N_tro_P wrote: That is what Griff said he does as well.
Not quite - Griff seems to use pascalCase for fields, requiring a this for initialization from parameters.
N_tro_P wrote: So what do we do here? Should they have an underscore?
I should have been more precise: I use the underscore only for a field if there is a property which returns that one field and possibly sets that one field (which introduces the problem of wanting to name the field like the property). So in your example I wouldn't use underscores because the properties return computed values, thus have a different meaning than any field and therefore will be named differently from any field.
N_tro_P wrote: where this fails is when extensions occur. A new requirement is added to a component that is a simple one. Expose someField with a public accessor. Now you must modify all usages of the field.
Yes, unless you can just change the field into a property. Lacking any sort of co-worker this hasn't been a problem for me
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
|
N_tro_P wrote: That is why we have auto-properties.
No, I didn't mean auto properties. I meant properties which, albeit reading and setting only one field, do a bit more than that, e.g. checking whether the new value is actually different to fire a PropertyChangedNotification only then.
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
|
Auto-properties are not the same as a "private backed" property that just sets or returns the private field value. For example, an automatic property can't be used within the class as an out or ref call to a method. (And until fairly recently couldn't have a default value).
I really don't like exposing fields at all - it forces the design to remain unchanged - and you can't just "promote" a field to a property later because of the possible external use of the fields as out or ref parameters.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
