I am looking for how-to information on how to create a progress bar that looks like a Windows 10 version, especially when the task is not done, there is a glowing markee on the "done" area of the progress bar.
Something like during a "Windows Explorer" search... until the search is done you'll see the progress bar is glowing.
I tried googling around, and all sites are explaining just the simple and straightforward progressbar.
EDIT
Thanks for the below answers... to emphasize what i'm looking for, take a look at the below picture.... This is a sanpshot from a simple copy dialog. you can see while the copy is in progress, a glowing effect on the progress bar itself.
I'm not sure whether this is what you're looking for but there is an IsIndeterminate property on the standard ProgressBar, which when set to true, gives a continuous effect rather than a bar which represents a value relative to a determinate, finite maximum value. See MSDN Progress Bar IsIndeterminate
Related
I have a chart which looks like this:
When I zoom into a section, the labels disappear:
However, I can get the labels back by scrolling all the way to the right and releasing the mouse:
And then when I scroll back to the left, the labels are all visible:
This behaviour is just super weird am I'm completely dumbfounded as to what would cause this, or even how to debug.
Does anyone have any ideas on what I could try to fix this? I'd like the labels to be shown as in the last image, but when first zooming.
It looks like others have had similar issues, so I'm going to try combining several answers I found online to maybe help fix your issue.
John (DevExpress Support) says:
It appears that the AutoLayout feature leads to this issue. Please set the ChartControl.AutoLayout property to False. This should make axis label elements visible.
https://www.devexpress.com/Support/Center/Question/Details/T328948/x-axis-labels-disappear-in-chartcontrol
Valdemar (DevExpress Support) says:
I suggest that you use the Axis2D.ResolveOverlappingOptions properties. Set AllowHide to False:
[XAML]
<dxc:XYDiagram2D.AxisX>
<dxc:AxisX2D >
<dxc:AxisX2D.Label>
<dxc:AxisLabel>
<dxc:Axis2D.ResolveOverlappingOptions>
<dxc:AxisLabelResolveOverlappingOptions AllowRotate="True" AllowStagger="True" AllowHide="False" />
</dxc:Axis2D.ResolveOverlappingOptions>
</dxc:AxisLabel>
</dxc:AxisX2D.Label>
</dxc:AxisX2D>
</dxc:XYDiagram2D.AxisX>
https://www.devexpress.com/Support/Center/Question/Details/Q489042/chart-axis-labels-disappearing-when-chart-is-resized
SharpStatistics says:
The only way I could replicate the problem you describe is by setting the x axis Label.style interval to a specific value, say,
area1.AxisX.LabelStyle.Interval = 100;
and then when I zoom in on the chart if the zoomed x axis section is less than 100 I don't see any lables.
loi-se (the OP) replies:
Thanks for your suggestion! But as far as i know i don't set the xaxis labelstyle anywhere, i just use: Chartarea1.AxisX.IntervalAutoMode = IntervalAutoMode.VariableCount
This works fine in the case of the yaxis but the xaxis seems to behave on its own will. Maybe i should renew my .net framework installation and get the latest version of the chart component? Any other suggestions?
https://social.msdn.microsoft.com/Forums/vstudio/en-US/d345d4a3-a4be-4b41-9c83-9a9d9dbb69b9/the-labels-of-the-xaxis-are-disappearing-when-i-zoom-in?forum=MSWinWebChart
This one is for SSRS reports, but I'm assuming it uses the same (or similar library) and supports the link right above this one.
When designing an SSRS Report using Chart you may notice that some of the labels whether in X or Y axis are not being displayed, this is because it’s so smart that it detects what you actually want (not!).
To display all labels follow the steps below:
Right click either the X or Y axis, Click Properties:
Set the Interval to 1:
Viola!
https://randypaulo.com/2012/02/20/ssrs-chart-label-missing-xy-axis-missing/
That's about all I can find that are similar, without spending a bunch more time researching this. Hopefully something here helped!
Hi everyone I would like to implement an ImageViewer (like the one in Facebook for example) in a WPF application
I already have a ListBox whith my pictures, it works well. But I would like to add pop "image full size" when the user double click on one of them. (something like in FB, with a fade out of the background etc).
Currently I'm thinking of to use a Window...Do you have a better idea of what I should use ?
i would probably use a window for that as well. Then you can easily put an opacity animation when the window loads to give it the fade in and fade out effect
You could also use a Popup control.
It comes with some some built in (but very limited) animations, like fade, see PopupAnimation.
I'd try that and if it doesn't fit your needs, I second bflosabre91 oppionion and would use a separate opacity animated window.
But bear in mind that with an additional window you could have negative side effects e.g always sync the window positions correctly, handle task switches (ie. correctly hide the window in the taskbar/tasklist)
I have a WPF window that contains a fancy image with roughly 200 controls (derived from buttons), all of which use one of my 5 templates (paths, shadow effects, etc). Agreed, it is a heavy window to draw. I can live with that.
My problem comes from resizing the window. Maximize/Restore take about 1-2 seconds, but manually dragging the bottom-left corner causes the system to hang for about 5-10 seconds. In that delay, the window is black & contains partial leftovers until the final result is shown. It looks amateurish and that, I can't live with.
Remote connection : using a remote account, I found that the window resize always takes 1-2 seconds, but doesn't draw the "intermediate" stages while I'm dragging the window borders. The result is as snappy as I would expect.
My conclusion is this: It's the redraws during the resize that are bottlenecks.
The inevitable question is this : how can I prevent redrawing the window until the resize is finished?
Thanks in advance for any ideas...
#Seb: I'm beginning to think WPF is
not designed for interfaces that go
beyond 2-3 controls at a time
Visual Studio 2010 and Expression Blend should be good counterexamples. Though Visual Studio sometimes freezes the bottleneck is definitely not in the WPF rendering.
#Seb: The inevitable question is this : how
can I prevent redrawing the window
until the resize is finished?
Simply set the window's content visibility to Visibility.Collapsed before the resize/maximize and make it visible afterwards. Though I think you asked the wrong question. Here is the right one
How to make my controls measure/arrange extremely fast?
And to answer it you should take a look at your code. Maybe you intensively use dependency properties in the measuring/arrange algorithm? Or maybe you picked wrong panels (e.g. Grid is slower than Canvas)? Or maybe... I stop guessing here :).
By the way, it's always better to launch your app under profiler and prove the bottleneck rather than assuming the place where it might be. Check Eqatec Profiler it's free yet powerful enough. VS 2010 also offers nice profiling features, though it's far from being free. And you may want to check WPF Performance Suite.
Hope this helps.
Let me know how this works... I am assuming that your root visual item is stretching to horizontally and vertically to fill your window with auto height/width. Get rid of the Auto height/width. On app start up set the dimensions of the root element. There is a FrameworkElements have a size changed event. Register for this on your Application.Current.MainWindow (maybe be a typo, that was from memory). Whenever this event fires, start a timer with a small interval. If you get another resize while the timer is running, ignore it and reset the timer. Once the timer fires, you now know the new size the user desires and that they have (at least for a short period) stopped resizing the window.
Hope that helps!
From Ragepotato's answer and your comment about needing to see roughly what the interface would look like while resizing, as long as you don't have your objects dynamically re-locating themselves (like a Wrap Panel) - you could take a screenshot of the window contents and fill your frame with it.
Set it to stretch both height and width, and you'd get a (slightly fuzzy) idea of what a particular size would be. It wouldn't be live while resizing, but for those few seconds that probably wouldn't matter..
In WinForms you could set a progress bar to loop endlessly to indicate that you don't know how long it will take. How would I do that in WPF?
<ProgressBar IsIndeterminate="True" />
I personally like the approach Visual Studio 2010 takes. They use an animation of a small, looping series of dots (with varying intensity). They just animate the dots circling in the center of the window in question.
In WPF, this is trivial - just animate a rotation of a small drawing of a circle of dots with the opacity set correctly up front.
I find it very intuitive, small, and unintrusive.
Is a progress bar the right widget for this? You are unable to indicate a % complete, since you "don't know how long it will take". Maybe an animation of some sort (like the Windows files-disappearing-into-thin-air-while-deleting effect) to show that activity is still going on would be better. But a "progress" bar that simply resets to zero because there is still more work to do just looks dumb to me.
In processing a group of items, I wanted to display a unified image of the status of the group, so I essentially made a Grid of a number of progressbars with transparent backgrounds and various colored foregrounds all at the same cell.
I'm running into some transparency artifacts (purple bar is actually purple under the green, and sometimes it draws over the top, etc) and it just seems a bit wasteful. So, I decided to make my own, but now I've got a bit of paralysis on how to do it. Do I use the DrawingContext in FrameworkElement's OnRender, or is there something simpler? Is there a set of general rules when it comes to making your own control?
I pondered switching to a pie chart since those are easy to come by, but its high time I did something not off-the-shelf.
Thanks!
I'm not quite sure how you intend the progressbar to combine different progresses, but if say the furthest along progress is at the bottom of the z-index and the least along progress is at the top, then I'd do something on the lines of this:
1) I would probably create a user control for this new progresbar.
2) It would have a property called NumberOfProgresses, that is tied with an array containing status of said progresses.
3) Each progress would be represented by a Border item (or perhaps something more suitable up the visual tree), because it's a simple wpf control with a background property. The background property would be set to nice a looking progress style and the progress color can be bound in the style to say the border's borderbrush property. Making it easy to set the color of the progress.
4) The user control would have a method UpdateProgress which takes the percentage value and the index of the progress in the array as parameters.
5) As progresses are updated you can either, just calculate the appropriate width (user control actual width * percentage) for the border and play around with the Z index to get it displayed at the top/bottom, or stack the borders horizontaly, set the least along progress as first, then for the rest of the progresses you'd have to substract previous progresses lengths to get the same effect.
This way there would be no transparency induced artifacts and no OnRender()...
Mind you, in WPF there should be no reason to mess with OnRender this and OnRender that, like it was required in WinForms with OnPaint.
Just set up the elements via code to get the look you want, and let WPF do it's rendering ;)
I can imagine one problem with this user control though. You'd have to provide feedback to the user as to which color belongs to which progress. But that would probably take you back to square one, meaning it's better/simpler to just display multiple progressbars.