-
Notifications
You must be signed in to change notification settings - Fork 317
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Auto resizing floating window on startup #146
Conversation
@@ -248,7 +250,9 @@ protected virtual IntPtr FilterMessage(IntPtr hwnd, int msg, IntPtr wParam, IntP | |||
handled = true; | |||
} | |||
} | |||
break; | |||
UpdateWindowsSizeBasedOnMinSize(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the first location where the style was loaded and the grid and border size could be retreived
I have reviewed your changes so far. Here are my thoughts on this:
Would it not be more useful to have the Auto-Resizing of the title bar in the LayoutFloatingWindowControl and the rest of it (configurable at construction time) in a deriving class (LayoutAnchorableFloatingWindowControl)?
Maybe this could be done in the style of the LayoutAnchorableFloatingWindowControl by adding a property like 'IsAutoResingContent'? |
I've reverted the copyright notice. I've added comments, note that the extension methods are internal. My guess is that many projects already have these methods implemented so I didn't want to expose them since it is likely to cause compile time errors if they happen to have the same name. 3 and 4. My assumption was that when these properties are set the control is unusable if the size is smaller and that it's better to resize any floating window that needs the space. But on the other hand, a control that needs a certain size probably shouldn't be in a I'm happy to move the size change to Regarding the title bar, it seem to me that it already adjust its size to the content and that no changes are needed? I have a couple of ideas of how the current implementation might fail so I will test more during the day. I have the feeling that more of this could be done with styles but that I lack the experience to see how, let me know if you see a less convoluted way of solving this than what I've done. |
I am actually surprised that your changes work without changing styles(?) There are styles for both floating control types (Anchorable, Document): I usally debug XAML styles like these by setting some number or property that makes it easy to recognize the change (eg.: set This is basically how I highlighted some controls visually in the Wiki section (eg.: LayoutAnchorableControl). I could do something similar for the LayoutAnchorableFloatingWindow (depicting its parts with different colors) if this would be helpful for you. |
That's a really neat trick for debugging. I've used the Live Visual Tree and the WPF Visualizer together with the styles you linked to find what to search for with the LINQ queries. It would really help if you did the same thing for the LayoutAnchorableFloatingWindow . I started with the queries of the visual tree at runtime when I tried to do the same thing from the calling code without having to redefine the complete style. I'll make some changes to put the setting of the LayoutAnchorableFloatingWindow in the style instead. |
I've added a Visual Parts section to better visualize the parts defined in the Generics.xaml file. Looking at the style I've realized that you might be interested in the items highlighted below:
|
I've now added a property for enabling and disabling the resizing and exposed the content size and total margins as dependency properties so that they can be used in styles in the future. As a default the behavior will not change with these changes. Let me know if I should make any other changes. |
This looks good from a technical point of view - the switch is
TextBlock We can set
|
On the other hand I can just merge this and add the demo customization as described above - thanks a lot for your patience and this cool contribution :-) |
Thanks for merging, and thank you for pushing me a bit. I should have tried the things you mentioned earlier in the week. I will make a new pull requests with some updates. I've just noticed that the resources of the docking manager doesn't propagate to the floating windows. Will continue a bit tonight and then I'll revisit this next week (Sweden is not working Friday or Monday), templates, resources and styles have been my weakest .NET skills so this is a good way to learn how WPF works. |
Auto resizing floating window feature from PR #146
Hi enove, I think its OK now, I've added the missing bits in the TestApp in the last commit. I should have known how to do this but my WPF skills have gotten a little bit slow as I was forced to take a bit of a break for the last 6 months due to private issues - but feel free to add on this if you like. Friday and Monday is also off in Germany so I guess you have a happy Easter in Sweden :-) Cheers Drk |
This pull request implements the auto resize in #140. It solves the problem I'm having for the existing styles, but might not help if someone creates a completely different style. But I don't see that as a problem, since that's a regular occurrence when styles are changed,
I also added an example in the TestApp which does the same thing we do in our
NavigationService
in our real application (our navigation service mimics MVVM Cross' navigation service but for dockable windows instead of full screen "windows").This is the look when calling
![image](https://user-images.githubusercontent.com/9482927/78119262-72a1fb00-7408-11ea-93df-637444058f46.png)
![image](https://user-images.githubusercontent.com/9482927/78119282-7a619f80-7408-11ea-8acd-9f2ac6b39cc7.png)
OnNewFloatingWindow
before the changeand this is after the change: