|
Cool,it works well.
thank you a lot.
John:
|
|
|
|
|
I have an update polling task on a thread that checks an internet server for updates. If an update is available it fires an event. It turns out that the event handler gets executed on the same thread as the task (sound logical).
BUT
I need the polling thread to die and the handler method to execute on the main thread. How can I do this?
I had a similar problem with Threads and Winforms. Only the owner thread can interact with the control. The solution to that one was a simple Control.Invoke().
|
|
|
|
|
I had to do something similar to this but because I come from the Win32 C++ world I took an API approach so there may be a better C# way of doing this. Anyway, what I did was an override of the WndProc method on the main thread and used post message from the polling thread. As I recall I was under pressure for a fast workaround and did not have time to thoroughly research an optimal solution. I would be interested in what you come up with.
|
|
|
|
|
Hey!! 
That is exactly the first thing that i came up with before I figured out how to do Thread<->Winforms properly.
However this is a different problem - there is no WndProc to override.
I decided to put the poller on a seperate thread because polling the server can really delay application startup. The application is running from an ApplicationContext. The Init method of the app context calls the Updater.Check() method, which attaches an event handler, kicks off the poller thread, and continues. When the event is fired the handler will execute on the same thread as the poller. This will not work for me because I have no idea how long the update will take. Btw, I have the downloader run on its own thread. Obviously, using the event will not work.
|
|
|
|
|
I had a similar problem. However, for me, I wanted to have a task get executed by a "main" background thread rather than in the GUI thread. It's the same problem as above, though.
Essentially, I employed a Command Queue design pattern, which the "main" thread monitors in some fashion.
Here's an interface:
interface ICommand
{
void Execute();
}
Then I can write some classes that implement the ICommand interface. For your case, the polling thread can construct some relevant object (that has the ICommand interface). This object can then be enqueued in a queue that the main thread monitors. Be sure to use some sort of synchronization on the thread -- it might be as simple as using the Queue.Synchronized() wrapper.
So, this queue could be a singleton object, which you might access via WorkQueue.Instance, or you could make it a private member of your MainThread class, and some public method of MainThread could be called from the polling thread, enqueuing the object. And you can use all sorts of techniques to look for any waiting commands in the queue...
Anyway, that's what I basically do, and it's pretty flexible for me, even though all I do is use it for executing a "Stop" command. It seems like one of the best ways to get another thread to execute some code.
|
|
|
|
|
Sounds like a good idea but I'm wondering where you would monitor it from. In AK's situation I think he is looking for an event to occur but in your situation you probably have a worker thread that is looping - before it begins another iteration you check to see if it should stop. Since there is no “loop” for AK he would need an event…
I do like your approach, though, for workers.
|
|
|
|
|
Well, it depends on the structure of AK's main thread. He doesn't need to loop, he could just use a combination of Monitor.Wait (in the main thread) and Monitor.Pulse (in the polling thread).
But I don't think you can do the equivalent of Control.Invoke() on some arbitrary thread. You can't tell a thread to interrupt its current code, run some code, and then continue execution as before without the thread explicitly expecting it (such as looping around for it).
Control.Invoke() is special -- I imagine it's basically implemented like your WndProc hacks. I imagine that Control.Invoke() calls are queued, and whenever WndProc finds a good time to invoke them, then they are finally executed.
But if someone proves me wrong, that would invoke a powerful change in my understanding of threading. 
|
|
|
|
|
You're right, it depends on the structure of his main thread. My feeling is he would not want to block on the Monitor.Wait, though.
AK, let us know what you find. You have Arun and me intrested.
|
|
|
|
|
This is very interesting. I've been searching for something that would work, and it the Monitor class sounds very promising. For now, I just decided to do a quick work around.
Basicly the updater lets the poller run. Using a timer the updater checks every minute if an update was found.
Still, this thread problem is really puzzling and I would like to figure it out.
|
|
|
|
|
I dunno, maybe SendMessage() is the way to go, if you can get a background thread to listen to the message pump...?
I happen to like the route you went, though, but mainly because I come from UNIX (C/C++) and Java.
|
|
|
|
|
I guess AK could use your idea and monitor from the Application.Idle event.
|
|
|
|
|
Alright, Im getting this error message with this line of code, any suggestions?
An unhandled exception of type 'System.NotSupportedException' occurred in system.dll
Additional information: ArrayConverter cannot convert from System.String.
this.text = (sbyte[])TypeDescriptor.GetConverter(this.text).ConvertFrom("Cp437");
Thanks,
Ryan
|
|
|
|
|
There are a lot of "dots" in that line of code. The first rule I follow in troubleshooting is to isolate the problem. So...
TypeConverter tc = TypeDescriptor.GetConverter(this.text);
object converted = tc.ConvertFrom("Cp437");
sbyte[] mybytes = (sbyte[])converted;
...
Without knowing anything about what your code does, we can at least isolate the source of the problem and often that leads to a solution.
Looking at the help info on TypeConverter.ConvertFrom() I found this:
Exceptions
NotSupportedException The conversion could not be performed.
That tells me that your conversion is not supported. Start there, I think.
α.γεεκ Fortune passes everywhere.
Duke Leto Atreides
|
|
|
|
|
Thanks for the process and suggestion Jim.
Ryan
|
|
|
|
|
I have a .NET class library that I want to test from an ASP.NET, when I try to add the reference to the class library registed in COM+ i get the following message
"A reference to 'myClassLibrary' could not be added. Converting the type library to a .NET assembly failed. Type library 'myClassLibrary' was exported from a CLR assembly and cannot be re-imported as a CLR assembly"
Anybody has an idea of what might be causing this error
Thanks in advance
|
|
|
|
|
okay 2 textboxes one box i have user input the other one is a password now i need to bind the userid and the datatime stamp to the listbox that i need to bind to xml file and then call and read that xml file into another listbox on another form
im using c#
Thanks any help would be greatly appreciated.......i checked out the article on msdn and im still lost.
Da Intern
|
|
|
|
|
what you just described is a whole program. which part are you having trouble with?
Seems to me that you also need an OK button (and a cancel button). In the ok button event place the code that takes the userid and psswd and does what you need. (i.e. you time stamping, output to the xml file ...)
|
|
|
|
|
how do i bind a listbox to an xml file then how do i read that xml file in another form
the last part i can probably figure out but binding it to xml file is killing me
Thanks
Da Intern
|
|
|
|
|
I'm not sure if that is possible. Parse the xml file and use the YourList.Items.Add method. Also, I'm not sure what you mean by "xml file in another form". if it is some sort of object you can either make it public, make a property or create a method in the "OtherForm" that allows access to the file.
Goodluck
|
|
|
|
|
|
Uh i still need some more help
Da Intern
|
|
|
|
|
|
What I am trying to do is to insert a new DataRow at a specific location in the DataRowCollection. I know that the order of items may not be preserved when using Select or GetChildRows method, but according to the DataRowCollection.InsertAt documentation, this order IS preserved when writing the data as XML (using the DataSet.WriteXml method). But it is not  Imagine the following scenario:
1. The DataSet is populated using the ReadXml method
2. A newly created row is inserted at the beginning of the DataRowCollection using the dt.Rows.InsertAt(dr, 0);
3. The DataTable dt is data bound to a DataGrid control, without any sorting, (the newly inserted row is indeed displayed as the first record).
4. The whole dataset is written to an XML file, using the DataSet's WriteXml method. And, surprise, the newly created row is at the END of the table 
What am I doing wrong? Anyone ever experienced this? Any clues or ideas are highly appreciated.
Rado
|
|
|
|
|
I don't know, it should work, but the following code is an alternative:
BackColor.GetBrightness();
BackColor.GetHue();
BackColor.GetSaturation();
So, you don't need to resort to interop.
Acting as a substitute for God, he becomes a dispenser of justice. - Alexandre Dumas
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
