|
|
Be careful, your teacher is probably reading those forums also.
|
|
|
|
|
If i could get some sample on how to draw the elipses and connector to those ellipses that is also fine to start
rasana
|
|
|
|
|
I'm using an invoke on a form to update the UI from a backgroundworker thread.
The problem is that the application slows down enourmously - in fact it is around >50 times faster when the UI is not being updated!
Using a delegate has the same effect.
Can anyone give me some pointers to an alternative to updating a UI from a backgroundworker that is fast.
Thanks in advance.
Guy
Continuous effort - not strength or intelligence - is the key to unlocking our potential.(Winston Churchill)
|
|
|
|
|
Updating UI is an extremely slow process compared to computation. The most effective way to update a UI is to do so no more than a human would reasonable expect. For example, there is no reason to update a text box more than 2 times per second, and even then that is overkill. Put in a throttle that will ignore your UI update invoke if it has already happened within a given unit of time and you will see a dramatic increase.
Need a C# Consultant? I'm available.
Happiness in intelligent people is the rarest thing I know. -- Ernest Hemingway
|
|
|
|
|
Thanks - that helps.
I was assuming that updating a UI was fast and I was just missing something.
Once every two seconds should be fine for my application.
I suppose C++ would be the direction to go for this sort of speed?
(A direction I have no intention of heading in just yet...)
Regards
Guy
Continuous effort - not strength or intelligence - is the key to unlocking our potential.(Winston Churchill)
|
|
|
|
|
GuyThiebaut wrote: I suppose C++ would be the direction to go for this sort of speed?
No, not really. You're still using slow controls that draw themselves to the screen. The language you use isn't going to make that much of an impact on the speed of the update.
|
|
|
|
|
Thanks for the information - coming from a database background this is all new stuff for me.
I'm guessing the Windows API is having to do a lot of work to update a form.
I popped a timer into the application and set the Tick event to update the UI - works like a treat now.
Continuous effort - not strength or intelligence - is the key to unlocking our potential.(Winston Churchill)
|
|
|
|
|
The problem with updating the UI is that only the UI thread can access the controls in the UI, so if you do it from a background thread, you are actually sending a message to the UI thread to do the update. This of course means a lot of overhead.
You can use a synchronised queue to send the information more efficiently. Create a queue in the UI thread and send along a reference to it to the background thread. Put updates in the queue from the background thread, and use a timer in the UI thread to look for new information in the queue.
SynchronisedQueue<string> queue = new SynchronisedQueue<string>;
IQueueWriter<string> writer = queue;
writer.Enqueue("something");
string info;
while (queue.TryDequeue(out info)) {
labelInfo.Text = info;
}
Instead of a string you can of course use any type you like, perhaps make your own class with any information you need to send between the threads.
Here's the synchronised queue:
public interface IQueueReader<T> {
bool TryDequeue(out T value);
}
public interface IQueueWriter<T> {
void Enqueue(T value);
}
public class SynchronisedQueue<T> : IQueueReader<T>, IQueueWriter<T> {
#region Private variables
private Queue<T> _queue;
private object _sync;
#endregion
#region Constructor
public SynchronisedQueue() {
_queue = new Queue<T>();
_sync = new object();
}
#endregion
#region Properties
public int Count { get { lock (_sync) return _queue.Count; } }
#endregion
#region Methods
public void Clear() {
lock (_sync) {
_queue.Clear();
}
}
public void Enqueue(T value) {
lock (_sync) {
_queue.Enqueue(value);
}
}
public bool TryDequeue(out T value) {
lock (_sync) {
if (_queue.Count > 0) {
value = _queue.Dequeue();
return true;
} else {
value = default(T);
return false;
}
}
}
#endregion
}
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Wow, thanks that is genius work.
I don't fully understand it at the moment but it is starting to make sense and is pretty cool.
Continuous effort - not strength or intelligence - is the key to unlocking our potential.(Winston Churchill)
|
|
|
|
|
Can this be done? I have a need to use a console application in the background with a c# gui feeding commands and reading output from it.
similar, but not limited to something like executing ping, feeding it the url or ip, then reading the responses. Any help would be appreciated.
______________________
Mr Griffin, eleventy billion is not a number...
|
|
|
|
|
Can you be more specific on what is going on in the background? We run console apps from web pages at my new job so I know it can be done. (Unless I have some weird definition of a console application.)
|
|
|
|
|
ideally, i would run psftp (putty sftp) in the background, feed it connection info and a "get" command and communicate the feedback to the gui app.
______________________
Mr Griffin, eleventy billion is not a number...
|
|
|
|
|
I'm not real familiar with psftp, but if no one else answers I'll try to do some research at home tonight based on what I know. Sorry I couldn't be more helpful out the gate.
|
|
|
|
|
Use the Process class and redirect the standard output and standard input streams. I have done it several times. It can be a PITA the way some exes deliver output compared to unix style, unfortunately.
Need a C# Consultant? I'm available.
Happiness in intelligent people is the rarest thing I know. -- Ernest Hemingway
|
|
|
|
|
Hello one and all,
I have problem with my single threaded C# Windows forms application. The application is designed to validate and save up to 600 records into db.
The application actually successfully processes all these records but when showing the result of the operation, (messagebox) the application does not respond with the CPU utilization factor reaching close to 100%. Sometimes after about 15 mins or so the application suddenly responds and sometimes not. This is happening in all the machines.
It would be wonderful if someone can help me out.
Warm regards,
Krishna
|
|
|
|
|
Without a code snippet or something, i'm not sure of how much help we can be. There is no reason the a simple call to MessageBox.Show should make your application hang, i think there must be something else.
My current favourite word is: Bacon!
-SK Genius
|
|
|
|
|
I have to agree with SK for the code. If it is on multiple machines, are people running the process at the same time?
|
|
|
|
|
600 records is a lot of data. Sometimes I have had similar problems based on memory usage. Check the memory usage and switch the 600 record update code into a worker thread allowing the UI free, independent reign and it could help.
Need a C# Consultant? I'm available.
Happiness in intelligent people is the rarest thing I know. -- Ernest Hemingway
|
|
|
|
|
Hello,
I thank you a lot for your time. Indeed the app works perfect and very fast if we run the operations on another thread but I am not supposed to use threads (my Manager does not like it. need more reason)however it would be of great help if you can explain why the app is running if I use multiple threads, will the allocated memory increase with another thread or something like that?.
Warm regards,
Krishna
|
|
|
|
|
What is the difference between bin\debug and obj\debug directories in a .NET project?
|
|
|
|
|
|
OK - So it looks like if I need to reference 3rd party dll's then the recommended practice is to put these dll's in the bin\Debug directory. Is this correct?
Since the name of the directory is "Debug", I wasn't sure about the implications of running the app in Release mode as opposed to Debug mode. Does this make a difference as far as the directory where the dll should be put?
|
|
|
|
|
Actually, the standard practice is to include them as a reference in the project. It handles them properly that way, so regardless of what build you're in..it places it into the proper folder.
1. Open your solution file.
2. Right click on the project file.
3. Select "Add Reference...".
4. Either select the third party dll's using the dialog (most likely the 'Browse' tab)
5. Build your project
6. Enjoy having Visual Studio handle the management of your third party dll's.
|
|
|
|
|
Of course - I know how to add a reference to a 3rd party dll.
The question is - where is the best place in my project to keep the physical dlls that I am adding a reference to?
|
|
|
|