|
If the way you're doing it works without side-effects, that's the right way to do it. 
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
I have a... an unusual control (its a container for visuals), to which I just added a TextBox (user can click somewhere and add some text).
This control also listen to Key down event and on 1,2,3,4 it does something.
Now the problem is, it also happens when the user is typing in the TextBox, which is less than ideal, to say the least.
I can see that the KeyEventArgs.OriginalSource is different from KeyEventArgs.Source (my container), could I use that reliably perhaps? Any other tips?
|
|
|
|
|
In your TextBox.TextChanged event handler, before exiting the handler method, set e.Handled to true, and see if that works.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Interesting...
I gave it a go, and unfortunately the KeyDown happens before the TextInput event...
I tried to override OnKeyDown in the TextBox, and even though I called base.OnKeyDown first, setting Handled = true prevented text input entirely... 
No matter, my test of only handling key input in global container if it was the original source worked!
Thanks for interesting suggestion though!
|
|
|
|
|
My next suggestion was to look at one of the preview events, and to make sure the source of the input was correct.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
BTW the inline text editor is progressing nicely.. now I "just" need to add the text to the map...
Text-Input — ImgBB
|
|
|
|
|
I have a FrameworkElement (subclass) in my app which is a host for custom Visuals (my app is a sort of drawing program).
Now I just put the first UIElement in the visual container. A UserControl which host a bunch of Controls, including a TextBox.
Now when the Text change and the text box resize and go outside the containing UserControl, it is clipped and does not show anymore.
I tried to set Clip to false on the UserControl, didn't help (in fact it was already false).
Now in my UIElement I can be aware of the need to resize, thanks to
protected virtual void OnChildDesiredSizeChanged(UIElement child);
But I need to know that in my visual container.
At the moment it looks like it should only really be able to host & resize UIElement which implement some sort of INotifyResize interface, which I could inform thanks to this OnChildDesiredSizeChanged() method.
I wonder if there is already a way I can know that, with just any UIElement, not just the one made specifically to be hosted by that container.
EDIT / REMARK
5 minutes later... I think I might had answered my own question!   
I could just override OnChildDesiredSizeChanged() in the visual container....
I think there might be some issues, because some ContainerVisual are involved in the Visual hierarchy... let's see...
EDIT2
So I tried that and it is really strange
protected override void OnChildDesiredSizeChanged(UIElement child)
{
base.OnChildDesiredSizeChanged(child);
child.Measure(new Size(double.PositiveInfinity, double.PositiveInfinity));
child.Arrange(new Rect(BoundedVisual.GetLocation(child), child.DesiredSize));
}
This method is called only once and the child didn't resize...
EDIT3
Ha, I see, this didn't work, it this was another child (the one which display the scollbar). got nothing for the text...
EDIT / FOUND a solution
I am using this UIElement event to do my reArrange(), it seems to be working
public event EventHandler LayoutUpdated;
modified 18-Dec-21 7:49am.
|
|
|
|
|
I am having a RichTextBox in a Canvas, or perhaps it should be an Adorner.
The thing is, this RichTextBox has no witdh (min,max, current, whatever) set nor has any hint about which width to use, like so:
<Canvas>
<RichTextBox Canvas.Top="50" Canvas.Left="80">
</Canvas>
I was hoping it would auto resize when text is edited. But the thing is, the width is set to and doesn't update. And It ends-up wordwrapping on every letter like so!
W
o
r
d
Hence I am currently investigating.. how to make a WPF RichTextBox auto size! And would appreciate any help!
EDIT7
I am aware this goes against the design and implementation of RichTextBox, and also some people seem obsessed with my use of Canvas in the example above.
At any rate I gave up for now, but I asked here in just in case there is a work around solution somewhere on the internet that any one knows about?
Meanwhile, to temper the obsessive questioning about why I used a Canvas (not really but it's a good approximation) or why I "need resizable text" here is my use case.
Forget about LOB applications. Imagine there is a (zoomable, scrollable, pannable, rotatable) drawing area.
Now when the user click somewhere multiple things could happen (like, say, drawing a bezier curve), one of them is adding some text centered around said point. Which start by typing said text centered at point inline, ie. wysiwig editing. With the box around the text, previewing textblock handles, for later manipulation, such as rotation or translation (as in displacement)
modified 15-Dec-21 7:43am.
|
|
|
|
|
Looks fairly simple to have the height automatically increase to accommodate the text:
c# - WPF:Auto-Expand RichTextBox - Stack Overflow[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
yes, yes, what about the width though? This is the width that I was looking for, as I tried to explain..
|
|
|
|
|
A Canvas works well when you need absolute positioning (e.g. game pieces). In other cases, it's the opposite of "fluent design". A Grid is better at relative positioning and using available space, dynamically.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
- Canvas is absolutely the right choice here (long story, I made a screenshot to explain, just for you! )
- Even in a Grid, the problem remains, the Width of the RichTextBox is NOT determined by its content
modified 13-Dec-21 18:02pm.
|
|
|
|
|
- The position of the edit box is not dependent on the canvas since you can have "layers".
- Content does NOT "stretch" the edit box (that's why it has scroll bars); the "available space" does; depending on the alignment settings.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
Gerry Schmitz wrote: The position of the edit box is not dependent on the canvas since you can have "layers".
No idea what you mean. Nor, obviously, did you guess correctly how this drawing surface work (I thought it would be obvious, I am obviously wrong  )
Anyway, could we please stop wasting time?
How about wondering how to auto-width that instead?
<Grid>
<RichTextBlock HorizontalAlignment="Center" Width="0"/>
</Grid>
Gerry Schmitz wrote: Content does NOT "stretch" the edit box (that's why it has scroll bars); the "available space" does; depending on the alignment settings.
Indeed, that's why I gave up on the RTB and decided to use a TextBox instead, glad we agree.
modified 13-Dec-21 21:04pm.
|
|
|
|
|
Re: "wasting your time".
You show no code; there is nothing "obvious". Re: "Layers":
<Grid>
<Canvas />
<EditBox />
</Grid>
HorizontalAlignment="Center" only makes sense when you have an absolute Width; in all other cases it compresses the control. You should be using "Stretch".
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
It should be obvious after I repeated it emphatically at least 6 times...
Why do I have even have to argue about that?
I guess there is nothing I can really say here, sigh... 
I am not even using a Panel anyway... Those don't support adding DrawingVisuals...
Canvas is just the most well known approximation of my scenario.
modified 15-Dec-21 5:43am.
|
|
|
|
|
Fitting the width of a RTB does not make sense from a control POV - the RTB is designed to wrap text not extend itself (otherwise you would end up with 1 line of text disappearing off to the right of the screen ).
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
I gathered... It's why I gave up on the RTB, since in my case, rich text is not a priority, but auto-width is...
Thankfully normal TextBox does work
|
|
|
|
|
You can do this by handling each keypress, measuring the length of the displayed string, and changing the size of the RTB as needed. I would probably also turn off the scroll bars.
using System.Drawing;
private void RtbField_TextChanged(object sender, TextChangedEventArgs e)
{
RichTextBox rtb = sender as RichTextBox;
double horzPadding = rtb.Padding.Left + rtb.Padding.Right;
double vertPadding = rtb.Padding.Top + rtb.Padding.Bottom;
System.Drawing.FontStyle style = System.Drawing.FontStyle.Regular;
if (!Enum.TryParse(rtb.FontStyle.ToString(), out style))
{
style = System.Drawing.FontStyle.Regular;
}
System.Drawing.Font measureFont = new Font(rtb.FontFamily.ToString(), (float)rtb.FontSize, style, GraphicsUnit.Pixel);
TextRange textRange = new TextRange(rtb.Document.ContentStart, rtb.Document.ContentEnd);
Bitmap image = new Bitmap(1, 1);
Graphics graphics = Graphics.FromImage(image);
rtb.Width = graphics.MeasureString(textRange.Text.Replace("\r\n",""), measureFont).Width + horzPadding+10;
rtb.Height = graphics.MeasureString(textRange.Text.Replace("\r\n",""), measureFont).Height + vertPadding;
}
<Canvas Grid.Row="1" HorizontalAlignment="Center" VerticalAlignment="Center">
<RichTextBox x:Name="rtbField" Height="30" Width="0"
Padding="0,2"
VerticalContentAlignment="Center"
ScrollViewer.HorizontalScrollBarVisibility="Disabled"
ScrollViewer.VerticalScrollBarVisibility="Disabled"
TextChanged="RtbField_TextChanged"/>
</Canvas>
I gotta ask, though - aren't you concerned with too much text being entered to keep your layout reasonable?
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
modified 14-Dec-21 6:43am.
|
|
|
|
|
Interesting mix of WPF and Windows Forms! And on point answer!
I studied your code a bit but then I realized one possible problem. It might not work if there are multiple Font in used on the longest line, like Courier 64 and Courier 12. Which is the point of a RichTextBox after all.
Which bring me back to just working with plain old TextBox. I can give them a custom Font too, and bold and italic and etc..., just a single font (or other properties) for the whole text.
The RichTextBox is not really hiding the possible width of the rich text (which would be "easy" to circumvent), it's not calculating it, and there doesn't seem to be any easy way to measure a FlowDocument that I could find...
Unless, could there be an easy way to convert FlowDocument to FormattedText? Mmm... perhaps I should google that...
As to the "too much text" issue, it's not my problem, it's the user problem. Worst case scenario they can use a few line return.
The view has builtin zoom and scroll, so that help too.
Additionally I'd like to keep the text centered on the target square as the text is entered / updated (though it could be dragged with the appropriate tool later)
I need to move on with (for now) plain text. And on a much later day I might spend some.. weeks making a custom text editor.. haha
modified 14-Dec-21 7:44am.
|
|
|
|
|
Why would you allow font changes in a box that grows as you type? That's just asking for trouble. Besides, you said you'd be willing to use a regular TextBox if need be. That implied to me that you weren't concerned with font changes.
You can't specify a requirement, and then move the goal posts after I've kicked a field goal.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
well... I just did...
What I would like in order of priority:
1. I need text
2. I need to know the size of the text live as it updates
4. (preferable)no page size (i.e. no max line length)
3. (bonus, optional) rich text would be nice
so I started with RichTextBox, thought it would be great. But then, pfff.. too much bother, could I at least get some text going, I realy would like to have some marker on my dungeon map ASAP.. the RichText could always come later, if ever....
|
|
|
|
|
I'm still having trouble with the growing nature of the textbox. I honestly can't come up with a use case for that, especially since a text box can horizontally scroll (without scrollbars), but hey, it's your app...
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Obviously, and I understand that it can have been confusing of me to forget that, scrolling will be disabled / scrollbar will be removed.
But Anyway TextBox does (almost) all I need (yes, including the resize, see, it's not so hard)
|
|
|
|
|
Forget about LOB applications. Imagine there is a (zoomable, scrollable, pannable, rotatable) drawing area.
Now when the user click somewhere multiple things could happen (like, say, drawing a bezier curve), one of them is adding some text centered around said point. Which start by typing said text centered at point inline, ie. wysiwig editing. With the box around the text, previewing textblock handles, for later manipulation, such as rotation or translation (as in displacement)
modified 15-Dec-21 6:35am.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
