Using the framework property I can detect the changes to the LockLeft, LockRight, LockTop, LockBottom, LockHorizontal, and LockVertical properties.
But when they change I’m not sure what CSS properties to change in order to get them to obey the changes. Perhaps @Greg O’Lone can give some insight into what the default controls do when these properties are changed. Although I know even with the default controls they don’t always listen to changes in the locking properly. (There’s a few bug tickets for this already)
The framework doesn’t support changing locks outside of the IDE.
Any particular reason why?
In trying to resolve this on my own I did realize that the order in which you change the locks on/off will change what happens. If I want go from lock left to lock right on my custom control, I need to change lock right true first and then lock left false. I’m thinking maybe a “ChangeLocking” event might be more helpful so the user doesn’t ever need to consider what order to change the locks in as the event will figure that out for them.
It’s not just the SDK. there are major issues with changing the locks on regular controls at runtime. The fact that you can do it is actually the bug.
Are you saying that the locks set in the ide are not obeyed in your SDK controls?
No, it does obey. There’s just been mutliple instances in the past where I’ve needed to change the locking. The webAnimator is a good example. After an animation I might want to change the locking for instance.
Do these issues have to do with what I mentioned? The order you change the locking and position in can completely change the resulting effect. I have the logic figured out to resolve this mostly but as I mentioned a ChangeLocking event might be more user-friendly.
Knowing what I know about the framework, I’d be surprised if changing the locks at runtime work at all consistently.
[quote=132733:@Brock Nash]Do these issues have to do with what I mentioned? The order you change the locking and position in can completely change the resulting effect. I have the logic figured out to resolve this mostly but as I mentioned a ChangeLocking event might be more user-friendly.[/quote] it has not been reviewed in depth.