this question is only for those who use the MDI from Codeplex.
I successfully implemented the mdi container and can add or remove child elements dinamically through my code.
My problem is that some of my custom controls (like UserControl) contain a few other controls (ex: TextBox, Buttons, ComboBox, etc), and every control works normally, EXCEPT for the RichTextBox!!!
The issue is that every time I input text in runtime mode, after each char input it automatically goes to another line.
Before you say that may be the way my custom control is built, be assured... it's not. I passed the control containing the richtextbox to another window and it worked normally.
Anyone has the same problem?? Or solution?? I know the codeplex version is still not fully finished but I'm hoping I'm the one doing something wrong...
Thanks
Found the issue. My RichTextBox Width Property was set to AUTO and for some reason (that is completely oblivious to me), it was what was causing the problem.
The solution is to give it a physical (a number rather than AUTO) value to it's Width property.
In my case, since my control has a TextBox just above the RichTextBox and they're supossed to be the same width, I've set my RichTextBox.Width = TextBox.ActualWidth. Note that I used ActualWidth and not width since the width property in my TextBox is also Auto, but the value returned by ActualWidth is a number.
Hope it helps someone :-)
Related
I'm developing a WPF project where I need to validate textboxes on code-behind and then change the border color of those textboxes to some unknown color defined by the user configuration; the problem is that to overwrite the MouseOver effect I would need to set the value from XAML directly via ControlTemplate or Style.
Is there a way to get the current value assigned to the TextBox from XAML? Maybe binding it to itself?
I will appreciate any help you can give.
When validating a TextBox, or any control for that matter, it's common to use an adorner to display the validation error (in your case, setting the border color). You can have a look at an example here.
Using this method, you don't actually change the TextBox's border, but create a new visual layer on top of the TextBox that draws the new border around it. This is pretty much the way validations should be done in WPF, and it also solves your problem of having to deal with changing the TextBox's border value back and forth.
I've written a WPF control which accepts a number of UIElement objects as input and displays them docked either vertically or horizontally. The control exposes functions for enumerating, removing and inserting children, but internally I'm using a Grid to build the layout, creating a row/column for each item and inserting a GridSplitter between them. To do this I've inherited from ContentControl, and upon initialization I just set the Content property with the Grid. Everything is working as intended, but now I wonder if this might be confusing for the user of my control, as it would be counter-intuitive to have a ContentControl that has many items.
Should I be inheriting from ItemsControl instead?
Should I inherit directly from Control which is "content-agnostic"?
Is there a better way to do this?
Thanks in advance.
What you describe sounds like a Panel - basically a control which is responsible for the layout of many elements. I would consider inheriting from that.
Your mention of "docked either vertically or horizontally" leads me to believe perhaps a StackPanel would be a better fit, since it does docking as well.
I've this situation:
A label placed in Footer Cell of a RadGridView doesn't have sufficient width available in its container for displaying its full text.
Is it possible by any ways to have the label cross its container boundaries and show full text?
Thanks!
The space given to any element depends on the parent control or Panel that contains it, as well as its Width, Height, Horizontal and VerticalAlignment, and Margin. Normally you can manipulate some combination of these directly to change overlapping behavior but by using a DataGrid control you've given up a lot of that control since things like ColumnSpan are set up by the control internally. You could try setting negative Margin values and changing the Panel.ZIndex but I doubt those will help.
The best solution I can recommend without more detail is to use TextWrapping or TextTrimming to avoid ugly clipping, maybe in combination with a ToolTip showing the full text.
You can overlay any WPF element by another anytime. Only place where it fails is the WebBrowser control .The WPF WebBrowser has not been improved a single bit from WinForms WebBrowser. It is still the same simple activex control. However, you can bypass even that with a tooltip control.
I believe you can either set ClipToBounds=False to allow it to expand outside its area, or set TextWrapping=Wrap to allow the text to wrap.
EDIT: Forgot ClipToBounds is only honored in the Canvas control, so wrap your label in a Canvas and set ClipToBounds=False and it should work.
I have a ListBox that contains a number of User items that are DataTemplated to appear as UserControls in the ListBox. Each UserControl can be expanded in size. To start with, the ListBox is big enough to display them all in their unexpanded state. The problem that I have is that when a number of these UserControls are expanded together, they extend out of the ListBox's visible area. The ListBox does not recognise this fact and no ScrollBars appear, even when they are set to Visible.
I am using DoubleAnimations to alter the UserControl heights when the user clicks on a button in each one. Is there something that I have to do, or some setting on the ListBox that must be set to get it to register the size changes of the UserControls that represent its items and display ScrollBars when needed?
Edit>>>
I have tracked down the problem to a custom WrapPanel that I am using in the ListBox.ItemsPanel. When I remove it, or replace it with a standard WrapPanel, ScrollBars appear when required. I got the code for the Panel from a good article about creating custom WPF panels. Can anyone see what's missing from the code given in the article and why it might stop the ScrollBars from displaying?
I wonder whether ListBoxes normally do what you are expecting? You might try calling InvalidateMeasure/Layout on the ListBox if you know when the item sizes change, just to see?
I decided to write the custom WrapPanel code again completely and this time it worked correctly! When comparing the new version with the previous version, I could see that a + was missing from a += in a measuring calculation and so the Panel thought that the items were much smaller than they really were... hence no ScrollBars.
So, if you have this problem, check your measuring code carefully.
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.