Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations wOOdy-Soft on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Problem with ASCII code 2

Status
Not open for further replies.

InsideEdge

Instructor
Apr 5, 2005
35
US
Hi, I’m trying to use the ASCII code in Visual Basic 6. I have a list of the codes and I am trying to get a smile face to appear in my RichTextBox. The ACII code is 001 and it corresponds to the character of the smile face so I use Chr(001). Visual basic changes the Chr(001) to Chr(1) and I don’t see anything but a little empty rectangular box. Is there any way that I can get my smile face to show with some other code?
 
Let's start with the the following question: where are you getting the idea that ASCII 1 (note that there is no difference between 1, 01, 001, or even 0000001) represents a smiley face?
 
I thought you were supposed to look at the ANSI chart, not the ASCII one.

Lee
 
A few pages in the back of my Visual Basic 5 book has a list of ASCII code and their corresponding character. The list shows that 001 will be a smili face.
 
It doesn't matter; on no planet that I am aware of is ASCII 1 a smiley face; nor in ANSI
 
My RichTextBox does show ASCII characters but it may also show ANSI characters, can you tell me where I can find the function that displays ANSI characters and maybe a site that has the code for the characters?
 
... and then there's the issue of fonts. It may be that in some arcane font the correspondence does exist (none that I'm aware of however.) Since you're probably using one of the more common fonts, you're going to get the interpretation of Chr(001) to be whatever that font thinks it is.
 
Actually, ASCII 1 and ASCII 2 are smiley faces. What I was getting at was that the RichTextBox uses the ANSI character set for display, not ASCII.

Lee
 
Nope, fonts shouldn't enter into it either. The first 32 characters of ASCII and ANSI are control characters, which means they aren't technically displayable (some controls will use their 'non-displayable character placeholder' character when they encounter these, but that isn't the same thing at all)
 
Interesting... if I open an instance of notepad and I press alt+1 a smiley face appears. I used Lucida Console and Arial and both produce the same result. I am running XPSP2.


 
The following supports what I wrote about ANSI characters. See first comment by Idle_Mind toward the bottom of the page.


Back in DOS days, ASCII control characters were used to print to the screen for a variety of reasons, and my older books have the same charts InsideEdge referred to.

Lee
 
>Actually, ASCII 1 and ASCII 2 are smiley faces

No, they are not. The unicode characters (not properly supported by VB, BTW) selected by using ALT-1 and ALT-2 in many unicode Windows programs, however, are indeed smiley faces. But this is not the same thing as ASCII/ANSII characters 1 and 2 (nor is it the same thing as Unicode character 1, which is exactly the same as ASCII character 1 and ANSI character 1)

>the RichTextBox uses the ANSI character set for display, not ASCII

Yes, but so what? ANSI character 1 is the same as ASCII character 1, so this is irrelevant.
 
I've used ASCII 1 and ASCII 2 (among other control characer ASCII numbers up through #31) in programs I've written for DOS over a decade ago. Those controls are left over from the old Teletype machines, I believe. I know those 2 are control characters for Start of Heading and Start of Text. In DOS, they DO display the smiley faces, and bjd4jc stated that they display the same in Notepad (which I just verified was true with Notepad in Windows XP Pro SP2).

Lee
 
<sigh>

Look, the charcaters you are talking about are from the bastardised IBM PC Extended ASCII Display Characters (often known as ECS). Not ASCII, [/b]not[/b] ANSI. They are part of Unicode, but not Unicode characters 1 and 2

ALT+1 does not select ASCII, ANSI or Unicode character 1 - it selects Unicode character 9786

ALT+2 does not select ASCII, ANSI or Unicode character 2 - it selects Unicode character 9787

(and ALT-3 gives Unicode character 9829)

ALT-0xxxx selects Unicode (decimal) character xxxx

typing a hex number xxxx and then pressing ALT-X selects Unicode (hex)character xxxx

Note that all of these alternate input methods only work properly in fully Unicode-aware and compliant applications and controls. VB isn't one of these.
 
So - having established

1) It ain't ASCII
2) It isn't even ECS
3) It is a character extracted from the Unicode character set that matches one from ECS
4) VB does not properly support Unicode

One additional point to make is that not all fonts contain all the Unicode characters, so we have to select that wisely as well.

we need to figure out how to get the smiley into a richtextbox (which CAN display Unicode characters, if only we can get them in there, which VB doesn't make easy ...)

One way is to put the smiley into, say, Word using the ALT-1 technique already described to insert Unicode char 9786, then copy and paste it into the Richtextbox - but that's a bit unwieldy.

Another alternative is to ignore the ECS characters, and select the smiley from the Wingdings font (it's a capital J)

Finally we'll use a more advanced technique, and here's the example (you'll need a form with a richtextbox and a command button, and set a project reference to &quot;tom&quot; - a search in this forum will find other posts from me about &quot;tom&quot;):
Code:
[blue]Option Explicit
Private Declare Function SendMessage Lib &quot;user32&quot; Alias &quot;SendMessageA&quot; (ByVal hwnd As Long, ByVal wMsg As Long, ByVal wParam As Long, lParam As Any) As Long
Private Const WM_USER = &amp;H400&amp;
Private Const EM_GETOLEINTERFACE = (WM_USER + 60)

Private Sub Command1_Click()

    Dim myIUnknown As IUnknown
    Dim tomDoc As ITextDocument
    
    SendMessage RichTextBox1.hwnd, EM_GETOLEINTERFACE, 0&amp;, myIUnknown
    Set tomDoc = myIUnknown
    
    RichTextBox1.Font.Name = &quot;Arial&quot; ' select a font we know has the Unicode characters in it
    RichTextBox1.Font.Size = 24 ' Make it big so we can clearly see it
    RichTextBox1.Text = &quot;&quot;
    tomDoc.Selection.Char = &amp;H263A ' places Unicode char 9786 (smiley face) at insertion point
End Sub
[/blue]
 
While ASCII codes 1 and 2 [!]may[/!] display as smiley faces on some operating systems, the purpose of those ASCII codes is not simply to display smileys.

I knew that the trusty old 1987 "Dave Williams Programmer's Technical Reference for MSDOS and the IBM PC" would still come in handy all these years later:

ASCII 1 (Ctrl-A) SOH Start of Heading
ASCII 2 (Ctrl-B) STX Start of Text

Who knows why smiley faces were chosen to represent these control characters - they could have been anything.

If you want smiley faces, you should use character codes designed specifically to reproduce the smiley face characters for the font in use (there are many in the Wingdings font), rather than character codes designed to be control characters.

Hope this helps,
Dan

[tt]Dan's Page [blue]@[/blue] Code Couch
[/tt]
 
I'd have to agree with strongm on this one. And just in case you wondered, the comparable character in EBCDIC is also not a smiley... ;-)


In some applications/software, the smiley is used as a default 'undisplayable' character replacement - sometimes it's a square box (e.g. for MS stuff), in Firefox for example it uses a black diamond with a question mark in the centre for undisplayable chars.. e.g. SOH, STX, BEL, etc... Maybe this is the behaviour you're observing, maybe not.. but it certainly isn't the intended use of ASCII/ANSI Char 1.

A smile is worth a thousand kind words. So smile, it's easy! :)
 
Just to make it interesting...

Create a small file:

face.vbs
Code:
WScript.Echo Chr(1)
WScript.Echo Chr(2)
Open a command window and execute the script as:

[tt]cscript //Nologo face.vbs[/tt]

Guess what you get? Faces!

A compiled VB6 console-mode program will produce similar results.

It's all about console code pages, which determines how characters are displayed in a console. Character display under the Windows GUI is an entirely different thing.
 
Absolutely, because the console, by default, uses ECS. Got no argument with that.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top