|
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...
|
|
|
|