I have a unicode MFC Dialog application which has CEdit control. When i change the system language to Japanese/Chinese and enter Japanese or Chinese characters, I don't get EN_CHANGE or EN_UPDATE notification. The text goes to multiple lines. I get EN_CHANGE or EN_UPDATE if I do a ENTER from keyboard and text gets wrapped in a single line. I tried changing fonts from Dialogue resource; but still no luck.
Have you come across these kind of issues? Any clue or lead will be appreciated.
-Sukhas
Related
I have a problem with my Excel (Office 365, Windows 10) VBA Project. I am attempting to create a GETTEXT equivalent, allowing authors to internationalize and therefore provide localisations for their own projects. I am trying to replicate the view that somebody using Excel would see if using an RTL language such as Arabic.
I have downloaded, and installed the Arabic language pack. I have made it my preferred language and it opens up as default with my Office apps (BTW - I Don't understand Arabic, I could have as easily downloaded any other RTL language).
I have selected an Arabic font from Tools > Options > Editor Format > Font: Normal Text = "Dubai Medium (Arabic)"
Unfortunately, I am not able to display Arabic text directly in Control Properties window, e.g. Form caption or Textbox text; nor am I able to type or paste Arabic text into the Editor window. I get the dreaded ????.
Built-in Excel Message boxes and commands appear in Arabic and as RTL, but my message boxes and forms can't be set. The only workaround I've found so far is to place the Arabic text in a worksheet cell and call it from there or to paste the text directly into the form control. Also MsgBox allows RTL and Right-Align Text constants, which is fine, but this leaves my Forms all messed up, even if I programmatically change the .Left and .TextAlign values of controls, I still have the issue of left-aligned Form caption, right-aligned close button, and various issues with MultiPage and TabStrip alignment.
I can't believe Microsoft would be so awkward, so I must be missing something. I'm loathe to install Arabic as my Windows language just to test things, as that would really mess up my day - I'd be totally lost - no offence to Arabic users!
Any help would be much appreciated.
Ok, I finally got it to work (sort of). I had to set the System Locale to Arabic. This can be done by the following:
Settings > Time and Language > Language > Administrative Language Settings (link)
Then on the ensuing dialog...
Under the Language for non-Unicode programs, press the Change System Locale button and choose one of the Arabic options.
The only issue is that the Form caption is not right-aligned and the control box (close) is still on the right. But I guess that's small potatoes. All controls with a scrollbar / button (RefEdit, ListBox, ComboBox etc) now have the correct RTL positions. Tabstrips, Frames and MultiPages are also correctly RTL'd. I hope this helps anybody else puzzling over this issue.
I have excel file with some ActiveX CommandButtons integrated directly into worksheet. Their Captions written in non-English language with some non-English characters. Problem I encountered that some of these characters are not displayed correctly until CommandButton is clicked (picture below):
Have anybody encountered similar problem? I tried changing fonts and character size, but that did not helped.
I cannot provide any code since I have no idea where to start. Maybe it is possible to somehow fake constant focus to them?
Laba diena!
If you created these with ActiveX Command buttons, you should be able to view the name and caption properties by either 1) clicking once, then right-clicking to get a menu with properties as a choice or 2) double-clicking to get a click event started in the visual basic editor. From there you should see what's listed as the caption for the button.
In the button properties there should be a "TakeFocusOnClick" property that defaults to True. I don't know if it will fix your problem, but try changing it to false. I couldn't emulate your exact problem, so I couldn't tell.
sėkmės!
Sublime displays one panel at a time. Is there a way to cascade the panels on top of each other. For example when displaying the console, if I do super+f, the find panel should also display along with the console panel.
This is not possible; Sublime only wants to display a single panel at time and so the command that opens a panel implicitly closes any panel that might already be open first (at least logically).
This is part of the original design philosophy. As seen in the excerpt below, a desire to maximize space as much as possible is also one of the reasons why the find panel (for example) is a panel and not a Dialog or something else that would take up unnecessary space.
Unobtrusive, minimal chrome. The focus should be on the text, not fourteen different toolbars.
Don't obscure the text with dialogs.
Use the pixels you've got. Full screen, multi monitor and editing files side by side should all be possible.
This seems really silly but I somehow hit a key combination by mistake in text mate and now the colored coded typing is disabled. It's all just black text no matter php or html or variables etc... I scoured google and messed with all the preferences and can't get it back on.
any idea?
thanks in advance
You probably change the source associtation to plain text... at the bottom of the editor window there is a dropdwon where you can choose the source syntax, try selecting the appropriate context (ie. HTML, CSS, PHP, etc.)
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...