Is there a way to move a popup to back, so it does not always display on the front of the application?
I have a canvas that displays many shapes, which are resizable. To get the resize box I am using a popup, because it was suggested that the best way would be to use adorners, but these are not used in UWP, so the alternative are popups. It works quite well, but when I have another element overlaying my canvas and resizing was enabled on a shape, the popup elements (resize thumbs/nodes) are displayed on top of the element that should be overlaying the canvas. Is there a way to tell the popup that it should not display on a "higher level" than my canvas?
A Popup control is intended to be displayed on top of all other content so it seems you're not using an appropriate control for what you are trying to achieve.
Without seeing more of your code and having a clearer idea of what you're doing (repro?) it's hard to suggest what you should do. However, I'd avoid resizing control that aren't on top of the viewable area or having multiple items in a resizable mode (or just with adorners displayed) at a time. Both of these should avoid what you're reporting.
Related
I want to create a UserControl that displays a dropdown selection control and a couple of buttons when collapsed, but could be expanded to display a larger selection of items when desired. It's expansion panel should slide down over the controls of the Window or UserControl it's embedded in.
I can do it if all of the XAML is in the same control, but I can't figure out how to do it if I want the small view and sliding bits in a separate, re-usable, UserControl.
For a small panel I am using an animation that changes the margin of an offscreen panel and bounds clipping to make it happen. I have been copying the XAML from Window to Window. I want to make a re-usable much larger version of this, but displaying it, properly, has me a bit lost because of the bounds clipping. The UserControl clips the panel within it's smaller view, rather than allowing the panel to display over it's parent.
This is the effect I am looking for:
The primary issue seems to be that the sliding panel has to be contained within the UserControl, or it gets cut off. So the user control has to be much larger than its collapsed view. Because of that, when you want to embed it in another Window (or UserControl) you have to do XAML gymnastics to accommodate for the size of the control while making appear that the control isn't really that big.
Maybe that's just typical for XAML. I am still learning. But I can't figure out how to have a visual element of a control appear outside its bounds. A Popup doesn't really work because of how it opens and closes with focus.
At this point it's just an exercise, as I've decided to implement it a different way (modal dialog) so I have the control I need over the visuals.
Imagine a bar graph with horizontal bars that may be very wide. I have a Panel on a Form where I want to display these bars and scroll and zoom them. The Form, and thus the Panel, can be resized. The bars are dynamically created from a database. Each time the user zooms in or out, all bars have to be created anew to adjust their sizes on the Panel.
I use Label controls to create these bars, but the problem applies to all other controls as well: If I zoom in far enough, my bars will eventually exceed the magic 16 bit border of control sizes (>65536 pixels). This makes it impossible to simply create all the controls on the panel at start and let the panel handle the scrolling.
My idea: Clear the Panel of all bar controls and create only the ones that are visible in the current view window, according to the current position of the scroll bars and the zoom level. The bars exceeding far from the visible view will be cut short just outside the Panel, so their maximum size is limited by the Panel size.
My questions:
At which Panel event(s) should this clear/create process take place best?
There could be thousands of controls, so it should be as seldom as possible.
Is there a better way to handle this? Maybe I got it all wrong from the start.
This problem arises not only with huge controls but also when smaller controls are very far apart (>65536 pixels) on a Panel, so I think a good solution may be helpful for many projects.
I wouldn't like to have to create / destroy controls, or hide / resize controls just for their click events. It's quite easy to create a UserControl and override the OnPaint method to draw the bars, and override the OnClick or OnMouseXxx events.
Since you already know the positions of the bars in "virtual space", it's easy to map the location of the mouse cursor to a bar (or a click outside a bar).
I know you said winforms is Mandatory, but I really think you should look into the wpf viewbox. You can host a wpf element in winforms. So everything else can be forms related, and you have a panel that hosts and displays your controls. I could write up a quick example that might demonstrate this for you, but if you have no intent of going this way I really don't want to waste my time.
You could create a metafile (vector graphics), show that in an image control, and manually determine which logical element is clicked.
I was wondering what is the best way to print entire content of scrollable control. I was trying to print a control in several ways, however all the time I was only able to draw visible content of control. So far I tried to use
PrintForm // there is nothing I can do with this because it requires a form not a control
I was also trying to use controlName.DrawToBitmap() method however this function captures only the visible area of control.
What is the best way to draw this kind of controls ?? I would like to avoid scrolling control's content in order to capture all control's element.
I would suggest that you create an invisible to the end-user form (for examlpe, position it at (-10000, -10000) and this form should have the size enough to display the ScrollableControl without scrollbars. This way you will be able to workaround this problem.
I'm experiencing difficulty with a custom-made User Control, and my searching on Stack Overflow, MSDN, and Google didn't pop up any troubles quite like the one I'm experiencing.
I have a very simple User Control: It's a label, a text box, and a button, with a SaveFileDialog and a FolderSelectDialog available. The text box and button are anchored Left,Right and Right respectively, with the intent that if the control is resized larger, the text box will enlarge to fill the gap, and the button will stay on the right edge of the control.
The problem I am encountering is that when the control is enlarged, the area to the right of the default width of the control becomes blank space when the project is built and run. The pictures here will illustrate what I mean:
In editor:
Running:
The control is smallish in its design window, but when I add it to a form and widen it, it behaves as intended. However, when I run the form the control was added to, half the control isn't visible.
I suspect that I'm overlooking something fairly straightforward, but I wasn't able to find anything addressing this point in my search. Help would be much appreciated.
My guess is that there is a panel or something that is added to your control and will be brought to front somehow runtime.
from property window's top there's a combo from which you can select all the controls in your User Control.
check if all the controls are what you want.
if you find that panel or anything delete it :)
EDIT:
alright this was not your problem.
now I can only assume that you have set some manual sizes to your user control, i.e. in its constructor. in that case designer will show the correct size of you user control,
now some other place in your code, you have set the user controls size manually again. if the layout is suspended and size changes, I think that the anchored controls' size will not change automatically.
if this is your problem, it is probably hard to find.
I just wasted my entire evening on something which I thought would be very simple but it seems WPF and Google are letting me down completely.
I need a grid, 6x6 of which I fill every row and column with a custom control. I want to be able to navigate through this grid via the keyboard (I can get those events, no problem) but I cannot seem to find how I can always have the selected grid row/column in the center of my window.
I found some carousel alike implementations, but most of them only work in a single direction and I want two way navigation, yet none seem to support this nor can I extend them to do this.
I essentially want to create a PSP alike grid navigation.
One easy way is to do this:
Create a scrollable form.
Add a 6x6 grid of child controls.
In the GotFocus (or similar) event for all the controls, set the parent form scroll offset to an appropriate position to centre the child.
This is pretty straight-forward thing to implement, with a little bit of maths to work out how to centre the x,y position of a control by setting the scroll offsets (it can be tricky/confusing, but as long as you understand the coordinate systems used for scrolling, not too bad)
Or, another approach that avoids scrolling via the windows APIs and using custom controls:
Create a form
Override OnPaint to draw your grid of 6x6 "controls" as simple graphical shapes or bitmap images centred on the selected "control".
Handle keyboard (KeyDown/Up) and mouse handling (MouseDown/Up) events to make the 36 areas of the graphic respond to user inputs in the way you desire. You'll have to track the selected item and force the window to redraw its graphics to show the new state. Enable double buffering to stop it flickering.
The first approach gives you a lot of windows-based handling for free (tabbing between controls, remembering where the input focus is, and directing events to separate classes for each "control", for example). The second approach strips away all this "help" but gives you complete control over everything, which can often help avoid unintended behaviours (e.g. it won't move the input focus when the user presses Tab unless you specifically write the code to make it do that).