|
- Say, you have a running process and you want to know where's the file that initially launched it or..
- You have a locked file "because it is running as a process" and you want to kill its associated process to unlock that file.
Any idea or article dealing with that??
Thanks!
All generalizations are wrong, including this one!
(\ /)
(O.o)
(><)
|
|
|
|
|
check the Process class, it can tell you all sorts of useful information.
for example:
foreach (Process p in Process.GetProcesses())
{
try
{
Console.WriteLine(p.MainModule.FileName);
}
catch (Win32Exception ex)
{
Console.WriteLine("caught an exception : " + ex.Message);
}
}
|
|
|
|
|
Thanks mate! That was helpful!
All generalizations are wrong, including this one!
(\ /)
(O.o)
(><)
|
|
|
|
|
hi have following table
student
id name school_ID
1 john 5
2 sara 2
3 luije 4
school
id name
1 area1
2 area2
3 area3
4 area4
5 area5
need to save "null" to school_ID with student ID(2)..??
thanks in advance
|
|
|
|
|
sounds like homework to me - what have you tried so far
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
var q = from d in sdc.student
where d.school_ID == 4
select d;
q.school_ID = null;
|
|
|
|
|
You cant make the primary key NULL!
xacc.ide - now with TabsToSpaces support IronScheme - 1.0 beta 1 - out now! ((lambda (x) `((lambda (x) ,x) ',x)) '`((lambda (x) ,x) ',x))
|
|
|
|
|
In your code, q is not a database row, but the query itself.
Also, you are not selecting on student id 2.
You should do something like this:
var q = from d in sdc.student
where d.id == 2
select d;
var row = q.FirstOrDefault();
if (row != null)
{
row.school_ID = null;
}
sdc.SubmitChanges()
|
|
|
|
|
ok, got it solve
but it is very straing
this not work:
-------
var q = (from d in sdc.student
where d.id == 2
select d).FirstorDefault();
try {if (q != null) q.school_ID = null;} cathc{ }
-------
following works:
int k = 0;
var q = (from d in sdc.student
where d.id == 2
select d).FirstorDefault();
try {if (q != null) k = 1/k;} catch { q.school_ID = null;}
---------------------------
Really don't know why when write this inside catch{} it works if write outside not work
Pleae check
Thanks
|
|
|
|
|
I don't see why this should not work.
What you mean by not work? Gives you an error, does nothing or what?
|
|
|
|
|
I've been using properties for quite some time, and it was until today that a question came to me: what's the difference between using a property and a variable? I know properties are better practice, but still... just wondering .
public int Number
{
get
{
return this.number;
}
set
{
this.number = value;
}
}
vs
public int number = 0;
|
|
|
|
|
You generally have more control over a property, but if you don't need that control then it's just overhead.
And have you looked at automatic properties (or whatever they're called)?
|
|
|
|
|
|
If you don't 'need' the private variable yourself but are just using it to hold a property's value with no validation then you can do this and the compiler takes care of it all for you. Personally I never use them as I like to be in control of what's happening.
public int Number { get; set; }
DaveBTW, in software, hope and pray is not a viable strategy. (Luc Pattyn)Visual Basic is not used by normal people so we're not covering it here. (Uncyclopedia)
|
|
|
|
|
What would be the initial value of the property?
|
|
|
|
|
Whatever the intial value of the data type - 0 in the case of an int. All value types have an initial value. Reference types will be null (I believe - I haven't checked) as no instance has yet been created.
DaveBTW, in software, hope and pray is not a viable strategy. (Luc Pattyn)Visual Basic is not used by normal people so we're not covering it here. (Uncyclopedia)
|
|
|
|
|
I like these, simple in the above style and can easily be expanded to a normal property if required.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
For future extensibility they are useful I suppose - but I've found I nearly always need more control so I do it the 'old fashioned' way! Also, not being able to have true read only properties this way (you have to have a set; - although it can have a private accessor) is a pain.
DaveBTW, in software, hope and pray is not a viable strategy. (Luc Pattyn)Visual Basic is not used by normal people so we're not covering it here. (Uncyclopedia)
|
|
|
|
|
I use properties a LOT, I have a class for each table in my BLL and a property for each field in the table (all auto generated) so nearly all of these can be serviced by the auto property. Expanding an auto to a full property is really simple and can be done at any time.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
you know you can do this:
public int MyInt{get; private set; }
|
|
|
|
|
Yeah - in my post...
DaveyM69 wrote: although it can have a private accessor
DaveBTW, in software, hope and pray is not a viable strategy. (Luc Pattyn)Visual Basic is not used by normal people so we're not covering it here. (Uncyclopedia)
|
|
|
|
|
Auto-Implemented Properties
|
|
|
|
|
There are many reasons - a couple to get you started...
1. Using a property enables you to do validation etc within the object that holds the variable in the getter and setter methods.
Imagine if the number variable should be restricted to a certain range under certain situations. If you expose the variable directly you have no control over what goes into it - other than the data type. With a property you can test the value parameter, and raise an exception or set the variable to a different value etc.
2. Properties do not have to refer to an actual variable. e.g.
private int number1;
private int number2;
public int Sum
{
get { return number1 + number2; }
}
DaveBTW, in software, hope and pray is not a viable strategy. (Luc Pattyn)Visual Basic is not used by normal people so we're not covering it here. (Uncyclopedia)
|
|
|
|
|
|
A property can be an interface member, whereas a variable can't be. This means changing the definition of a class to add/remove a property is a breaking change. Generally speaking if "Number" is part of the publically available API, then you want to expose it as a property.
A variable can be passed by reference (ref/out), a property can't be. A variable has only one access modifier, a property can have a different modifier on get/set.
In terms of overhead, the effort of implementation is quite small if you use automatic properties. int Foo { get;set; }. In terms of performance the simple accessor will usually be inlined by JIT, making the performance identical (except on forms - they inherit MarshalByRef).
Also as a property is effectively a stub of metadata pointing to getter and setter methods, they can benefit from things like declarative security, etc.
|
|
|
|