I have a (multiline) text indicator in my program where I display everything that my program does. Every time after adding new string to the indicator, I move the vertical scroll bar to the end to make sure that the user will see the message instantaneously. It works fine.
However, when there is a lot of text in the indicator, the user is unable to move the scroll bar. Also, the scroll bar doesn't move to the bottom of the indicator after adding a new message.
How can I increase the capacity of my text indicator? Is it even possible or do I have to decrease the amount of text I display?
The rest of the program works well, the screen doesn't freeze. The only problem I have is that the vertical scroll bar doesn't work properly.
LabVIEW stores strings as a pointer to a structure containing a 4-byte length value followed by a 1D array of byte integers (8-bit characters). The 4-byte value is the same size as a U32, which has a 2^32 range (0 to 4,294,967,295). So, your string can have up to 4,294,967,295 characters.
About the second part of your question: http://digital.ni.com/public.nsf/allkb/E888D1D6A739A787862571F800586482
Put a gigantic amount of text in your indicator while the VI is in edit mode. Can you move the scrollbar then? If you can, then I suspect the problem is how you're adjusting the scrollbar at run time. Is it possible that you're continuously setting the scroll position to the bottom so your user tries to drag it and fails?
Related
Not sure if I'm wording the question right.
That's why I had a hard time finding the answer on google, like I usually do.
I have my vim set to never wrap lines. Keeps code cleaner.
But I don't like that if I'm moving the cursor across a line and get to the edge of the screen, the view jumps so that where I was at is now in the middle of the screen.
Is there a way to make it not do that? Like, so it just goes one character at a time
(or if I'm traveling by word, one word at a time, etc. Just so if I go the edge of the screen, the cursor stays at the edge of the screen, and the page moves inward under it)?
You could check out the 'sidescroll' setting:
'sidescroll' 'ss' number (default 0)
The minimal number of columns to scroll horizontally. Used only when
the 'wrap' option is off and the cursor is moved off of the screen.
When it is zero the cursor will be put in the middle of the screen.
When using a slow terminal set it to a large number or 0. When using
a fast terminal use a small number or 1. Not used for "zh" and "zl"
commands.
I have a CodenameOne application which has a TextArea that should display a multi-line text.
When I run the app in the simulator and click on the text-area, the spacing between the lines and possibly also between the characters change so that the area that the text occupies shrinks a bit.
Why is this?
What should I do to prevent it?
That is due to the switch from our drawing to the native editing which will always render things slightly differently. E.g. things like line spacing are really hard to get accurately for every native device.
TextArea has a setRowsGap method that allows you to specify the spacing between rows in pixels but since this differs between OS's its probably not ideal.
For those unaware, AFAIK by default in Emacs scrolling works the following way.
It doesn't scroll until the user has reached the end of the visible buffer, when you reach the end of the visible buffer and you go one over the visible buffer it doesn't load one line, instead it loads an entire new page, basically. I imagine this is to reduce lag when re-rendering the screen.
What would be a way to achieve this in Vim? Is there a way to do this? If there isn't, what are some pointers to implement something like this? My idea was to maybe get the best of both worlds and scroll half a page or one page when scrolloff is reached.
Any help is appreciated. :)
I think this would do what you want:
set sj=-50
check :h 'sj' for details:
'scrolljump' 'sj' number (default 1)
global
{not in Vi}
Minimal number of lines to scroll when the cursor gets off the
screen (e.g., with "j"). Not used for scroll commands (e.g., CTRL-E,
CTRL-D). Useful if your terminal scrolls very slowly.
When set to a negative number from -1 to -100 this is used as the
percentage of the window height. Thus -50 scrolls half the window
height.
NOTE: This option is set to 1 when 'compatible' is set.
It is possible to read the following in the apple Documentation:
UIKeyboardFrameBeginUserInfoKey
The key for an NSValue object containing a CGRect that identifies the start frame of the keyboard ……
UIKeyboardFrameEndUserInfoKey
The key for an NSValue object containing a CGRect that identifies the end frame of the keyboard ……
Would that mean that the keyboard has a "start frame" and an "end frame"?
I suppose YES.
But when the keyboard appears I cannot see any frame changing. It just stays the same frome start to end.
So my question is:
What are those "start frame" and "end frame" referring to?
I must be missing something.
Thanks for your help.
The keyboard does indeed have a start and end frame, and the properties do exactly what you suppose they do. They keyboard does not always animate however; sometimes it just appears or changes size. For example, in the case that you are typing on the Japanese keyboard, when the keyboardWillShow fires after the first character is hit. There's no animation, but an additional bar appears above the keyboard, thus changing the size. The properties you listed above tell you how much the keyboard changed size by.
I'm not sure what exactly you're looking at when you say no frames are changing. I suppose it's possible that when you move from one editable text field to another, you get a keyboardWillShow notification, even though nothing on the screen changes.
This is happening on Vista.
I created a new dialog based MFC project to test this. I added a CEdit control to my dialog. I called SetLimitText to let my CEdit receive 100000 characters. I tried both:
this->m_cedit1.SetLimitText(100000);
UpdateData(FALSE);
and
static_cast<CEdit*>(GetDlgItem(IDC_EDIT1))->LimitText(100000);
I placed these calls on InitDialog.
after I paste 5461 characters into my CEdit, it becomes empty and unresponsive. Any ideas as to what is causing this and workarounds to be able to paste long strings of text in a CEdit or any other control?
note: 5461 is 0x1555 or 1010101010101 in binary, which i find quite odd.
if I paste 5460 characters I have no problems.
I contacted microsof support.
The goal was to have approximately
240000 characters in one single
editable line of text.
I am able to reproduce the issue on
Windows Vista (x64 and x32 both) but
not on Windows XP.
this code works fine in XP:
BOOL ClongeditXPDlg::OnInitDialog()
{
CDialog::OnInitDialog();
// Set the icon for this dialog. The framework does this automatically
// when the application's main window is not a dialog
SetIcon(m_hIcon, TRUE); // Set big icon
SetIcon(m_hIcon, FALSE); // Set small icon
// TODO: Add extra initialization here
UINT limit = m_longEdit.GetLimitText();
m_longEdit.SetLimitText(240000);
UINT limit2 = m_longEdit.GetLimitText();
CString str;
str = _T("");
for(int i = 0; i < 250000; i++)
str += _T("a");
m_longEdit.SetWindowText(str);
return TRUE; // return TRUE unless you set the focus to a control
}
If I use a CRichEdit control instead,
when I press "end" key or "right
arrow" key after pasting a long string
inside, i cannot see all the
characters in the Rich Edit Control.
trying to scroll past the last visible
character produces a beep. The rest of
the characters are there, I know this
because if i double-click the Rich
Edit Control and copy the text using
ctrl-c and then paste it on a text
editor, I can see the 240000
characters. So the control is holding
the right amount of characters, but
the last characters are not viewable
except in an external editor, so my
original problem remains.
Here are the answers by microsoft
representatives:
Problem here is that an edit control
with a large number of characters in
it does not paint its text.
I tried setting different characters,
and discovered that I could fit more
'l's than 'x's than 'm's. The issue
isn't directly the number of
characters, but is likely the number
of pixels. Multiplying the number of
visible characters by the pixel width
of the characters in the selected font
shows that the limit is about 32k
pixels.
another answer from microsoft:
I did extensive research on this issue
and would like to update you about the
case progress.
The primary difference between the
Edit control on Vista and on XP is
that the Edit control on Vista
pre-composes its glyphs for better
international support (internally, it
ends up calling ExtTextOut with
ETO_GLYPH_INDEX and an array of glyphs
rather than a string of characters.
This ends up saving the glyph indices
into a metafile and so runs into the
32k pixel limit. When too many
characters are provided, ExtTextOut
fails and draws nothing. The Edit
control on XP doesn't precompose the
glyphs and so doesn't have this
problem, but won't handle
international characters as well.
The edit control on XP will clip at
32k, but since that is offscreen it
isn't obvious. When scrolling to the
right, it starts with the first
visible character so the visible part
of the control is always earlier than
32k pixels.
The RichEdit control draws the
beginning, but after hitting End,
edits occur mostly offscreen.
RichEdit 3.0 and 4.1 gives similar
behavior. This appears to be the 32k
pixel limit of RichEdit control, as
the it draws its text on an offscreen
bitmap before displaying it to the
screen.
Considering these points, the behavior
is by design. You would need to create
your own control to get the behavior
of displaying as big string as 240000
in a single line.
and the last one:
I did further research on this issue
for finding any light weight
workaround for overcoming 32k pixels
limit, but unfortunately it seems that
there is no workaround for this.
Couple of alternatives that we tried
are RichEdit 3.0, RichEdit
4.1, using UniScribe, using different fonts etc., but none of them seems to
suffice your requirement.
Possibly, you would need to create
your own custom control if you wish to
display an editable single-line string
which exceeds 32k pixel limit in
Windows Vista.
FYI -- if the text is read-only/dsiplay only, you can add some CR-LFs to the string to fix the display of the text. It appears that the ExtTextOut function works slightly different when the newlines. Since it is a single-line edit box the newlines are stripped so the text looks the same -- unless you copy and paste it, then the linefeeds will be in the string...