|
HI
Have alook at WMI and the System.Management namespace. There is an article on CP (but I'm to lazy to search) , just search for WMI C#. 
I think that should provide all the answers u need
"There are no stupid question's, just stupid people."
|
|
|
|
|
I was reading some stuff on MSDN and I was wondering if anyone could tell me the difference between a property and a field?
|
|
|
|
|
I think not even MS can
lazy isn't my middle name.. its my first.. people just keep calling me Mel cause that's what they put on my drivers license. - Mel Feik
|
|
|
|
|
Well I looked but I couldnt understand why you would use a property instead of a field and visa-versa.
|
|
|
|
|
A property allows you to add additional login before getting or setting values. A field is for direct getting and setting of values.
|
|
|
|
|
|
Hi
Properties are a replacement for all those get/set methods we have in C++ / Java. It also allows you to expose a different type than the field you setting. AFAIK any fields should be never be public.
Hope this helps
"There are no stupid question's, just stupid people."
|
|
|
|
|
Wow, this seems to be a good definition!
lazy isn't my middle name.. its my first.. people just keep calling me Mel cause that's what they put on my drivers license. - Mel Feik
|
|
|
|
|
Yeah, its best to use properties rather than public fields. A property acts as an encapsulation around and a buffer between a classes private fields and the function accessing them.
Where with a public field all you can do is get and set:
class Test
{
public int ABool = 0;
}
Test t = new Test();
t.ABool = 1;
A property allows you to do many things before the field itself is set. A property also allows you to restrict the access to a field, allowing only getting or setting, if that is what your class requires:
class Test
{
private int aBool = 0;
public int ABool
{
set
{
// restrict the value of aBool to positive and zero
if (value >= 0)
{
aBool = value;
}
}
get
{
return aBool;
}
}
}
Test t = new Test();
t.ABool = -1;
|
|
|
|
|
Thanks for the code sample, it makes it much clearer to why properties would be usefull.
|
|
|
|
|
Thank you.
|
|
|
|
|
leppie wrote:
AFAIK any fields should be never be public
Unless they're readonly.
Kevin
|
|
|
|
|
Kevin McFarlane wrote:
Unless they're readonly.
More like const fields I would say. Read-only properties are quite common. Look at the TimeSpan and DateTime classes.
"There are no stupid question's, just stupid people."
|
|
|
|
|
If I understand the question correctly...this may give a good definition.
Property: This is exposed via public accessors (get/set) that allow a user to indirectly modify an internal variable. This process allows the developer to a) encapsulate the actual data b) include process against the data before it is set in the variable c) define that variable as read-only / write-only / read/write-capable.
Field: Directly exposes an internal variable as PUBLIC. This, to some extent, breaks encapsulation, does not keep control of the variable within the control of the object, and is not CLS Compliant. No process can be performed against the public property (such as security or business logic) and as such the value of the variable should be treated as suspect by the owning object.
Does this help?
---------------------------------------------
Once I thought I was wrong
but I was happy to discover that was a mistake.
Condor
|
|
|
|
|
|
theRealCondor wrote:
Field: Directly exposes an internal variable as PUBLIC. This, to some extent, breaks encapsulation, does not keep control of the variable within the control of the object, and is not CLS Compliant. No process can be performed against the public property (such as security or business logic) and as such the value of the variable should be treated as suspect by the owning object.
I don't understand your statment, you can set the field to be public AND readonly in which case control of the variable is kept within the object that contains it.
ASP.NET can never fail as working with it is like fitting bras to supermodels - it's one pleasure after the next - David Wulff
|
|
|
|
|
You are correct in stating that I can do:
public readonly int myInteger
and that variable will be in my control as far as it being a computed field. But I still cannot maintain control over that property as to who can access this property, nor can I hide the implementation of the data.
I also was not looking at specific instance examples, but rather full utilization of either public accessors or exposed public fields. So from that all-or-nothing viewpoint, my statement still holds true. Just to make sure we are on the same page....this is the definition I go by:
Encapsulation means that a group of related properties, methods, and other members are treated as a single unit or object. Objects can control how properties are changed and methods are executed. For example, an object can validate values before allowing property changes. Encapsulation also makes it easier to change your implementation at a latter date by letting you hide implementation details of your objects, a practice called data hiding.
From this definition, even if I maintain some amount of encapsulation with the public readonly direction, I also do not hide the implementation of that data. As such, if that integer now has to be long, I just broke my consumer because they know my implementation is integer. Thus I have broken some form of encapsulation. 
_____________________________________________
I have a tendancy to where my mind on my sleeve
I have a habit of losing my shirt...
|
|
|
|
|
Does anyone know how to create a program that can be operated via named pipes (I think that is what it is called)?
Two programs that I know of that use them are Microsoft Document Explorer (the help files for VS .NET) and Microsoft Money. The help files can be accessed using the "ms-help" pipe and Money can be accessed using the "money" pipe.
The functionality I would like in my program is much like Money, where if you enter a "money" address into Explorer or IE the program is launched and navigated to the right location.
I remember reading somewhere about how to do this but I haven't be able to find any information recently (I forgot what I searched for). Does anyone have an idea of how to do this? Or any references to some articles or help files somewhere that describe the process of APIs used.
Thank you.
|
|
|
|
|
|
|
. . . embedd an, say excel sheet in my application? I was looking at OLE, but as far as I can understand that has to do more with manipulating an open application rather than using components of the app.
What I'm really trying to do, is to create an Excel graph from data that my app collects.
Quite new to this!
Regards,
Venet.
Donec eris felix, multos numerabis amicos.
|
|
|
|
|
Search this forum with "Excel" in the search box right above.
How low can you go ?
(MS rant)
|
|
|
|
|
Thanks,
I did do a search before posting, however all the examples that I've come accross describe Excel automation, i.e. opening excel and populating the fields in it.
My question was, if I can embedd an excel workbook in my application, rather than having that workbook opened in the Excel app itslef.
(Something like IE does when viewing .PDF files)
Regards,
Venet.
Donec eris felix, multos numerabis amicos.
|
|
|
|
|
You've got OLE components with progids such like Excel.Sheet and Excel.Chart (you probably already know the Excel.Application progid, which in turn launches Excel).
These are OLE components, not ActiveX controls. That's why they don't appear in the IDE (customize toolbox for instance).
But they are here and ready. For instance, They appear when you are in Word, Insert \ Object, then select either Microsoft Excel Sheet, or Microsoft Excel Chart. That's exactly the entry point for that.
More info here[^].
How low can you go ?
(MS rant)
|
|
|
|
|
Example looks as exactly what I need. I'm going to try it out later.
Thanks for the reply.
Regards,
Venet.
Donec eris felix, multos numerabis amicos.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
