I have a page that uses the nabla character for bullets on a menu. The code for it is ∇. However, on my machine as well as some others around the office, this character comes up as the null character, [], in IE. In Firefox, though, it displays the actual character. My question is whether there is a fix for this so I can make sure anyone viewing this site will see the actual character. Is there a browser font that needs to be installed on any machine that views this site, or is it an issue that can be fixed from my end.
The empty square character is not the null character, it is a visual placeholder - a representation of a Unicode character for which there is no associated glyph in the current font.
There are couple of possible issues:
your page does not have explicit encoding associated with it and your IE is configured to use Win-1252 as default instead of Unicode.
the font family you specify in the CSS is missing on your computer and IE fallback font is different from Firefox and does not have tha babka char.
Make sure your page explicitly specifies Unicode encoding and use the iE developer tools and Firebug to examine the actual rendered style for the bullet and see what font is being used by the two browsers.
Related
There are obviously some bugs in Tab control of Common Controls 6
Here is my testing environment showing Tabs in often used way:
But when I switch to bottom aligned tabs, I get wrong aligned text here.
When I switch to left aligned view, it becomes more ugly. The underlined mnemonic char, represented with an ampersand in string and correctly interpreted is wildly shown at the end of the tab text and the tab is incorrectly dimensioned. The background colors of the tabs are not themed.
How can I tell Microsoft in an official way about the bugs?
CC6 tab control dropped support for everything except tabs on top. Sad but true.
This style is not supported if you use ComCtl32.dll version 6.
Im using CKEditor as a part of Grocery Crud (this is a php codeignihter crud setup), which uses CKEditor (3.6.5) to edit text fields.
So the problem im having is, some special characters (like Ā) gets somewhat stripped from CKEditor (this happens in the latest version too). Can someone help me make sure these special characters gets treated correctly (specially if there is any flags that i can set maybe)?
To test, just open up a CKEditor anywhere (use the Full demo on the CKEditor website), click the "source" button (to see html mode), then paste the following in the editor: Ā. Then click the source button again (to see the wysiwyg mode) and you will see a Letter A with a line above it. Then click the source again (to see html mode) and you will see that the characters you entered Ā have been replaced by the Letter A with the line above it.
Any thoughts about keeping CKEditor from stripping out the character codes?
The above only happens for some special characters (ones that uses decimal or hex codes) and not others which is a bit strange. And some character codes (that uses hex/decimal) get changed to some other codes (that has non hex/decimal alternatives, which is strange but atleast you end up with the same result).
Alright, let me answer my own question.
You need to add the following to the config:
config.entities_processNumerical = true;
In the case of grocery crud, this is done on the following file: /assets/grocery_crud/texteditor/ckeditor/config.js
More doccumentation can be found here: http://docs.cksource.com/ckeditor_api/symbols/CKEDITOR.config.html#.entities_processNumerical
To be fair though, im surprised this is not enabled by default. Not quite sure why.
Years ago, I was messing around with Visual Basic and I discovered a bug with the MsgBox function. I tried searching for it, but nobody had ever said anything about it. It's not just with Visual Basic though; it's with anything that uses the standard Windows MessageBox API call.
The bug is triggered when the title text has more than one character, and the first character is a lowercase 'y' with an umlaut ('ÿ'). What's so special about this character? It almost definitely not the character itself, but rather its ASCII value that's special. 'ÿ' is character 255 (0xFF), meaning it's the highest value that can be stored in an unsigned byte, and all its bits are set to 1.
What does this bug do? Well, there are two different possibilities, which depend on the number of characters in the title text. If there are an even number of characters (unless it's 2) in the title text, no message box appears, and you just hear the alert sound. If there are two characters in the title text, or any odd number other than 1 (in which case the bug wouldn't be triggered)...then this happens:
And that's not all--the message will also be truncated to one line. It seems like the kind of bug that would occur in at least one semi-high-profile incident, considering how often this API call is used. Are there any reports of this on the Internet, or anything showing what could cause it? Maybe it's a Unicode-related glitch, like that "bush hid the facts" glitch in Notepad?
I made a program in case you want to play around with this; download it here.
Alternatively, copy the following into Notepad, save it with a .vbs extension, and double-click it to display the dialog box seen above:
MsgBox "Windows 3.1 font, anyone?", 0, "ÿ ODD NUMBER!"
Or for a different font:
MsgBox "I CAN HAS CHEEZBURGER?", 0, "ÿ HImpact"
EDIT: It seems that if the first four characters are ÿ's, it doesn't ever display the message, even if there's an odd number of characters.
This is a bug with dialog templates generally. It is not a message box bug as such.
For example, in Visual Studio create the default win32 application. In the .rc file, change the caption in the template for the about box from
CAPTION "About sampleapp"
to
CAPTION "ÿT"
and the bug will manifest itself when you display the about box.
In the DLGTEMPLATEEX documentation note that the menu and class name have type sz_Or_Ord which means either a null-terminated string or 0xFFFF followed by a single word resource identifier.
Windows incorrectly applies a similar scheme to the dialog title: if the first character is 0xFF then it treats the title as being two WORDs long, but only when it is trying to locate the font information. When it is displaying the title it correctly treats the title as a string.
In other words, Windows is looking for the font information inside the title string. In most case this won't specify a valid font, so Windows defaults to the system font.
To prove this, I constructed a dialog template in memory (based on this). Once this was working I deleted the code that writes the font information to the template and used the dialog title "ÿa\xd\x200\x21SimSun". This displays the dialog in italic SimSun because windows is reading the font information from the title string.
This bug is likely a hangover from 16-bit Windows, where (I guess) 0xFF was used as the resource ID marker.
A strange bug. I suspect the symptoms are the result of the way the MessageBox() actually displays the dialog.
Internally, MessageBox() builds a dialog template dynamically. If you look at the description of a DLGTEMPLATE structure you'll find the following nugget of information:
In a standard template for a dialog box, the DLGTEMPLATE structure is
always immediately followed by three variable-length arrays that
specify the menu, class, and title for the dialog box. When the
DS_SETFONT style is specified, these arrays are also followed by a
16-bit value specifying point size and another variable-length array
specifying a typeface name.
So, the in-memory layout of a dialog template has the font specification immediately following the dialog box title.
Visual Basic does not use Unicode and so the function you're calling is actually MessageBoxA(). This is simply a thunk that converts the passed-in strings from multibyte to Unicode and then calls MessageBoxW().
I believe what's happening is that, for some reason, the conversion of that string from multibyte to Unicode is either going wrong, or returning a spurious length value. This has the knock-on effect, when the dialog template is built in memory, of corrupting the memory immediately following the title string - which, as we know, is the font specification.
I get some text string from service, which contains Unicode control characters
(i.e \u202B or \u202A and others for Arabic language support).
But while debugging I can't see them in default text visualizer. So I need to enable display for such characters to determine which of them my text consists of. There is checkbox in text visualizer "show all characters", but it doesn't work as I expect.
Any suggestions?
Thanks in advance
Those are codes for explicit RLE and LRE order, ie if in RLE something should be displayed in LRE order.
http://unicode.org/reports/tr9/#Directional_Formatting_Codes
We're having trouble setting window captions using cyrillic or japanese characters. We either see question marks or random garbage, but not the text we want. We've tried using different encodings, SetWindowText(), SetWindowTextW(), SetWindowTextA(), and so on. We can't even get it to work by passing a string literal to SetWindowText().
Our Windows install does appear to have everything it needs - Internet Explorer and Firefox do show cyrillic and japanese captions correctly, for example. So I'm pretty sure we're not finding the correct encoding/method combination. Any suggestions?
The problem you've got (at a guess) is that the top-level frame window of your application is an ANSI window. Under the hood, when you create a window (with CreateWindow() or CreateWindowEx()) a window class must be supplied. This window class determines the window's properties, including whether or not it, by default, accepts ANSI messages or Unicode messages. In turn, this is set by whether you (or your framework) register the window class by calling RegisterClassExA() or RegisterClassExW().
What's almost certainly happing is that your top-level window's class is being registered with RegisterClassExA(). This means that the default window procedure for the window will translate all Unicode strings in messages to ANSI before processing them, hence the question marks and odd characters everywhere.
The easiest solution to all this is to just make your application Unicode throughout (usually done by defining _UNICODE). The other way is to figure out where RegisterClassEx() is being called, and make it RegisterClassExW(). This may cause ANSI/Unicode issues with other messages, but it should (in theory, at least) work. Of course, either way will break Windows 9X, if that's an issue.
If all this sounds horrendously complicated, you're not wrong ...
SetWindowText()? Did you compile your application as Unicode? If not, SetWindowText() is equivalent to SetWindowTextA(), which in turn is limited to your current system locale (aka "Language for non-Unicode applications").
Also, how did you CREATE your window? Using an explicitely Unicode-aware API such as CreateWindowExW()? If not, make sure that your program is compiled as Unicode.
If your program is not compiled as Unicode, you might want to either modify your "Language for non-Unicode applications" in CP/Regional Options. Reboot required. Or more easily: Use MS AppLocale to simulate a cyrillic system locale
You have to compile your application with _UNICODE defined. Otherwise all windows will still be MBCS and not utf-16 and therefore can't show cyrillic or japanese characters if the codepage doesn't match.