you should avoid using DoEvents as its bad practice and can cause undesirable effects at times. Why do you need DoEvents? There may well be a better way of what you are trying to do - can you explain more about the project or rather this particular part where you are using DoEvents? FYI DoEvents is in the System.Windows.Forms namespace
Yes i know that its not good programming practice. I have a while loop which is waiting for data received (or sent) over sockets. Since I have to keep on listening for data being received, I cant think of a better way of doing this thing without using the while(true) loop. The loop terminates when the client sends an exit message. So, I am using the DoEvents before I enter this loop to allow my program to do other stuff.
And yes I know that DoEvents is in Windows.Forms, but that is where the problem is .... i dont have a windows form in a class library.
you should create a new thread which listens on the socket/port and let that execute in the background with the while(true) loop in this case and let it keep listening and then disconnect from the client when you get that message from the client :-) This is generally what you should do and what most people do when listening to socket/communication between client/server - to run a thread in the background which only listens to communication whilst your main thread is not "hung" or acting as if its not responding, when it is.
that is exactly what I am doing. I am listening on threads, but I have to send data in real time and even a while(true) loop in a thread degrades the performance I intend to get, so I was using the DoEvents and it got me what I wanted.
And kindly if you do not have a solution to the question asked, dont try to act smart :-).
if a reply to your question is not helping you why is it marked as answer? If a reply is marked as answer and it is not helping you you unmark it and others will see that you have not found an answer to your question.
You can use DoEvents if your class library references the System.Windows.Forms assembly. This implies that it is used from a .NET winform app. If you do this you must take into consideration that your app can get events while other events are being handled. It is nothing bad to do DoEvents(), you just need to be aware of it in your code, as in any multithreading app.
Can you start the send data code in a new thread? Maybe if you give a sample I or somebody else can give a more helping answer.
Thanks a lot Andreas, I didnt realize I had marked the reply as an answer. And apologies to the rest of the people on the forum for my rudeness in my previous reply.
I have two threads, one for sending and the other for receiving the data. I call these threads from a function, and this function is called from my C++ code at the time of initialization.
I tried using the System.Windows.Form in my C# Class Library, but after I enter "System." I dont see any "Windows" in the list of assemblies. Does this have to do with the way i created my Class Library? How can I add the System.Windows.Form assembly to my Class Library?
Thanks once again.
I agree with the sentiments expressed that "DoEvents()" is a problem.
Since we don't have any sample code to look at, it is difficult to diagnose why a so-called "while (true)" loop may be degrading performance. It sounds to me like a busy-wait problem, but with no code it's impossible to say.
There are no circumstances that I can think of where DoEvents() is necessary. In fact, the overhead of calling DoEvents() is HUGE. We treat the use of DoEvents() as a bug here...
IMHO the solution to this problem is to rewrite the code so that it doesn't need to use DoEvents(). The CALLER should perhaps be creating a worker thread to do this.
Alternatively, you can have the library code create threads, and communicate back to the caller via events (that is a common way for threads to communicate back to callers). It is possible to write library code that accepts a Form object and then uses that to transition back to the main UI thread (using InvokeRequired() and a delegate) so that the client code doesn't need to worry about it.
1.) I agree with Andreas's comments on answer marking.
2.) I disagree that the use of DoEvents is indiscriminantely bad practice. Part of a good programmers knowledge base if to know when and why to use Doevents, when it will work for and when it will produce undesireable side effects.
3.) Everyone here is not a guy.