Search Results

Search found 2 results on 1 pages for 'brone'.

Page 1/1 | 1 

  • Using .NET XmlSerializer with get properties and setter functions

    - by brone
    I'm trying to use XmlSerializer from C# to save out a class that has some values that are read by properties (the code being just a simple retrieval of field value) but set by setter functions (since there is a delegate called if the value changes). What I'm currently doing is this sort of thing. The intended use is to use the InT property to read the value, and use SetInT to set it. Setting it has side-effects, so a method is more appropriate than a property here. XmlSerializationOnly_InT exists solely for the benefit of the XmlSerializer (hence the name), and shouldn't be used by normal code. class X { public double InT { get { return _inT; } } public void SetInT(double newInT) { if (newInT != _inT) { _inT = newInT; Changed();//includes delegate call; potentially expensive } } private double _inT; // not called by normal code, as the property set is not just a simple // field set or two. [XmlElement(ElementName = "InT")] public double XmlSerializationOnly_InT { get { return InT; } set { SetInT(value); } } } This works, it's easy enough to do, and the XML file looks like you'd expect. It's manual labour though, and a bit ugly, so I'm only somewhat satisfied. What I'd really like is to be able to tell the XML serialization to read the value using the property, and set it using the setter function. Then I wouldn't need XmlSerializationOnly_InT at all. I seem to be following standard practise by distinguishing between property sets and setter functions in this way, so I'm sure I'm not the only person to have encountered this (though google suggests I might be). What have others done in this situation? Is there some easy way to persuade the XmlSerializer to handle this sort of thing better? If not, is there perhaps some other easy way to do it?

    Read the article

  • Evaluating expressions using Visual Studio 2005 SDK rather than automation's Debugger::GetExpression

    - by brone
    I'm looking into writing an addin (or package, if necessary) for Visual Studio 2005 that needs watch window type functionality -- evaluation of expressions and examination of the types. The automation facilities provide Debugger::GetExpression, which is useful enough, but the information provided is a bit crude. From looking through the docs, it sounds like an IDebugExpressionContext2 would be more useful. With one of these it looks as if I can get more information from an expression -- detailed information about the type and any members and so on and so forth, without having everything come through as strings. I can't find any way of actually getting a IDebugExpressionContext2, though! IDebugProgramProvider2 sort of looks relevant, in that I could start with IDebugProgramProvider2::GetProviderProcessData and then slowly drill down until reaching something that can supply my expression context -- but I'll need to supply a port to this, and it's not clear how to retrieve the port corresponding to the current debug session. (Even if I tried every port, it's not obvious how to tell which port is the right one...) I'm becoming suspicious that this simply isn't a supported use case, but with any luck I've simply missed something crashingly obvious. Can anybody help?

    Read the article

1