I've been trying to create a method to change the opacity of an object when I select it in a combo box so that I can see another object behind it. This is done prior to changing the camera position/direction to follow the 2nd object from the 1st object's position. This is done by cloning the object's default material with
this.DefaultMaterial = this.DefaultMaterial.Clone();
and then calling the
MaterialHelper.ChangeOpacity(DefaultMaterial,0.1);
method as I've written it out there.
The opacity seems to work properly for the most part, but for some of the objects in the view port, I can't see them through my initial opaque object. For instance, when I turn the camera to the particular object in question (the buggy one), instead of being able to see it behind my initial object I see through my initial object and past the second one(the buggy one) as if the buggy one wasn't even there. I just see what's behind it.
I have no idea why this is happening.
Does anyone know what could be causing this? Or if maybe there is a different way of making something transparent rather than setting its Opacity?
I saw some people referencing a TRANSPARENCY property, but wasn't sure if that applies to a FileModelVisual3D object, which is what the initial object is.
The buggy object is a UIElement3D, the opaque one is a FileModelVisual3D, there are other objects of the Point3DCollection class which also have the bug, as the UIElement3D does.
Because of the RenderOrder and depth buffer. You have to move your transparent object to the end of the rendering. It's not a bug, it's how rendering works.
Or change to use Helix-toolkit sharpdx, and use transparent rendering pass.
Related
Hi when I set ShowItemToolTips of a ListView with checkbox items to true in designer and change it to false in the code, the event ItemChecked is raised. The checked state itself is not changed though. But inside the (also raised) ItemCheck event the old value is not equal to the new value but the new value is the value that was previously visible. It seems like the items are re-inserted or reset in some way.
I tested this on two machines and projects. Why does this happen and how can I avoid it?
I'll explain the "why", a workaround is hard to come by. Some control properties are very impactful and can have odd side-effects when you change them. Like ShowItemToolTips, changing it after the ListView is created requires Winforms to completely destroy the native control and recreate it from scratch. Under the hood, it is a style flag (LVS_EX_INFOTIP) that's specified in the CreateWindowEx() call. The Control.RecreateHandle() method ensures it is effective. You'll see the flicker that this causes if you look closely.
So for a brief moment, the native control exists without yet being initialized with the original checkbox states. Getting a flaky event for that is a bug, but it is the kind that was either never fixed because doing so was too difficult or was just never discovered because nobody ever changes the ShowItemToolTips property after the control was created. It is very uncommon to do so.
In general, this native control re-creation trick has been a significant bug generator in Winforms. And workarounds are hard to come by, they fit either in the "deal with it" or the "don't do it" category. With the latter one strongly recommended in this case.
I've stuck with one pretty trivial problem (at first look).
Simplified version of my situation looks like this:
I want multiple Background(for example) colors to be applied to SAME Control and to be able to clear only some of them (by condition). WPF does not offer such capability, I can set only one value for each DP.
So, I want to apply Yellow then Green then Red colors successively to Control object and then be able to reset Red so that Control will be with Green background (on the other hand, reseting Green leaves background Red). Looks pretty simple, have you ever created such Decorator for Control? I believe DP internally use such behavior, but there are no public APIs for it.
Please, do not suggest using triggers or any other kinds of conditional DP setting, I really need to set multiple values for single DP and to be able to manage them
Its not a good idea to say "do not suggest" ... Anyway, Well its not possible, and WPF does not do this, what you might meant is the value precendence but this List is fixed, you can't just add another layer in between, for good reasons. The whole system relys on that. Otherwise you could not set one value and use triggers to override it and don't need to take care of resetting the value. Also animations, Style inheritence etc. wouldn't be possible if people start to mess with this list.
So you don't like the trigger idea ... Why? Its exactly for that.
Ok, if you don't like it, how about adding an attached property for Background1, Background2 etc. You also could make Background as an attached property and make it inheritable. You could make an attached behavior, listen to property changes and modify your Background color. You could use a MultiBinding or PriorityBinding.
Well alot of stuff is possible if the obvious solution is not desired :)
I have a Button in Silverlight. I need to change its style at runtime. The style of this Button needs to change multiple times during the life of the application. Is this possible in Silverlight? If not, what is a good workaround?
Thank you!
Consider using the VisualStateManager to change the state of the button as appropriate.
You could create your own states for each of the different styles you wish to show.
Yes, it's possible, but I'd think hard about what exactly you're trying to do by changing the style itself because there's probably an easier way. You've probably already run into the fact that you can't simply assign a new style to the button with something like MyButton.Style = (Style)FindName("NewButtonStyle"). So you do need some kind of alternative.
The VisualStateManager is the first and easiest way of handling most kinds of changes that you would normally want to do to a control. You can pretty easily set changes to occur on the normal sorts of visible states (hover, focus, mousedown, mouseup) and it'll animate those state changes correctly from whatever state you're in to whatever other state you need.
If the kind of change you're looking for is more extensive, changing the type of control to, say, a ContentControl and then catching the mousedown/mouseup events from there might be a better workaround. This is obviously a bigger deal (and you lose the simplicity of having a button), but you'd be able to get whatever changes you wanted to pretty easily by just swapping out the Content property.
Somewhere between the two (and something I'll mention because it's possible, not because I recommend it) would be to actually manipulate the Style definition itself. The Button will pick up the changes and adjust itself. I'm going to repeat myself here though: I don't recommend this and I can't envision a scenario where I'd prefer doing this over using the VSM or using something other than a Button entirely. But it is possible to get into Application.Current.Resources["Style"] as Style and muck about with whatever you please. The bigger question then is why and whether what you're doing can be done some other way that would make more sense for whoever's going to maintain your code later. Personally, I expect Styles to be pretty static and I think that's the general consensus too.
Sure you can....
if you have a style stored locally you can access it like that :
rec1.Style = (Style)this.Resources["style1"];
I'm looking for a SL4 equivalent to .NET 4's SetCurrentValue API, which would appear to be exactly what I need for my scenario.
In short, I'm writing an attached behavior that updates the value of a given property at appropriate times. However, I don't want it to overwrite any bindings that are set on that dependency property. I merely want to push that value to the property (and therefore have any bindings refresh based on that value).
From what I can tell, there's no easy way to do this yet in SL4.
Thanks
Silverlight does not provide direct access to this level of dependency value. However its this level of value that Animations in storyboards set when they manipulate a property.
Hence a Storyboard with a 0 length duration containing a single DiscreteObjectKeyFrame might achieve your desired result.
I've managed to simulate what I'm after by detecting bindings and injecting a surrogate object between the source and target. I can then manipulate the surrogate and have both sides of the original binding refresh.
It's ugly and more work than I'd like, but it seems to work.
Kent
Using WPF I'm drawing symbols in the "fast way" (Drawing rendered on DrawingVisuals, no Shapes). So... I can successfully draw them and get hit-tested with no problem.
But when trying to remove them, using RemoveVisualChild() plus RemoveLogicalChild(), there is no effect on the screen: No visual removing.
I'm implementing my own displaying canvas-alike object (overriding VisualChildrenCount, GetVisualChild, MeasureOverride and ArrangeOverride).
For a while I believed it was a problem of refresh, but after invoking many methods (InvalidateMeasure, InvalidateArrange, InvalidateViual and UpdateLayout, plus a Dispatcher calling technique for post background-threading execution) well... the supposedly erased objects are still there.
A curious thing is that new objects going to be drawn OVER these erased ones, are in fact rendered UNDER them!!
Any Ideas?
SOLVED: It was my mistake (what a shame!)... A recursive symbol update, started at property setter level, was repainting the object.