:thumbsup:

Good catch. I read right over that.

Thanks for the clarification, keefb. keefb wrote: If I understand you correctly, by passing the formula as a string will require the current class to be responsible for performing the parsing as well as whatever this class is meant to do with the result, this is probably bad object encapsulation. Agreed. But the class is not actually responsible for the parsing or evaluation (it passes those tasks off to another class), nor is it responsible for acting on the value. The class just holds on to expression tree created by parsing the formula and uses it to provide a value when requested. Perhaps my original example was over-simplified. keefb wrote: ...unless you are parsing text entries from a user or some other source (e.g. text input from a UI or file), writing formulas in strings and then evaluating them is bad design... This is exactly what I am doing. The formulas are read from user-created XML files and used to control the program's behaviour. This is fun... every criticism you offer just seems to confirm that I'm doing it correctly :laugh: . Keep going, keefb... one more critique should cement that I'm the bona fide genuis that I always knew myself to be:cool: (no matter what those jerks at Mensa had to say :mad:) Clive Pottinger Victoria, BC

Great. Happy to help :thumbsup: Navaneeth How to use google | Ask smart questions

Perhaps I need to clarify further. I would like to deserialise this XML <fleet> <auto type="car">boss's limo</auto> <auto type="truck"/>delivery truck</auto> <auto type="car">employee's rusty corvair</auto> </fleet> into these classes public class AutoClass { ... } [XmlRoot("fleet")] public class FleetClass { [XmlElement("auto") public AutoClass[] Vehicles { ... } } public class CarClass : AutoClass { ... } public class TruckClass : AutoClass { ... } so that XmlSerializer s = new XmlSerializer( typeof( FleetClass ) ); TextReader r = new StreamReader( "example.xml" ); FleetClass myFleet = (FleetClass)s.Deserialize( r ); AutoClass[] myVehicles = myFleet.Vehicles; should result in myVehicles containing 2 objects of type CarClass and 1 object of type TruckClass - not 3 objects of type AutoClass. Edit: I know I could change the <auto> tags to <car> and <truck> and collect them in the Vehicles property - but that is not the goal. The XML tag should remain as <auto> but the objects created need to be of types CarClass and TruckClass. Is there any way to decorate the classes and properties to accomplish this? Clive Pottinger Victoria, BC modified on Thursday, July 23, 2009 12:11 PM

Thank you too, Mika Clive Pottinger Victoria, BC

Thanks guys - but I found the cause of the problem... P.E.B.K.A.C.! I was actually rewriting the routine to use Convert() (thanks Greeeg), when I noticed that I my error message was printing out the wrong info - instead of saying that the parm was "of type passedParmType; requiredParmType was expected", it said it was of "type requiredParmType; passedParmType was expected"! That led to finding other places where I had mixed up the two references (due to an ambiguous naming convention). Once I fixed that I found that my code was actually working correctly and warning me that I was trying to use an Int32 as a value to an Int16 parameter. :doh: Perhaps I should consider a change of career. I hear that Air Traffic Control is less stressful... and apparently the FAA is much more lenient about minor errors than IT managers. Clive Pottinger Victoria, BC

Hi Clive, I continued looking for a way without calling GetEnumerator explicitly, and this now works fine for me: public override void Run(int arg) { Type type=Type.GetType("LPExplorer.CPTest_Enumerator+MyList"); log("type="+type); IEnumerable aList=System.Activator.CreateInstance(type) as IEnumerable; log("aList="+aList); if (aList!=null) foreach (string s in aList) log(s); } public class MyList : IEnumerable { private List list=new List(); public MyList() { list.Add("aaa"); list.Add("bbb"); list.Add("ccc"); } public IEnumerator GetEnumerator() { return list.GetEnumerator(); } } So once the object (aList) exists I don't need reflection to enumerate, provided I know (or the code somehow finds out) what the type of the items is. As I mentioned before, aList must be an object, i.e. an instance; it would not work on static classes. :) Luc Pattyn [Forum Guidelines] [My Articles] Voting for dummies? No thanks. X|

cpotting wrote: I must say that I am surprised that this seems to have been overlooked when the XML documentation ability was being created. It seems (to me, at any rate) to be an obvious feature to be included - much more so than the <seealso> or <include> tags. I agree. You may want to check the Sandcastle documentation, as it may support the overloads tag. Scott Dorman Microsoft® MVP - Visual C# | MCPD President - Tampa Bay IASA Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai [Forum Guidelines][Articles][Blog]

Well I've had two years of learning from some of the best ;) led mike

Sure thing. Hope it helps. Visit BoneSoft.com for code generation tools (XML & XSD -> C#, VB, etc...) and some free developer tools as well.

Iam not sure what version you are working on, i think this can be done with Dictionary(.net 2.0), Please take a look at it. Thanks Srini

Thanks Mav. I think you hit the root of my question - is a reference, in my main thread, to chickenLittle.ThinkSkyIsFalling valid even though chickenLittle is operating in thread t? It appears it is - great. That gives me the groundwork I needed to get information to my executing thread. Thanks again. Clive Pottinger Victoria, BC

BackgroundWorker is meant to be used for running long running operations in the background - essentially operations for which you would create a Thread yourself. The difference is that you can use the BackgroundWorker to report progress and completion without having to manually use Invoke or BeginInvoke. Bulk file copy and application initialization (with a splash screen indicating progress) are two places where a BackgroundWorker would work well. The reason I suggested that you use Invoke/BeginInvoke was that you were not running any big operations in DoWork, you were simply using it to marshal the call to the UI thread by setting the Result property. That is exactly what Invoke/BeginInvoke is supposed to do. What's more, the BackgroundWorker's DoWork will run on a threadpool thread - this is in addition to the other thread on which you're doing the actual work. Invoke/BeginInvoke will not use a threadpool thread, it simply causes the delegate to execute on the UI thread. Regards Senthil [MVP - Visual C#] _____________________________ My Blog | My Articles | My Flickr | WinMacro

Thanks everyone. It would appear that the general consensus is "You're screwed, pal!". That's okay. I think I have a way out of this akin to Ed.Poore's suggestion that the Van and Truck construction methods should accept an Automobile object and derive the required information from that. Thanks again. If I can't get it to work, I'll be back. Clive Pottinger Victoria, BC

cpotting wrote: Is there a way to fake having the user move the splitter? Would an Invalidate() followed by an Update() work instead? Looks like the window needs to be completely refreshed in order for the controls to render properly. This bug is in the Win32 layer and has been around for years. :( /ravi This is your brain on Celcius Home | Music | Articles | Freeware ravib(at)ravib(dot)com

While the above answers are correct, I'm going to throw a one into the pot that you might not be aware of. You can use Partial Methods to accomplish a similar thing in .NET 3.5. Basically it allows you to put a call to a partial method and call it from your code. If the method is present, in the implementation then it will be called otherwise it will be compiled out. Take a look at this[^] site for more information. Deja View - the feeling that you've seen this post before. My blog | My articles