View Single Post
  #11 (permalink)  
Old May 16th, 2008, 02:57 AM
jimibt jimibt is offline
Friend of Wrox
Join Date: Mar 2007
Location: Creetown, UK
Posts: 488
Thanks: 2
Thanked 11 Times in 10 Posts

quote:Originally posted by LAM
quote:Originally posted by Lee Dumond
 Your UpdateProduct method seems to have uniCost instead of unitCost as a parameter. Could that be it?
Apparently the problem is solved. You were right!!! I had uniCost (no "t" in unit) as a parameter in the UpdateProduct method. I was looking at other overload of the same method that had the correct unitCost parameter.

Anyway, shouldn't .net care about the type of the parameter (string, int, etc) and the position (method signature) instead of the actual name of the parameter??

Thanks so much for your help!!! I really appreciate it.

Take care.

LAM - the name of the parameter (as well as obviously the type) coming from the aspx page is important as .net uses reflection to match this up at IL level. But you've learned thro' an unfortunate circumstance (i.e. an actual published typo) that this is the case. equipped with that knowledge, it's probably unlikely that that particular nuance or error will occur again in your quest :D. another great example of this is action is the 'invisible' paging parameters which have default names of startRowIndex and maximumRows. you'll notice that if you give your BLL class method different parameter names for these values (i.e. startRow, maxRow) that a similar error will be thrown by the compiled code. trying to track that down can be a nightmare unless you know about this quirk.

i'd recommend also that you download the codeplex version of the code just so you know how the final rendition looks/feels.