I'm writing custom tree control from scratch and I've yet implemented most of default behaviors of Windows control. My last change involved adding so called autoscroll feature: if you start making a rectangular selection and drag mouse below or above control, it starts to scroll automatically, such that you can select more elements than are currently visible.
I would like my control to behave as similar to other Windows controls as possible, so my question is: is the automatic scroll interval and scroll step (eg. pixels to be scrolled) defined somewhere in the WinAPI? Are there different scrolling speeds for different distances from the control bounds and if so, are they defined somewhere as well?
Related
WPF doesn't appear to convey visibility information during rendering so it does no culling and, consequently, performance can be awful. So I'm interested in the idea of circumventing WPF's normal rendering pipeline in order to replace it with a more efficient one.
For example, given a scroll viewer containing a grid of controls I'd like to precalculate the locations of the controls in the grid in order to render only potentially visible controls given the visible region within the scroll viewer. So I'd replace the scroll viewer's renderer with one that passes that visibility information and then replace the grid's renderer with one that uses that visibility information to cull controls that lie completely outside the visible region.
Is this possible and, if so, how might it be accomplished?
I recently used a TranslateTransform in my WPF application to implement dragging a UserControl across the screen. There is a new bug in that after the first time you drag it somewhere else on the screen, when you click on the "Title bar" on the control, it jumps back to where it was originally displayed. It will still follow the mouse, but that initial jump is disconcerting.
I don't know what's going on, but this got me to wondering. Since WPF controls don't have a left or top property of their own, unless you put them into a Canvas, and those are attached properties anyway, just what properties are being modified by the TranslateTransform?
WPF's layout and render passes have intrinsic knowledge of transforms. By modifying the X and Y properties of the TranslateTransform, you're causing the layout/render pass to take those new values into consideration when positioning the associated FrameworkElement.
To put it another way: the TranslateTransform is not modifying other properties, but by modifying its properties you are triggering another layout/render pass and thus affecting the on-screen positioning of the associated FrameworkElement.
Read here for more information.
I'm using a pop-up window in my WPF application. It's a borderless window with SizeToContent set to WidthAndHeight.
It resizes itself every time I show it to the user in order to accomodate for various lengths of caption on the button and the number of buttons which can vary etc.
Unfortunately, this auto-resizing is noticeable - especially when the window shrinks; it looks "jumpy" and thus sort of amateurish.
I'm never disposing of this window - just hiding and showing again - because I'd have to reattach some event handlers every time, and also repopulate a listbox (with language codes), which I'm not sure I should do.
Is there any way I could tell it to calculate the right size before it is displayed?
It must be WPF perf optimization. Calling InvalidateMeasure() beforehands might help.
I have an ItemsControl with a number of elements, each one with its own ViewModel instance. Each item's ViewModel knows whether that item should be visible (currently each ViewModel has a Visibility property that the UI binds to). When my window first opens, some of these items are visible, others are collapsed. Later, some items' visibility might change in response to user interaction. The window sizes to its content, so the window resizes when items are shown or hidden. And the window is initially centered on the screen (which means everything has to be arranged properly right away, so the window knows its initial size and can center itself accordingly).
Now I want to add animations whenever an item is shown or hidden -- but I only want to animate if the item's visibility changes after the window is already shown. So if the window is already open, and the user does something that makes one of the ViewModels want to appear, it animates in; if the user does something to make one of the ViewModels disappear, it animates out. But when the window first opens, I want everything to start out rock-solid -- no lingering animations.
And I want the window to still set its initial size based on its initially-visible content, and I still want it to be initially centered onscreen. (Although actually, in this case, it would be acceptable if it centered itself as if all items were visible, if event ordering made it work out that way.)
I know a fair bit about WPF, but I admit I'm lost when it comes to triggers and storyboards. I haven't really done anything with WPF animations before, and I'm not sure where to begin.
I already tried using Reveal from the Bag of Tricks, but I had several problems with it, the biggest being that it doesn't have the "only use animations after the window is shown" behavior that I want -- my window would appear and the initially-visible elements would still be animating in. It also didn't play well with my layout (it was centering the elements horizontally, instead of stretching them to the ItemsControl's width), and a few other problems that might or might not be fixable.
I'm not too picky about whether I animate by stretching (e.g. by animating a LayoutTransform from SizeX=1 SizeY=0 to SizeX=1 SizeY=1, thus starting with squished text and expanding to normal size) or by just changing the Height (thus starting with only part of the content visible and revealing more as the animation progresses) -- I'm fine with either.
I'm open to writing my own Panel descendant (I've done it before) if that's the best way to solve this, and I can always steal code from Reveal and hack until I get it working -- but it seems like there should already be an easier way to do this, if I just knew what it was. I'm open to learning about triggers and storyboards, or whatever, if someone can point me in the right direction.
The problem is fairly simple, but is best illustrated visually. Note that all screen shots are from the Visual Studio 2005 design surface. I've noticed no difference when I actually run the application.
Here is my user control (let's call this UC-1):
The buttons on the control are set to anchor to Bottom + Right.
Here is what it looks like when placed onto a particular parent user control (UC-A):
Please disregard the difference in colors and such. Some styling is done in the user control's constructor.
Notice the bottom of the control is getting clipped. The instance of the consumed control on the parent is set with a "FixedSingle" border. Notice also that the consumed control is taller than the original, indicating that the buttons bottom anchor settings are being respected, but are essentially overshooting where it should be.
To confirm this is definitely a problem on the parent control, notice another user control (UC-2) containing a data grid view when placed on the same parent:
Again, the instance of the consumed control is set with a "FixedSingle" border which helps illustrate the clipping. The datagrid is properly anchored to the Bottom Right. To reinforce the perplexity of this problem, here's the first user control (UC-1) when placed on a different parent user control (UC-B):
alt text http://i38.tinypic.com/2rnyjd0.png
Here's the second "consumed" control (UC-2) when consumed by a form:
Notice, no clipping this time.
I have spent many hours searching and experimenting to resolve this. I have exhausted the various settings of margins, padding, sizes (min/max), locations, anchors... etc. I can not for the life of me figure out why this one user control is causing child user controls to clip like this.
Another strange thing I noticed was that when I do an UNDO on the parent user control design surface (where the controls are misbehaving), the clipped user control instances actually shift location even though the undo action is unrelated to those controls. For example, if I make the main containing control larger, then undo, a couple of the child user controls jump up. They appear to move about as far as they are being clipped. Very suspicious.
Does anyone have any idea what is going on??
A very interesting problem!
Does your problem parent (UC-A) override any of the methods around sizing or client areas?
Or has UC-A got a negative value for the bottom value of Padding or Margin ?
Is there anything else docked at the bottom edge of UC-A? Perhaps, something that has a negative size?
Or, does UC-A set the constraints of its child controls? If the minimum height of the panel is forced too large, you would get this result.
Hope this is helpful! If not, is there any chance you post the source to UC-A ?
I was having the exact same problem and found your post while searching for a possible solution. Although I'm pretty sure that this is a bug in winforms, I found a bit of a workaround. Just put everything in your user control inside a panel, dock the panel to full, and do your anchoring inside the panel. This seems to alleviate the problem, although my button does tend up to show up at a slightly different size than it should in the parent control. Very weird. I compensated by making the button smaller in the designer, and it stretches wider by a few pixels in the parent control for some unknown reason. Hope this helps.
Assuming the parent control in question is not a standard .NET framework type, but a custom one, I'd guess that it is mixing up client and screen co-ordinates somewhere in it's logic. But that's just a guess.