|
This might sound a bit strange but how would i change the start position of the progress bar?
So it would render like this: [ |||||| ] go from 40% to 80%
Thanks for any help,
-- Cyonix
|
|
|
|
|
Hi Jonathan.
A bit later but I´m here, at the end of this week I release a new version of the progress bar and will try to add this feature.
cheers
------------
Take a look to my Articles[^]
|
|
|
|
|
Great, thank you very much
-- Cyonix
|
|
|
|
|
Great control you have there!
I would like to use it as a trackBar - so clicking into the progressBar should change it's "Position" property. I can't find a way to do this right now - perhaps, you (or someone) can help me?
Any hint would be apprechiated,
Florian
|
|
|
|
|
OK, I found a solution myself. I have to add, that I'm new to customising controls, so there might be a better solution...
private bool mMouseDown = false;
protected override void OnMouseDown(MouseEventArgs e)
{
this.mMouseDown = true;
this.Position = (int)((double)this.PositionMax * ((double)e.X / (double)this.Width));
base.OnMouseDown (e);
}
protected override void OnMouseUp(MouseEventArgs e)
{
this.mMouseDown = false;
base.OnMouseUp (e);
}
protected override void OnMouseMove(MouseEventArgs e)
{
if(mMouseDown)
{
this.Position = (int)((double)this.PositionMax * ((double)e.X/(double)this.Width));
}
base.OnMouseMove (e);
}
Greetings,
Florian
|
|
|
|
|
Nice work, exactly what I was looking for. Replaced the standard progress control I was using in minutes!
Thanks.
Mark.
|
|
|
|
|
I'm trying to do the same thing. These are great looking progress bars. But how do I drag them on the form? In other words, how do I select the Prog1 control and use it in other C# apps?
Greg
|
|
|
|
|
Thanks to sparky909 and you for the comments !!
You need to add the control to the toolbox, for this:
- Open the toolbox
- Right click on it.
- Choose add/remove elements
- Browse for the Framework.Controls.ProgressBar.dll
- Select the XpProgressBar control and walla !!!
Cheers !!
|
|
|
|
|
Thanks, Marcos. Works Great! I'll only use your progressbar controls.
Greg
|
|
|
|
|
Wonderful control, thanks a lot I'll use it everywhere now
|
|
|
|
|
... for the motivation !!!
|
|
|
|
|
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.
|
|
|
|
|