|
In the history it says 2.0 added "Vertical ProgressBar." Is this just the gradient specifier? I can't find a vertical property. Vertical progress bars seem to be rare without writing them from scratch.
Please advise on the vertical feature.
Thanks
J
|
|
|
|
|
The 1.5 and 2.0 items not are the history are only the RoadMap...The current version is 1.0
The editors trim this part, I'm working in the next version, maybe at the begining of the next year will be ready.
Thanks, sorry for the confusion .
Marcos
|
|
|
|
|
Yes I need too a Vertical Progress bar...
waiting for it !!!
Thanks
|
|
|
|
|
Application.DoEvents causes events in the event-queue to be fired.
Read that again. I did not say it fires only queued UI events. Any events that are queued are fired.
This can cause code re-entrant related, and other strange problems to arise when you least expect them. Quick example: You're code is happily spinning, chewing up CPU, and the user clicks the "Close" button -- what happens when you call Applicaiton.DoEvents? It certainly isn't gracefull, that's for sure. After the 'close' code runs, you're progress-bar code tries to continue running. I won't go into details as the evils of Application.DoEvents are discussed at length elsewhere. Here's a few to check out:
http://blogs.msdn.com/jfoscoding/archive/2005/08/06/448560.aspx[^]
http://www.codinghorror.com/blog/archives/000370.html[^]
http://ramblings.aaronballman.com/?p=196[^]
If you're method is hammering the CPU, and preventing your UI from updating in a timely manner, you should look into splitting that heavy method off onto a non-UI thread. The easiest way to do this, in .NET 2.0, is the BackgroundWorker. It's multithreading without all the work.
http://msdn2.microsoft.com/en-us/library/4852et58.aspx[^]
http://msdn.microsoft.com/msdnmag/issues/05/03/AdvancedBasics/[^]
Heck, there's even a CP article that discusses it:
http://www.codeproject.com/csharp/backgroundworker.asp[^]
I feel rather strongly about this because I have handled non-trivial DoEvent re-entrant related problems in the past, and they are no fun. Do it right the first time, and you'll never regret it.
...Anyway...just my $0.03.
|
|
|
|
|
I'll check this info, it seems to be interesting, but I've been using DoEvents in all my Apps and I never had problems with it.
If it is well used, maybe the problems will not arise.
At the end not everybody want to write a multithread app to correct the painting of the progress bar, but I'll try your solutions to see the differences.
This is an extract of the article that you referenced above
The best example of DoEvents is in the updating of the Progress Bar while loading a large file. Using a DoEvents every 1000 bytes or so gives a nice crisp response on the progress bar and is far easier to implement than a threaded solution.
Thanks a lot !!!
Greetings from Argentina
|
|
|
|
|
I agree with you, DoEvents does work in many situations. Especially a simple progress-bar situation where nothing else could/should be going on in the background.
Like I mentioned in my first comment, I'm of the mindset of just doing it 'right' the first time, and being reasonably sure it won't come back to bite me in the rear. I try to take a 'best-practices' approach to most things.
An example of what I consider doing-it-right-the-first time:
I've created a ProgressForm -- it's just a simple Form with a ProgressBar. The constructor takes a delegate to a 'worker' method. This ProgressForm, upon loading and showing, prepares and starts a BackgroundWorker. The BackgroundWorker calls the specified worker delegate. The worker method gets a handle to the BackgroundWorker, through which it can indicate it's progress back to the ProgressForm's progress bar. The heavy worker method hammers the CPU, yet the UI is still responsive, and with no DoEvents -- win-win. If you didn't know better, you'd never even know that it's multithreaded. The best part? The progress form is completely generic, it cares not one bit about your worker method. Code once, use it many times.
I've heard people many times say they've been using DoEvents for -years- and have never experienced a problem. I was the same. I understand how hard it is to even think of a situation where using DoEvents could cause problems during the normal use of your application. As such, let me describe the first time DoEvents gave me a hard time. (Forgive me, this is a bit long-winded, and rambly )
I was working on an application that used a GPS for input to a mapping application. The GPS was connected to a COM port. When the COM port's buffer filled with data from the GPS, a "BufferFull" event was raised. In that BufferFull event handler, I parsed and processed the data from the GPS into a format the application could use. After the data was processed, secondary events were raised (by my code,) to indicate to other parts of the application that processed information had been captured, parsed, processed, and was ready for it to use.
The operations in some of these secondary event handlers were a bit on the 'heavy' side of things because they had to interact with the mapping API. Fortunately (unfortunately, actually,) in most cases, the load was never very heavy, and no problems were ever experienced. But still, to ensure the UI was responsive, I enlisted the use of a few DoEvents here-n-there where I thought the code could hang-up the UI on a larger-than-average data set.
DoEvents came back to haunt me when we picked up a user who's map data was much larger than anything we'd dealt with before. As can be expected, those heavy secondary-processing operations were taking longer to process through the mapping API. When those heavy methods fired-off a DoEvents in the past, it simply refreshed the UI because the UI Paint events were the only things in the event queue.
Not anymore.
With this larger-than-average data set causing the heavy secondary operation to take longer than expected, more than UI Paint events were sitting in the event queue -- COM port BufferFull events were sitting there as well! Data was coming in faster than it could be used!
So, in the middle of the data being secondarily processed against the mapping API, new data was coming in, getting parsed/processed, and then secondarily processed, all before the first data was secondarily processed! Sometimes the problem would 'uncongest' and catch up, giving the user, at the worst, strange results. Usually, it would cripple the app, and bring it to it's knees.
All this, in an app that had been working for literally more than a years time, now brought to it's knees because DoEvents was used to refresh the UI.
So, in conclusion, I'm only looking to offer you my advice. I used to be a use DoEvents all the time. No longer.
|
|
|
|
|
I agree, DoEvents is EVIL!
I was a C++ programmer for years, then came to an position with a lot of VB code ... scattered with DoEvents just to be able to press Cancel buttons, and update Progress bars etc. There were also thousands of lines of code to disable controls all over the place just so the user couldn't click those instead of the Cancel button. It generally worked, but some things couldn't be stopped, like clicking minimize, etc. And if new controls were added, it was a nightmare trying to make it so the user couldn't hose the app.
I eventually wrote a set of speciallized DoEvents functions. One would go through the queued events and process just certain kinds, another just those for a certain control. Then I dropped all the control disableing code, and replaced the DoEvents calls with DoEvents functions to process the pain messages for a given window/control, accept any message from a specified control (ex. Cancel button). The code than was easy to read and maintain, and much more safe that before.
When we moved to C# 1.5 years ago I almost tore my hair out when I found out they had a DoEvents!!! But since it would be all new code, I laid down the law and said "Thou Shalt Not DoEvents!" ... we are multi-threaded where needed and all is weel in the world
|
|
|
|
|
Hi !! i would like to use your progress bar to my Windows APP.
And i have two buttons to my application that import and export data to my hockey website.
How do i setup my Timer with the data Weight or time to will take to transfert the data so i can show somethign to my user !
thankx !
|
|
|
|
|
Contact me by email to marcosdotnet[at]yahoo.com.ar to send me more info.
What I do is set the PositionMax of the Progress Bar to the weight of the data and in the timer update its position.
Cheers
|
|
|
|
|
|
good work and thanks for a great control
|
|
|
|
|
Thanks for your comments, i'm finishing the version 1.1 come back soon.
|
|
|
|
|
Is this control free for commercial use?
|
|
|
|
|
yes the control and source code are Completely Free.
A vote is enough.
Enjoy it.
|
|
|
|
|
I must say the progress bar look great. Good work
|
|
|
|
|
Thanks, i use your analog clock control in my apps, is a fantastic work !!!!
Highly recommended Obaid´s Analog Clock
|
|
|
|
|
Hi!
It would be great if you could implement a never ending progressbar, that is, one that goes back and forth (like when XP starts).
I couldn't find one yet.
Nice control!
|
|
|
|
|
Thanks.. i work on your idea, but i see a control that do exactly what you want, i search my computer and send you a link.
Please if tou can, vote for the post.
Greetings from argentina (The mate country)
|
|
|
|
|
|
I use an animated GIF for a never-ending progressbar.
Look in "C:\WINNT\PCHealth\HelpCtr\System\images\progbar.gif"
Cheers
Craigo
|
|
|
|
|
Here is one that works (more or less) in windows 2000 and xp. If you are just targeting xp I think you can use visual styles to get the same effect.
Peace
-- modified at 11:29 Thursday 6th October, 2005
Hah! I forgot the URL...http://www.codeproject.com/cs/miscctrl/indeterminateprogressbar.asp
|
|
|
|
|
I wrote an activity bar a while back which does what you're talking about: http://kentb.blogspot.com/2005/02/activity-bar.html or download from GotDotNet: http://www.gotdotnet.com/Community/UserSamples/Details.aspx?SampleGuid=88BAA5BE-DFA6-4038-81D4-1715BA3A41BA
Well done on the progress bar - looks fantastic!
|
|
|
|
|