The code for the calculation is al that's required - no rotate transforms, etc. Personally I think it's a lot more elegant than what you originally described, but then again I haven't seen that code. It's an alternative anyway...
Chris On 3 July 2010 22:34, Xerxes Battiwalla <[email protected]> wrote: > i see what you mean, now. > > Given this would also mean require some code to do the calc (in either the > view or the VM), what other reasons would you recommend for this method over > using the grid as we did? performance reasons, or am i just being pedantic? > ;) > > -x > > > On Sat, Jul 3, 2010 at 10:07 PM, Chris Anderson > <[email protected]>wrote: > >> OK, well that makes it clearer then. Well a ScaleY of 1 = 100% of the >> height of the Rectangle. Therefore, instead of setting the height of the >> Rectangle to the height of a single unit (as per my example), it should be >> set to a height representing the maximum value that the control should >> display (note that the CenterY property will need to be bound to the height >> of the Rectangle so that it can show the negative values). >> >> If your ViewModel had a MaxValue property and a Value property, then you >> would set the ScaleY = Value / MaxValue. You could do this in your >> ViewModel (not ideal), or use a ValueConverter to do the calculation. Even >> better, wrap it up into a custom control, and do the calculation in it >> instead. >> >> Hope this helps... >> >> Chris >> >> >> On 3 July 2010 21:52, Xerxes Battiwalla <[email protected]> wrote: >> >>> yep, plugged it into a blank app, and been playing around with it. >>> >>> Yes - the size of the control should be the max. Sorry - i omitted that >>> extra bit of info from the original post thinking it wouldnt be >>> relevant...The entire gauge control is to have a fixed height (say 400px). >>> This means there's 200px representing the positive scale and 200 for the >>> negative scale. >>> >>> This control gets dropped onto View A which requires a range from 30 to >>> -30. 1 increment on this control = 200px / 30 = 6.67px...if i increase 30 >>> times, the bar is filled up to its top border. The same control is then >>> dropped onto view B which requires a range of -5 to 5. each increment is now >>> 200px / 5 = 40px. It takes 5 clicks to fill the bar. >>> >>> The scale transform requires an absolute size, doesnt it? how would you >>> do it using a scaletransform? we initially started with that but decided >>> against it because our code had to know the height of the control in order >>> to calculate the increment size... >>> >>> thanks for your help :) >>> >>> -x >>> >>> ps I just realised i should mention that the maximum and minimum values >>> are equidistant (-30 to 30, -5 to 5, -14 to 14 etc etc), in case you were >>> wondering ;) >>> >>> >>> >>> >>> >>> On Sat, Jul 3, 2010 at 9:00 PM, Chris Anderson >>> <[email protected]>wrote: >>> >>>> The increment size is determined by the height of the Rectangle. In the >>>> example it had a height of 20px = 1 unit. So yes, this is coded in the >>>> view. But to me, that's where it belongs. The bigger the range that is to >>>> be represented, the smaller the height you would give the Rectangle. Are >>>> you saying that you want to treat whatever size the rectangle is as the >>>> maximum value it can display (100%), and then have it calculate the >>>> increments in between this? You could do that too using a ScaleTransform. >>>> I guess I'm a bit lost though as to the exact problem. Based on your >>>> original problem description, the one in my example seemed to fit what you >>>> were after. Did you give it a go? >>>> >>>> Chris >>>> >>>> >>>> On 3 July 2010 20:41, Xerxes Battiwalla <[email protected]> wrote: >>>> >>>>> Sure, but the problem here is that the proportion of each increment is >>>>> a fixed size, as coded in the view. >>>>> >>>>> we need to have a variable increment size depending on which view the >>>>> control is used in. in some views it might have a range of -30 to 30 and >>>>> in >>>>> other views the range could be different yet again, changing the size of >>>>> each increment. >>>>> >>>>> >>>>> On Sat, Jul 3, 2010 at 2:30 PM, Chris Anderson < >>>>> [email protected]> wrote: >>>>> >>>>>> Not at all. Throw the following XAML on a view: >>>>>> >>>>>> <Rectangle Height="20" Width="50" Margin="118,130,0,0" >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> HorizontalAlignment="Left" VerticalAlignment="Top" > >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> <Rectangle.Fill> >>>>>> <LinearGradientBrush EndPoint="1,0.5" StartPoint="0,0.5"> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> <GradientStop Color="#FF2B7911" Offset="0" /> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> <GradientStop Color="#FF56FF00" Offset="1" /> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> </LinearGradientBrush> >>>>>> </Rectangle.Fill> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> <Rectangle.RenderTransform> >>>>>> <ScaleTransform ScaleY="1" CenterY="20" /> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> </Rectangle.RenderTransform> >>>>>> </Rectangle> >>>>>> >>>>>> You'll get a little bar indicating a value of 1. Now change the >>>>>> ScaleY property of the transform to 6. Then try changing it to -6. >>>>>> Represents exactly what you are after. Then you can bind the ScaleY >>>>>> property directly to your ViewModel property that exposes the value to >>>>>> display. >>>>>> >>>>>> Note: There is an artefact at the top and bottom of the rectangle that >>>>>> appears when it is scaled. Maybe someone has an answer to prevent that? >>>>>> I'm sure there's a way, just not off the top of my head. This solution >>>>>> solves your primary problem however. >>>>>> >>>>>> Hope this helps. >>>>>> >>>>>> Chris >>>>>> >>>>>> >>>>>> On 3 July 2010 13:09, Xerxes Battiwalla <[email protected]> wrote: >>>>>> >>>>>>> Correct me if I'm wrong here, but that would then mean the vm has to >>>>>>> know the height of the control in order to set the correct proportion? >>>>>>> Using >>>>>>> star values at least means the vm only has to know about ratios and >>>>>>> proportions, not absolute heights >>>>>>> >>>>>>> sent from my phone >>>>>>> >>>>>>> On 2 Jul 2010 08:49, "Chris Anderson" <[email protected]> >>>>>>> wrote: >>>>>>> > I'd personally use a scale transform rather than star values. It >>>>>>> would >>>>>>> > allow you to bind the ScaleY property to a view model property with >>>>>>> the >>>>>>> > value to display however, so no need for code-behind. >>>>>>> > >>>>>>> > Chris >>>>>>> > >>>>>>> > >>>>>>> > On 2 July 2010 08:38, Xerxes Battiwalla <[email protected]> wrote: >>>>>>> > >>>>>>> >> Hi everyone, >>>>>>> >> >>>>>>> >> This week we've needed to create a gauge control which is used to >>>>>>> indicate >>>>>>> >> positive values by filling a bar from the middle of the gauge >>>>>>> upward, and >>>>>>> >> negative values from the middle downward. A picture is worth a >>>>>>> thousand >>>>>>> >> words, so here's a QnD of what the control should do: >>>>>>> >> http://www.xerxesb.com/wp-content/uploads/2010/07/gauges.png >>>>>>> >> >>>>>>> >> The first gauge shows the control in its initial state. When the >>>>>>> user >>>>>>> >> presses the up arrow, the control increases in single increments >>>>>>> (as in the >>>>>>> >> second gauge) and when they press down it goes in reverse (third >>>>>>> gauge) >>>>>>> >> >>>>>>> >> We managed to do it, but I wanted to canvas how everyone else >>>>>>> would >>>>>>> >> implement the same control? >>>>>>> >> >>>>>>> >> Our implementation basically used a fill for the green bit, and >>>>>>> placed it >>>>>>> >> inside a grid with two rows (the grid was only half the size of >>>>>>> the whole >>>>>>> >> bar, and by default positioned to the entire height of the >>>>>>> positive side of >>>>>>> >> the gauge). The fill's size was set to take up the entire bottom >>>>>>> row, and we >>>>>>> >> then had some code in the code-behind to set the size of both rows >>>>>>> using >>>>>>> >> star values. If the value was negative we then apply a >>>>>>> RenderTransform to >>>>>>> >> flip the fill upside down. It works, but feels kludgy. Was hoping >>>>>>> there is a >>>>>>> >> XAML only way of doing something like this? >>>>>>> >> >>>>>>> >> Cheers, >>>>>>> >> Xerx >>>>>>> >> >>>>>>> >> _______________________________________________ >>>>>>> >> ozwpf mailing list >>>>>>> >> [email protected] >>>>>>> >> http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf >>>>>>> >> >>>>>>> >> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> ozwpf mailing list >>>>>>> [email protected] >>>>>>> http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> ozwpf mailing list >>>>>> [email protected] >>>>>> http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> ozwpf mailing list >>>>> [email protected] >>>>> http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> ozwpf mailing list >>>> [email protected] >>>> http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf >>>> >>>> >>> >>> _______________________________________________ >>> ozwpf mailing list >>> [email protected] >>> http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf >>> >>> >> >> _______________________________________________ >> ozwpf mailing list >> [email protected] >> http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf >> >> > > _______________________________________________ > ozwpf mailing list > [email protected] > http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf > >
_______________________________________________ ozwpf mailing list [email protected] http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf
