I have a confusion on some piece of code.
Inside a class I have a property
Class A
{
ClassB objB;
public int TimedValue
{
objB.Timer;
}
}
Inside classB I have
classB
{
public int Timer
{
get
{
// get time value using some algorithm....
}
}
}
My confusion is that I place breakpoints inside the getters, but I dont see the program flow there and stop! Although I see an object being created and full populated with the TimedValue when I look at it in debug mode inside a watch window. Am I missing something on properties?
EDIT: So, ColinE guided me through the right steps, except I could not find the option there. Here is the screen shot where of where it was suppose to be,
My screen shot
I guess this is a VS bug. Anyway Just posted this so that anyone with team system 2008 should make a note of this :)
Typically the debugger is configures to step over properties, so your breakpoint will never be 'hit. Ensure that the following checkbox is not checked:
Tools => Options => Debugging => General => Step over properties and operators
It looks like you're accessing the Field Time (if that's not a typo in your question and you've omitted that part in your post), not the property Timer on classB.
Related
I have created property from code with ReSharper (moved from some method that was too long):
private static SomeFunctions XmlSomeFunctions
{
get
{
// some logic
return someFunctions;
}
}
However, I want it to be something like this:
private static SomeFunctions xmlSomeFunctions;
private static SomeFunctions XmlSomeFunctions
{
get
{
if (xmlSomeFunctions == null)
{
// some logic
xmlSomeFunctions = someFunctions;
}
return xmlSomeFunctions;
}
}
But I have not found any entry in context menu (Ctrl+Shift+R = Refactor This) in ReSharper that could help me with this task. Is there any way I can create above code automatically with ReSharper?
If I won't rewrite this code (manually for now, preferably with ReSharper, if I know how), I will have that logic executed many times (instead of once) if I ask for XmlSomeFunctions in different places in my code.
What your actually trying to do is create a lazily instantiated property. A better way to do this is just use the Lazy class in .Net. Reuse this class instead of trying to automate the repetitive code with resharper would be my advice.
See http://msdn.microsoft.com/en-us/library/dd642331(v=vs.110).aspx
You do have this possibility. Place your cursor on the name of the property (XmlSomeFunctions) and click on the hammer icon to the left.
You'll have to add the if statement yourself though.
I want to run my project, and I have one class that makes errors - I will fix it later ,but now I want to run the project without reference to the class that makes errors.
How can I do it?
You can do right click on that file and select exclude from project for now.
It is something like Image bleow.
Other way is to comment the logic that is not desired and continue working on without excluding.
You need to comment your class and all usages of this class. It can be done by selecting code block that you need to comment and pressing Ctrl+K, Ctrl+C.
If you need to uncomment - Ctrl+K, Ctrl+U on selected commented block.
Also you need to note that commenting your class usages in project also might produce new errors.
Comment out its inner code. This way you can still reference that class from your code but it will no longer show errors unless you are refering to method or property of this class which is commented out.
public ProblemClass
{
// public string Name { get; set; }
// ...
// ...
}
I have this class:
public class MyProps
{
public MyProps()
{
}
protected string myVar;
public string MyProperty
{
get { return myVar; }
set { myVar = value; }
}
protected int myOtherVar;
public int MyOtherProperty
{
get { return myOtherVar; }
set { myOtherVar = value; }
}
}
That I want to add to my Form, so when I inherit from it I will be able to fill the properties in the MyPropsX property.
I have this code in my form:
protected MyProps propsX = new MyProps();
[TypeConverter(typeof(ExpandableObjectConverter))]
public MyProps MyPropsX
{
get
{
return propsX;
}
set
{
propsX = value;
}
}
Now, the properties MyProperty and MyOtherProperty are nicely shown in the Properties Window, and I can set their values directly there.
But when I close my form and I open it again, all my changes are lost, the properties being reset to show zero and an empty string.
What am I missing?
Should I inherit my MyProps class from certain special class or interfase?
Or some special attribute?
This is a little bit much for a comment and maybe your solution, so i'm answering to your comment with an answer instead with another comment:
With does not happen when I put properties directly on a form you mean, you are using the designer to set some property of the form. These will be written into the MyForm.designer.cs file. When you go into the code of your class you'll find within the constructor a method InitializeComponent(). Set the cursor on it an press F12. Here you can see what the designer has written into all the properties. You should respect the comment above the mentioned method and not start to modify the code with the code editor unless you really have understand how and when the designer will read and write code here (which is another chapter i can explain if needed). Otherwise it will happen that trying to opening your form with the designer after the code change will lead to an error message or code loss.
If you like to set some default value also, you should go back into the constructor and add the needed initialization code below the InitializeComponent() function and everything should work as expected.
Update
As you wrote in your comment you already know how the Designer interacts with the *.designer.cs file. So i really can't understand your concrete problem but maybe one of these articles can give you a more insight about how Microsoft wrote their components:
Make Your Components Really RAD with Visual Studio .NET Property Browser
Components in Visual Studio
This is very normal, since each time you are closing the form and opening it again you are having a new instance from the form MyPropsX, so the best way would be to save your properties in any kind of a database (sql, access, textfiles,...)
When we must use DebuggerDisplay Attributes? What is the advantage of using this?
This article explains it well.
You can use this attribute on your classes to display a more meaningful text when you debug. For example:
Suppose you have a the following class:
[DebuggerDisplay("x = {x} y = {y}")]
MyClass
{
private int x;
private int y;
...
}
Once you debug an instance of MyClass in the Visual Studio debugger and you hover over it (or put it in the Watch Window, you no longer see "MyClass" there but instead "x = 4 y = 5" (assuming that x and y of this instance currently have this value. This is just an example you can do much more as the article explains it.
To answer your question when you should use it, my recommendation is on every single class that is a business object that has data properties that have meaning. Especially important is for any class that will be inside a collection. Since classes that are inside a collection when you expand the results view you'll only see the fully qualified type name and will have to expand each result individually to see which item it is.
However when you use the DebuggerDisplay attribute you can see the properties you deem most important right in the results view of the quick watch window when debugging code that contains collections.
The DebuggerDisplay attribute sets how the class or field is displayed when you view the class or field in the debugger.
For example, rather than see that the variable of is type Address, you could get the debugger to actually display the address that the object is storing.
It just makes debugging a little bit easier! When debugging is easier - the life of a programmer becomes a lot more enjoyable! ;-)
I'm building a custom web control with a public property which I only want to be available in design time (i.e. make it unavailable in code behind).
The DesignOnly attribute promises to do just that, but when I set [DesignOnly(true)] it has no noticeable effect whatsoever:
[Bindable(true)]
[Category("Appearance")]
[DefaultValue(null)]
[Localizable(false)]
[DesignOnly(true)]
public string MyProp
{
get
{
return ViewState["MyProp"] as string;
}
set
{
ViewState["MyProp"] = value;
}
}
The property still appears in code behind IntelliSense. Setting a value to it in code behind works. In these respects, the behavior is just as if the attribute had never been set. And I've cleaned and rebuilt the complete solution. Twice.
Am I doing it wrong? Can you please tell me what is the right way to go about this, then?
Many thanks in advance.
The DesignOnly attribute promises to do just that
Actually, no; it tries to make it clear when accessing it in code isn't available; if you lie (i.e. claim that something is design-only when it is available) then you should expect it to misbehave. The compiler knows what is available, and this design-only attribute is not defined in the C# spec, so it makes no difference to the compiler if you add this attribute.
Try adding:
[EditorBrowsable(EditorBrowsableState.Never)]
which the code editor (IDE) looks at (but only when using a separate assembly) - note that this doesn't stop you using it - it just hides it.
I believe the MSDN text is trying to describe the difference between properties that actually exist on code, vs properties that only pretend to exist; you can actually do all sorts of things to make fake properties appear in the designer, and it is these pretend properties that might be marked as design-only.