Fog Creek Software
Discussion Board




VB6 and Unicode

We're having nightmares at the momemnt with Greek characters in VB.  None of the controls have proper unicode support.

Unicode supporting controls are available in the FM20.dll, but this is part of Office.  We cannot distribute with our applicaitions.

Looks to me like this is a problem Microsoft could easily fix with a patch, but they haven't.  Has proper support for VB6 ended already?

Could this be the start of the push from VB6 to VB.Net? 

Ged Byrne
Wednesday, October 30, 2002

FM20.dll is part of VBA and I found this in reference to Visio.

=============================
Microsoft® Visual Basic® for Applications (VBA) in Microsoft® Visio® provides the Microsoft Forms 2.0 ActiveX® controls, which include standard dialog box controls, such as buttons, check boxes, text boxes, and combo boxes. You can distribute these controls most simply with a Visio solution, because they are included with Visio—no special installation or additional licensing is required.

You might acquire other controls by installing Microsoft Visual Basic or C++, downloading controls from the Internet, or buying third-party packages. Distributing a solution that contains such controls can be a little more complicated:

Because the controls might not already be on the user's system, your solution's Setup program needs to check whether the control is already installed and, if not, install the control and register it on the user's system.
Such controls typically come with a design-time license, so you can use them in your development projects, and the controls might require a run-time license for distribution.
For details about installing, registering, and licensing third-party controls, see the developer documentation provided with the control
=============================

To feel more comfortable I would hunt around and find the exact liscence that allows you to use this component from VBA. But it seems to me that it is supposed to be redistributable.

Rob Conley
Wednesday, October 30, 2002

The following knowledge base article makes it clear that fm20.dll is not freely distributable.

http://support.microsoft.com/default.aspx?scid=kb;en-us;Q224305

However, as the article states, you can get the dll onto a users machine by getting them to download and install the free Active X control pad.

So, microsoft are making the dll available for free.  However, they will not make it easy for developers to install with their applications.

This seems to be pure obstruction.

Ged Byrne
Wednesday, October 30, 2002

As far as I can tell VB6 is supposed to have full Unicode support.

Now what happens when you create Unicode applications in VB and then try and run them on a non-Unicode OS I don't know.

i've emailed you a couple of bits of info, and will try and find some more.

Incidentally MS is still selling and supporting VB6. It's unlikely to change until it has managed to port over VBA to be compatible with .NET and that appears to  be three years off.

Stephen Jones
Wednesday, October 30, 2002


Of course, you can avoid all that OCX nightmares and use Delphi instead.

(Sorry, couldn't resist :-)

Leonardo Herrera
Wednesday, October 30, 2002

Thanks for all the info, Stephen.

We have now cracked the control problem.

The international fonts have a range of 'scripts' that cover different characters.  For example, Greek.

Now we just can't get unicode from our database using ADODB 2.7 recordsets.

Java and Delphi manage to have proper Unicode support.

Your comments about VBA are interesting.  Office (and therefore VBA) has much better Unicode support than VB, thanks to the restricted license extension in FM20.dll. 

Ged Byrne
Wednesday, October 30, 2002

The standard answer from Microsoft seems to be

"This is an issue that is being addressed in the next version of Visual Basic, also known as VB.Net."

Ged Byrne
Wednesday, October 30, 2002

The main area where VB6 is lacking unicode support is that the built-in edit control only supports the local character set.

To work around this:
* use the rich text control
* embed IE as an editor
* or buy a third party edit control that supports unicode.

Before you whack your brain out too hard make sure you've read the book by Michael Kaplan

http://www.amazon.com/exec/obidos/tg/detail/-/0672319772/

Joel Spolsky
Wednesday, October 30, 2002

Actually the Delphi Visual Component Library (VCL) does not support Unicode. This is a common request amongst Delphi developers.

John Topley
Wednesday, October 30, 2002

Ged,

<quote>
Now we just can't get unicode from our database using ADODB 2.7 recordsets.
</quote>

I am intrigued by this comment. What database? And what datatype?

In SQL Server, I believe you would need to use the n data types (eg nvarchar, rather than varchar). Have you done that?

Seeya

Matthew Wills
Wednesday, October 30, 2002

"Actually the Delphi Visual Component Library (VCL) does not support Unicode. This is a common request amongst Delphi developers."

There are free third-party components that address this, though.

Frederik Slijkerman
Thursday, October 31, 2002

---------------------------------------------------
I am intrigued by this comment. What database? And what
datatype?
---------------------------------- Matthew Wills

Actually we are using SQL Server.  We are using wchar, but as soon as we apply it to a string it is lost.

In Java, Delphi or C(++) I could get around this.  I  could access the String as a Byte Array, or use a WChar like character type.

However, VB is doing all of the data conversion for me.  No matter what way I do it as soon as I do rs.fields("Description").value my nice Greek letters held in a WChar field is being stripped down into squares and question marks.  Am I missing something obvious?  It is so frustrating!

Ged Byrne
Thursday, October 31, 2002

Possibly Matthew is giving the correct reason. Here's what "Dr. International" saya. It's actually fromthe very first article he gives.

"If everyone supports Unicode, then why are my strings broken?
Dear Dr. International,

I am using SQL Server 7.0, and I am trying to run an UPDATE query in an ASP page via ADO. I am building the query on the fly and the syntax I am using is:

UPDATE Table1 SET Col1 = 'New Text' WHERE id = 1000

The column data type is NTEXT. This SQL works well for English data, but if I try to insert Japanese data on my US English Windows 2000 server, all of the characters inserted into the database are broken. I thought that ADO was supposed to be Unicode?

(From the Internet)
Dr. International replies:

Yes, you are right. This is a problem that many people run into (and also happens with SQL Server 2000). It seems like every component (SQL Server, ADO, ASP) supports Unicode, so how could strings get corrupted?

Luckily, Dr. International can assure you that you are not crazy. Incidentally, the problem is not merely restricted to ADO and web-based interfaces; it can also happen in stored procedures that build UPDATE SQL statements on the fly.

The answer to this question is actually in the SQL Server Books Online, hidden in a topic named Using Unicode Data. At almost the very bottom of the topic, there is a very innocuous-seeming statement: "Unicode constants are specified with a leading N: N'A Unicode string'."

Here is the root of the problem! Since SQL Server 7.0 and 2000 support both Unicode and non-Unicode data types, they require you to use the "N" prefix in front of Unicode string literals. Even though ADO is sending the query as Unicode text (since all COM automation components have Unicode interfaces), SQL Server believes that the string literal 'New Text' is supposed to be on the default system code page (CP_ACP) and it converts it to that code page. Then, upon inserting the text to an NTEXT column, SQL Server converts it back to Unicode using CP_ACP. This causes a slight performance hit for the query because of the two extra conversions, but it also causes strings to be corrupted if they are not on your server's default system code page.

Now that Dr. International has diagnosed the problem, he can prescribe the cure: simply place that "N" prefix in front of the string literal you are using:

UPDATE Table1 SET Col1 = N'New Text' WHERE id = 1000

This will allow your data to be inserted without corruption, and also slightly faster!"

Stephen Jones
Thursday, October 31, 2002

Stephen,

You've been a great help.  Thanks.

Joel,

I've order the Michael Kaplan book.  Thanks for the tips.

Ged Byrne
Thursday, October 31, 2002

Just a quicky does this still apply to ADO.NET?
(I'd try it but I don't have the stuff to hand at the moment)

Peter Ibbotson
Thursday, October 31, 2002

I'm using Unicode in a Vb6 Grid control. See www.cyberactivex.com (Coming soon - CyberActiveGrid). Although I use FM20.Dll for in-place editing all the screen output is done via API DrawTextW. Unicode tooltips are handled using StrConv(sTip, vbUnicode). Unicode works correctly in the Grid also when connecting using ADO 2.7.

Although Fm20.DLL is not redistributable anyone can download it free as part of activexcontrolpad at http://download.microsoft.com/download/activexcontrolpad/Install/4.0.0.950/WIN98MeXP/EN-

Users with a non-English version of Office may be missing FM20ENU.DLL which you can get from the above download. The symptoms are that the controls appear in the Toolbox but cannot be placed onto the form.

dseaman
Sunday, July 06, 2003

*  Recent Topics

*  Fog Creek Home