We need to use the built-in WinForms tooltip control to display a very long tooltip (about 4000 characters) for one of our controls. But if we do so, the form freezes for a minute or two when we place the mouse pointer into the target control to see the tip. And nothing happens after that.
We experimented and detected that the standard tooltip starts to work very slow when it has about 2000 chars, and the situation becomes much worse when we increase the number of chars. Is it a known issue, and is there any workaround for it? Please, don't suggest to trim the tip text - we need to display the string as is.
When you assign a string of text to a ToolTip, part of the process of drawing it involves calls to USP10.dll which handles Unicode layout of characters on screen. I was able to see this by looking at the stack trace while the program was freezing. The performance of this layout is terrible for long strings.
Disabling Visual Styles for the application (commenting out EnableVisualStyles()) fixed the problem - the tooltip displays immediately, though this is not an optimal solution.
I kept looking and found this page which indicates the problem may be linked to layout of long strings where word-wrap is necessary. By inserting line breaks into the tooltip text, I found that the string displayed immediately. So, if you can determine where to insert the line breaks manually, the ToolTip should display quickly.
What about using another Tooltip , i.e. HtmlToolip?
Related
This question is related to this other one (Android). A sample test case was also provided here
Basically, I can get past the "glitch" of losing the bottom screen under the keyboard that occurs sometimes when a single line TextField is focused by setting the TextField's bottom padding and making it a layer
But when the same glitch occurs to a multi-line TextField, each time the cursor is moved to a different line the keyboard follows the current line and hides everything underneath. I've been looking at TextArea and Component but I can't see anything there that stops this behavior. My "trick" of making the TextField a layer with bottom padding doesn't work in multi-line mode. I'm out of options, could this be enabled or alternatively is there some magic method somewhere I am missing?
Also, I've checked that calling getComponentForm().getInvisibleAreaUnderVKB() returns 0 when the glitch occurs
I think you need to re-open the applicable issue. This code is very platform specific as the virtual keyboard behavior is handled 100% within the Android port.
Android doesn't implement getInvisibleAreaUnderVKB() since the VKB doesn't work that way in Android. It resizes the screen instead to provide the additional space. It will generally try to get the top area where your cursor is. That's the chief goal.
When the screen is empty that might look problematic but when your screen is full of data we'd rather see the data than have the full text component in view. Unfortunately, the native editing code has no way to distinguish between the two cases. We might be able to come up with a workaround but with these things there are often issues/regressions.
Solution to prevent this consists in setting the Form's setFormBottomPaddingEditingMode(true);. Easy fix! 👍
During the development of my program I came across one drawing glitch that I was unable to solve. I am using GtkRevealer to show and hide a GtkInfoBar above another box holding a scrolled window with a GtkTextView (actually GtkSourceView) a lot like it is in gedit.
The whole thing is packed in a GtkPaned.
When I hide the infobar through the revealer, a black area in the text view appears and it disappears when a redrawing of the widget must occur (for instance when I click on the text view to place the cursor)
Additionally, this glitch does not appear if I enlarge the default resolution of the window, which for compatibility reasons is 640x480.
I understand that this may be hard to reproduce, but I am unaware who encountered the same problem. He maybe knows a workaround to this issue.
Also any idea is welcome.
I will draw exactly how the glitch looks on gedit (although it doesn't happen in gedit or it does but I cannot hit the correct resolution).
I tried to force a redrawing with gtk_widget_queue_draw() but nothing happens and it won't, because it has nothing to redraw.
I will try now to place the cursor automatically. It may work, but it is not functionally adequate.
EDIT:
Surprisingly it did not work. Grabbing the focus and placing the cursor
had no effect on the glitched visual behavior. I had to even make a new line
to fix it this time.
The fact that I have to resize the window with a value more than a specific point, may mean that the glitch may be due to alignment miscaulculations, but this doesn't explain why adding new line or a text mark in the gutter that colorizes the entire line also removes the black field.
Currently this bug has been encountered in another programs with a text view as well, but hasn't been reported as a bug yet.
Perhaps this has something to do with the fact that it is hard to reproduce.
I found that hiding the gtk text view with gtk_widget_hide() and then showing it with gtk_widget_show() works. The flicker of this visual glitch is not noticeable, perhaps due to GTK+ being event-based and waiting for the function to return to process changes.
I'd like to change the font size of a chunk of RTF without erasing the bold / italic / underline formatting (an issue similar to the one in this question). The accepted answer is to modify the selection of the text box until the SelectionFont propery is null in order to find runs of consistently formatted text which can be modified individually. Sounds reasonable. However the actual behavior of the RichTextBox control seems to be inconsistent with the documentation.
In the documentation for RichTextBox.SelectionFont MSDN states:
If the current text selection has more than one font specified, this
property is null.
However, this code which uses mixed bold / regular text doesn't behave as you'd expect:
var rtb = new RichTextBox {
Rtf = #"{\rtf1 This is \b bold\b0.}"
};
rtb.SelectAll();
// Now you'd expect rtb.SelectionFont to be null,
// but it actually returns a Font object
Is there any other reliable way of formatting the text so that I can change the font size without clobbering the other formatting. (Manipulating the RTF directly is OK, I'm not absolutely set on using WinForms to achieve this).
I've given up on trying to go through Winforms to fix this. As I'm applying the change to a whole document (rather than just one portion), it turns out that it's not too hard to modify the RTF directly.
In this case I'm interested in the font size, which is represented by the \fs command. So to replace all the 8.5pt text with 10pt text, you can replace \fs17 with \fs20. (Yes, RTF font sizes come in units of half a point, apparently).
This seems to work well enough, although it does feel like one of those "let's mangle our HTML using regular expressions" type solutions, so I'm not convinced that it's very robust.
Take a look at this:
Changing font for richtextbox without losing formatting
I think it's the same issue. LarsTech's solution is working perfectly for me.
I have textBlock defined such that it fills the entire screen of the phone.
The textBlock is initialized with some data which cannot be displayed in the boundary and hence gets clipped.
I want to read the data which actually got rendered on the screen (i.e. whole data - clipped data).
Putting a breakpoint shows me that myNewTextBlock.Text contains the entire data that it was initialized with.
Thanks
You could look at using Measure and MeasureOverride to determine how much of the Text would fit in the available space.
You'll likely need to test various trimmed versions of the Text but it shouldn't be too tricky.
Ok I have the following problem in Silverlight. I have a control with 2 columns. On the left is a stack panel with line numbers and on the right is a textBox.
So when I write in textBox without wrapping turned on I can simply create the right count of numbers on the left, because I'm searching for '\r' in text.
But when I turn on wrapping I have no control over the count of lines in textBox.
Is there a way to get to that count? Or a way to know which line in textBox is going to wrap?
I hope you can understand what I'm trying to do.
There's one way to do this. You can simulate the word wrap operation in the background using a TextBlock. Here is a good link of the complete solution to this problem.
Extended TextBox control with MaxLines property
Is it not possible to create your items in code before they are passed to the view. This would enable you to bind a list of items to a listview and style them as you wish.
You need to user a value converter to count the number of char / lines and then trim that number if you wish to. Unless you use fixed width, you can't really count or calculte in advancet the size, since each application might be displayed differently (due to different sizing option).
There are two great sample chapters on Windows Phone and Silverlight for Windows Phone on the LearningWindosPhone.com site. There is great Windows Phone Trainng material , and dont forget the Windows Phone Develoeprs Blog
Yes there is a way to get the number of lines occupied by the text in the textbox. It's not that simple though 'coz you have to simulate the behavior of the word wrap in order to count/predict the number of lines generated as a result of a word wrap. I have the solution described here in detail.