|
Pick up a book on C# and read - you would get an idea on properties and setters - getters.
|
|
|
|
|
Okay, so it's all about the learning curve ?
So then, like, C# takes a long time with repeated experiments and examples and so on before you are really competent to write something useful ?
|
|
|
|
|
C-P-User-3 wrote: So then, like, C# takes a long time with repeated experiments and examples and so on before you are really competent to write something useful ?
No. Your earlier work will probably seem quite naive to you when you go back to it later on, but there's no reason not to be writing useful code early on.
|
|
|
|
|
As others have said, it's simply a way of getting a value using a property:
private YourType yourValue;
public YourType YourProperty
{
get{ return yourValue;
}
The next obvious question is why we use a getter. In the example above we could have just made yourValue public. The disadvantage of that is then yourValue can also be changed. In our code, it is read only as there is no corresponding setter.
Including a setter rather than exposing the variable still has advantages however. For example, we could include some validation, raise an event or start some other activity in the setter:
public event EventHandler YourPropertyChanged;
private YourType yourValue;
public YourType YourProperty
{
get{ return yourValue;
set
{
if(!yourValue.Equals(value))
{
yourValue = value;
OnYourPropertyChanged(EventArgs.Empty);
}
}
}
protected virtual void OnYourPropertyChanged(EventArgs e)
{
EventHandler eh = YourPropertyChanged;
if(eh != null)
eh(this, e);
}
Also, the getter could be static as in DateTime.Now , where it returns a value that is calculated on demand.
There are other advantages too, but that should be enough to get you going
|
|
|
|
|
So then, a "getter" without a "setter" is the way (a way?) for me to define a group of bytes that won't change during program execution ?
That is one of the things that I definitely want to have if at all possible; i.e., when the user clicks button 1, I want to be certain that the bytes in a certain group are the bytes that go out the serial port.
|
|
|
|
|
IF you want a collection of anything ( <T> ) I would use a ReadOnlyCollection[^] and expose that using a property.
|
|
|
|
|
Sounds like a job for a FIFO collection. Time to cue the Queue[^].
|
|
|
|
|
Hello
I'm using this code...
System.Reflection.Assembly assembly = System.Reflection.Assembly.GetExecutingAssembly();
Version version = assembly.GetName().Version;
...to get version of my application.
The result is: 1.0.0.24557, but I want to reduce a number of digits in MinorRevision so that my result look like: 1.0.0.24
Why there is 5 digits in MinorRevision? Is it possible to modifiy MinorRevision to be only on 2 digits so the next version will be 1.0.0.25, 1.0.0.26 etc?
Rene
|
|
|
|
|
Member 9141033 wrote: Why there is 5 digits in MinorRevision?
Version numbers consist of two to four components: major, minor, build, and revision. The major and minor components are required; the build and revision components are optional, but the build component is required if the revision component is defined. All defined components must be integers greater than or equal to 0. The format of the version number is as follows (optional components are shown in square brackets ([ and ]):
major.minor[.build[.revision]]
The components are used by convention as follows:
Major: Assemblies with the same name but different major versions are not interchangeable. A higher version number might indicate a major rewrite of a product where backward compatibility cannot be assumed.
Minor: If the name and major version number on two assemblies are the same, but the minor version number is different, this indicates significant enhancement with the intention of backward compatibility. This higher minor version number might indicate a point release of a product or a fully backward-compatible new version of a product.
Build: A difference in build number represents a recompilation of the same source. Different build numbers might be used when the processor, platform, or compiler changes.
Revision: Assemblies with the same name, major, and minor version numbers but different revisions are intended to be fully interchangeable. A higher revision number might be used in a build that fixes a security hole in a previously released assembly.
Source[^]
Right-click on the project in the solution-explorer, choose "properties", go to the "application" tab, click on the button "assembly information" - there you can edit the numbers.
|
|
|
|
|
Tnx for your reply!
In my "application" tab -> "assembly information" stands 1.0.0.44, and when I run my application, application shows 1.0.0.25
Why there is a difference?
|
|
|
|
|
Member 9141033 wrote: Why there is a difference?
The assembly is part of the application; every assembly has it's own version-number, and then there's the version-number of the app.
|
|
|
|
|
Is there any way to reduce a number of digits so that my Revision has 2 digits?
tnx
|
|
|
|
|
Did your previous post not show an example where you had two digits?
|
|
|
|
|
ooops! sorry, my bad...
application(.exe) shows 1.0.0.25969 and in project properties stands 1.0.0.44.
i want to reduce number of digits...
tnx
|
|
|
|
|
Come on! It's simple string manipulation! Convert the Revision number to a string and grab the left 2 characters.
Why is this being treated as rocket science??
|
|
|
|
|
Rocket science or not, if you want to help then help, and don't prance here...
|
|
|
|
|
You asked how to get this: "28475" down to this "28". If you can't do
string shortenedRevision = revisionString.SubString(0, 2)
you've got much bigger problems than getting the correct revision number.
|
|
|
|
|
Member 9141033 wrote: application(.exe) shows 1.0.0.25969 and in project properties stands 1.0.0.44.
After building, the version should be 1.0.0.44 for the assembly, regardless whether it's an executable or a library.
Back to the solution-explorer, check the folder called "properties"; it'll contain an "AssemblyInfo.cs" file. At the end of the file, you should see something similar to below;
[assembly: AssemblyVersion("1.0.0.0")]
[assembly: AssemblyFileVersion("1.0.0.0")]
It is the on at the bottom that's used to display a version number in the Windows Explorer. Should even work if you enter "-1" as the "revision"
|
|
|
|
|
Hi all I would like to create a button in the context menu (right click) for the selected contact. This button has the same functions as the call button. Is there a way to create this add-in for Outlook 2007 and 2010 in Visual C # and NOT in VB.NET. I repeat NOT in VB.Net.
|
|
|
|
|
I'm certain you can write VSTO addins in C#
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
This is not valid answer.
|
|
|
|
|
|
Well, if you're going to be like that, pack your bags and leave.
You asked if it was possible and the answer was "Yes!"
The quality of the answer you get is directly dictated by the quality of the question you ask.
|
|
|
|
|
You're doing really well, kid. Out of 11 messages five have a score of 1.0
|
|
|
|
|
I was joking...
|
|
|
|