I am developing my system using WPF with MVVM and I am having trouble to find out the best way to solve the following problem:
I have a screen in which many components (User Controls) are drawn at specific positions. All components in the screen are rotated, translated and scaled according to binded variables calculated by the screen's VM.
However, each of this components could have a different center for the rotation, a different origin for the translation and a different scale, dependent of internal variables and the screen scale.
How is it possible to make this transformations calculated internally in the User Control? I think the easier approach is using the Converter, however since I have many different User Controls with different behaviours, I would have to create multiple converters very similar to each other, which would not be the ideal solution.
Thank you very much for the help!
A UIElement has only one RenderTransformOrigin.
Some transformations allow you to set the origin for that transformation but in coordinates relative to the control bounds (e.g.: 125, 34) not in proportional coordinates like the RenderOrigin (e.g.: 0.5, 0.75)
So if you can use the coordinates you're good to go.
If not, you could compose the transformations by creating Transformation groups that first translate the control, then perform the transformation, and then translate the control back.
If you need more help, please post an example of what you are trying to achieve.
Related
I was looking for a way to scale part of a wpf form properly when I came across this post on SO. It actually told me quickly and succinctly what I needed to know but got me to wondering on the following question.
I have identified a need for a control with a particular degree of functionality and as such it's a perfect candidate for a user control. One thing that it will need to be is scalable. If I were to enclose the contents of my user control in a viewbox (and there were several of those controls on a form in a wpf application) would they conflict with any viewbox that might be wrapping all of the controls on a form? In other words when designing user controls that require a degree of scalability is it acceptable to just 'wrap' the contents of the user control in a viewbox?
Thanks
The Viewbox will "stretch/scale a single child element to the fill the available space". You shouldn't run into any issues with Viewboxes at various nested levels composing a larger control (and it's fairly easy to test some general layouts in a mock project).
What is worth considering, is if the simple Viewbox scaling behaviour is actually what you're after. If you wanted say, a particular button to increase in size, or certain elements to stretch horizontally, you may get more mileage from various Grid layout options, with relative / proportional sizing/stretching.
Of course, the Viewbox scaling may be exactly what you're after =D
I have a question regarding WPF programming, and it's with regards to whether we can check if a certain percentage of a shape is intersecting/overlapping with another shape. My intention is to create a minigame where there will be a model (e.g. a cube), and the app will apply a random Transform to it. The user then needs to manually rotate and resize the model using given controls, and fit it into (roughly) the randomly Transform-ed cube.
Is there any method/algorithm I can apply for two ModelVisual3Ds within the same Viewport3D? It would be ideal if the method can return a percentage (e.g. 0.8, 0.9), so that I can tweak it to accept only if the percentage is above a certain level.
Many thanks!
I'm looking at some new options for displaying a percentage value as a fill in a custom shape. Consider the effect to be similar to a "progress thermometer" in a traditional dashboard UI sense.
Considerations
Goal - a graphic element showing a percentage value for a custom report.
Format - Either a full graphic (or infographic) itself, or part of a PDF via Photoshop/InDesign or even iBooks (as an excuse to use it).
Usage - I'd like the process to be programmatic, for re-use. It needs to be accurate, and I'd like the solution to be somewhat object oriented to apply to other datasets and graphical containers. This rules out hand-drawn charting.
Source data - currently a pivot table in Excel, but I can work with any other host as required.
Shape - is a custom vector shape that will originate from Illustrator/Inkscape. final format as best fits resolution and rendering of the report. I would also be interested in any other generative shape ideas (such as java/javascript).
Fill - I'd like to be able to represent the fill as both an actual percentage of total area (true up), and as a percentage of the vertical scale. I'd imagine this flexibility would also help reuse of the method as a fill value against selected object variables (height, area, whatever).
I know I'm being slightly vague in the programming languages or hosts side of things, but this gives me an opportunity to break out of the usual analytic toolchain and scope out some innovative or new solutions. I'm specifically interested in open source solutions, but I'm very keen to review other current methods you might suggest.
This might be a little open ended for you, but d3.js is very powerful. There might be some useful templates on the site, or you can build your own from the library.
If you limit yourself to shapes where the percentage can be easily converted into a new shape by varying one of the dimensions, then the display part can be covered by creating a second shape based on the first one, and filling in 100% of the second shape.
This obviously works best with simple shapes like squares, rectangles, circles, etc, where it is simple to convert "50% of the area" or "75% of the height" into manipulation of vector nodes.
However, things gets significantly more difficult if you want to support genuinely arbitrary custom shapes. One way to handle that would be to break up a complex "progress bar" into "progress pieces" (e.g. a thermometer bulb that represents 10% of total progress, then a simple bar for the remaining 90%).
As has been mentioned, D3 seems like it would meet your needs - here are some simple examples of what I think you are asking:
Changing the fill color of a distinct shape: http://jsfiddle.net/jsl6906/YCMb8/
Changing the 'fill amount' of a simple shape: http://jsfiddle.net/jsl6906/YCMb8/1/
Given a WPF Application running full screen, a fair amount of controls some of which will animate from off screen to center. I was wondering if there are any special ways to save on the amount of time required to optimize an application for different screen resolutions?
For example, using Blend I've setup some text, which is originally off screen to scroll into view. Now in design mode the start positions are static. If resolution changes the start positions will obviously not be correct.
So I guess to correct this, during app startup. I need to
Check resolution
Move the text box to the desired start location
Adjust the storyboard as required, so the frames all have correct co-ordinates depending on the res of the screen.
I don't mind doing all of this, but if there is an easier way please share!
Thanks
In WPF layout of controls should be made in such way, that when size of window or content changes, controls automaticaly resize/reposition themselves to reflect this change.
This is highly affected how your layout is made, especialy by using specific panels, that do layout of their child elements.
This is also made obvious by using device-independent units for sizes, margins and sometimes positions of controls. And also allows different kind of zooming and scaling of whole UI without any need to redesign the whole thing.
If you are trying to position your controls absolutely, either by using Canvas panel or margins, your are doing it totaly wrong.
In WPF, scene is measured in abstract units, not pixels, and controls are freely scaled. There should be no problems to center something, or what?
What is the best approach to render charts and then save them on a hard drive for further distribution using WPF?
I found a number of ways to accomplish this by using the following types:
DrawingVisual - creating a object of this type and then rendering graphics on its context;
Shape - deriving from the Shape class and then overriding its DefiningGeometry property where the actual rendering is happening;
PathFigure - adding LineSegment-s to an instance of this class and then adding this instance to a Canvas;
Adorner - deriving from it and then overriding its OnRender method;
WritableBitmap - rendering on it and then adding the bitmap to a Canvas.
Of course I'm going to write an app to test how fast each of these will be. But can anybody tell me:
whether am I on the right track?
are there any other means to do such rendering?
which one of them is the best in
terms of performance?
It all depends on your actual usage, in your case you mention saving on the hard drive for "further distribution" - I'm going to assume you are saving them as an image (jpg or png) and not as wpf objects (xaml).
You should consider if WPF is the right tool for the job, WPF is a UI framework and not a generic image processing library, it may be best to use something else entirely for generating images.
For a reasonable number of points your performance bottleneck will be encoding the image and saving it to disk - not actually rendering it - so you should choose the method that is easier for you to code.
All the articles about high performance WPF charts are a: about charts with 10,000 points and more (because that is where the performance problems are), b: about charts you display in your GUI (because otherwise you can use an image processing library to create the bitmap) and c: charts that change all the time (so they work nicely with data binding) - there's a reason why they don't talk about saving charts to disk.
For a very large number of points:
The fastest way to draw in WPF is to inherit from FrameworkElement (not Adorner) and override OnRender.
When the data changes often it is recommended to use multiple DrawingVisual objects because then you don't have to re-render everything when one value change - but this is not relevant for you since the image won't change after you save it anyway.
WritableBitmap is used for raw bitmap access, you use it when you decide to give up on all the nice layout and drawing WPF gives you because you can't take the overhead, if this is the case you should re-read my first point above.
So, to summarize, you are asking the wrong question :-) if you need to save images to disk than either the WPF rendering speed is not your bottleneck or you shouldn't be using WPF to begin with. If you do use WPF just pick whatever is easiest for you to code.
BTW: Adorners are used to display "floating" elements above the normal UI, you can use them for tooltip-like features but not for the main chart rendering (and you probably don't want them at all since your main usage is saving the image to disk), FrameworkElement is the base class you are looking for.