|
I've got another question. If a host has a socket open and BeginAccept has been called. Is it possible for a Client to be able to search for open sockets bound to a certain porta and detect that socket?
modified on Monday, March 24, 2008 12:55 PM
|
|
|
|
|
I need to change te text of some messageBox buttons...
Can anyone help me on that?
PC
|
|
|
|
|
pcaeiro,
You'll need to explain a bit more what you want to do.
Regards,
Gareth.
|
|
|
|
|
You will need ti develop your own message box.
Giorgi Dalakishvili
#region signature
my articles
#endregion
|
|
|
|
|
You have to write your own implementation, or use the new TaskDialog in Windows Vista (although I believe somebody has put together a .NET version that will run on XP as well - have a search here on Code Project for the article explaining it).
|
|
|
|
|
See [^].
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
good example.
thanks for the help. 
PC
|
|
|
|
|
Hello,
VS 2008
I am using a binding source that is bound to a dataset with one table called AddressBook.
The binding source is bound to a combo box.
The address book table consists of 2 columns (number, name). There will be no duplicate phone numbers, as if it is already in the combo box it will
just set it to index zero.
This is just a simple table as I want to display the recent phone numbers.
When someone enters a phone number it will add it to the combo box, and position the number as index 0 (most recent).
However, if the phone number is already stored, then it should move it to index 0.
So this just a simple combo box that displays the most recent calls that are made. Just like any mobile phone.
This is my code so far. However, I am having a problem with moving the item to the top. is there some way this could be done better.
Many thanks for any advice,
Steve
<br />
if (!this.bsRedialedNumbers.Contains(this.txtDetails.Text))<br />
{<br />
DataRowView drv;<br />
drv = (DataRowView)this.bsRedialedNumbers.AddNew();<br />
drv["Name"] = this.txtDisplay.Text;<br />
drv["Number"] = this.txtDisplay.Text;<br />
<br />
}<br />
else
{<br />
DataRowView drv;<br />
drv = (DataRowView)this.bsRedialedNumbers;<br />
int index = this.bsRedialedNumbers.Find("Number", txtDetails.Text); <br />
}<br />
|
|
|
|
|
I have faced a problem.
That is:
Input:
File name which I want to search
Drive name where I want to search
Output:
True / False (Whether the file exists or not)
Can anybody help me?
|
|
|
|
|
You might want to look at DirectoryInfo and FileInfo classes.
|
|
|
|
|
Does the following work?
Requires System.IO namespace
foreach (string FileName in Directory.GetFiles(path, "file.ext"))
{
}
|
|
|
|
|
Hello everyone,
As mentioned in this article, why using this or type itself as lock object is bad idea? What means "it potentially offers public scope to the synchronization object"?
http://www.albahari.com/threading/part2.html
I quote the whole paragraph below,
--------------------
Choosing the Synchronization Object
Any object visible to each of the partaking threads can be used as a synchronizing object, subject to one hard rule: it must be a reference type. It’s also highly recommended that the synchronizing object be privately scoped to the class (i.e. a private instance field) to prevent an unintentional interaction from external code locking the same object. Subject to these rules, the synchronizing object can double as the object it's protecting, such as with the list field below:
class ThreadSafe {
List <string> list = new List <string>();
void Test() {
lock (list) {
list.Add ("Item 1");
...
A dedicated field is commonly used (such as locker, in the example prior), because it allows precise control over the scope and granularity of the lock. Using the object or type itself as a synchronization object, i.e.:
lock (this) { ... }
or:
lock (typeof (Widget)) { ... }
is discouraged because it potentially offers public scope to the synchronization object.
--------------------
thanks in advance,
George
|
|
|
|
|
Hi,
The class of 'this' (say NotPrivateClass) might not be private (or might not be private anymore in the future) , so let's say that someone else could do :
NotPrivateClass x=new NotPrivateClass();<br />
lock(x)
in another thread and therefore create a potential deadlock with
lock (this) { ... }
hope it helps
modified on Saturday, March 22, 2008 10:09 AM
|
|
|
|
|
Thanks girm,
What means "offers public scope" and why it is discouraged?
regards,
George
|
|
|
|
|
public scope means it is available outside of the class itself.
In the context of synchronisation objects it is discouraged. If the sync' object is available outside of the class other code can attempt to lock it - this could potentially lead to a deadlock.
|
|
|
|
|
Thanks Colin,
Colin Angus Mackay wrote: this could potentially lead to a deadlock.
Could you describe a scenario why expose this as lock object will cause deadlock compared with using private object as lock please?
regards,
George
|
|
|
|
|
well, in my exemple NotPrivateClass , has potentially a public scope : some other class could access it
consider 'this' is an instance of NotPrivateClass (in the code you quoted) : someone else could access to the instance refercenced by this ("public scope is offered").
so if you use 'this' as the locking object , then someone else could do the same .. and that's not ggod .. for the deadlock reason I've given
|
|
|
|
|
Thanks girm,
Could you describe a scenario why expose this as lock object will cause deadlock compared with using private object as lock please?
regards,
George
|
|
|
|
|
Sure...
public class PublicClass1
{
public PublicClass1(){};
public void LockMe1(PublicClass2 aPublicInstance2)
{
lock(this)
{
lock(aPublicInstance2)
{
MessageBox.ShowDialog("no deadlock, great!!");
}
}
}
public class PublicClass2
{
public PublicClass2(){};
}
...
say a thread Y calls :
lock(aPublicInstance2)
{
lock(aPublicInstance1)
{
MessageBox.ShowDialog("no deadlock, great!!");
}
}
another thread X calls :
aPublicInstance1.LockMe1(aPublicInstance2);
Lets say that thread X is actually executing '// ref line (X)'
and thread Y is actually executing '// ref line (Y)'
...no problem...
then X step forward and is now stuck because it cannot acquire the lock :
lock(aPublicInstance2) , since it is already locked by thread Y
But Y is still running and perform a call :
...and then is stuck because it cannot acquire lock on aPublicInstance1 (see 'lock(aPublicInstance1)
') because it is locked by thread X (see lock(this) // ref line (X))
...so X is blocking Y, Y is blocking X : deadlock , no message is displayed
-------------------------
Now if locked object were not publicly availlable X and Y thread would not have been able to
put lock on those objects since they wouldn't have access to it.
...
of course simply not using 'lock(this)' will not garantee you will never have deadlocks : it just limit the risks
regards
Girm
|
|
|
|
|
Wonderful sample, cool Grim!
regards,
George
|
|
|
|
|
If you are using the keyword "this" then most likely something elsewhere has access to that object, the thing that called the method you are in will have a reference to what ever "this" is, for example.
If you want to ensure that the object is threadsafe then exposing the thing you are using to lock (synchronise) isn't a good idea as code you have no control over could attempt to do the same thing by locking the object. If that happens, I'd imagine that it becomes easier to get into a situation where deadlocks can occur. A deadlock is where two bits of code are blocked because the first is waiting for the second to complete, and vice versa. In this scenario neither will complete.
So, if the object uses private objects internally to do the locking then nothing else can access the synchonisation objects and you have better control over how the locking works, and if you do find yourself in a situation where a deadlock occurs you won't have far to look to track down the problem (it will all be in one class).
|
|
|
|
|
Thanks Colin,
I read your reply carefully. Agree and understand most of your points. Just one question,
Colin Angus Mackay wrote: If that happens, I'd imagine that it becomes easier to get into a situation where deadlocks can occur.
Why using internal private object as lock object will reduce chance of deadlock compared with using this object? Could you describe a scenario please?
regards,
George
|
|
|
|
|
George_George wrote: Why using internal private object as lock object will reduce chance of deadlock compared with using this object? Could you describe a scenario please?
Well, if you use a private object then nothing outside the class can access the object. That means that you have full control within the class of how instances of the class are synchronised.
If you use "this", and other code uses the reference to the same object then they can interfere with each other. There isn't much you can do to defend yourself from code that you have not written and have no control over.
|
|
|
|
|
Thanks Colin,
I can understand the situation you described above. But could you show by example why in the similar situation, using this object other than using private member as lock object will be more prone to cause deadlock please?
A sample will make everything clear.
regards,
George
|
|
|
|
|
How can I create a subclass from a base class by just just inputting the name of the subclass I want to create? I think this uses System.Reflection. Need a working code. Thanks.
modified on Saturday, March 22, 2008 9:09 AM
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
