How Windows 7 broke VB6's RightToLeft property, and how to get it fixed

by Michael S. Kaplan, published on 2010/02/13 07:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2010/02/13/9962894.aspx

I was helping people with some VB add-ins that had to be supported in multiple languages when everyone suddenly realized (after an email I sent out about the subject) that the sample code provided to help with runtime localization was not going to work for Arabic or Hebrew since VB's RightToLeft property couldn't be changed at runtime. It wasn't their fault, really; it was the CreateWindowEx function in the Win32 API that was to blame since you could never change the directionality of a window after it had been created.

VB's position was that this was by design since the technology they were using didn't support the notion, but I convinced Jim (a VB developer who is no longer at Microsoft) of the speciousness of that argument, since Windows wasn't sticking an easy property out there that anyone could set. So for VB 6.0, Jim made this property settable and did the work behind the scenes to destroy the window and recreate it (at the time a novel concept since suddenly, the handle on the window could change, a rich source of bugs for testers to find!).

There were a bunch of people who were being persuaded, convinced, and cajoled to support the new ComAddIn interface that Office 2000 was going to use to let people plug their Visual Basic 6.0 add-ins into the suite by a program manager named Dave who also no longer works for Microsoft.

I myself (still a mere vendor to Microsoft at the time but who was doing a number of different jobs for various groups) had contracts to help with the integration of four different add-ins, including one that I had written myself and another of which I had mostly written.

Anyway, it was around the first week in December I think that there was some panic since Dave had promised a localization framework. The panic was Dave's as there was no such framework. How could there by VB add-ins in the Office box if no one was going to be able to translate them into the Office languages.

He started to write something but it really wasn't very good, plus it was incomplete.

Dave was overjoyed since it meant he was not going into the midyear with a major initiative flopping, and other devs looked at the framework and saw it would do the job they needed. Everyone was happy.

Dave was willing but they had no money, the teams that I was working for specifically refused to pay for it since the work I was doing for them was scoped tightly and this work was being promised by a shared team. Other teams felt the same way, plus no one wanted to own testing the framework or supporting it.

I suppose I could have been a jerk and just sent a cease and desist and made them take the framework out of those products. Someone would have paid me then but I doubt I'd have a whole lot of future work to look forward to for groups at Microsoft.

I decided to be magnanimous and just grant Microsoft a permanent, non-transferable, non-exclusive license to my "Win32Dialog" class. Perhaps not entirely selfless since it saved at least four of those contracts. :-) Anyway, crisis averted, though even years later I would have someone in legal sending me email asking me about the two files (win32dlg.bas and win32dlg.cls) with the header that said:

and how to get that taken care of. When I explained the situation and told them to take care of it all they had to do was pay me for the three weeks they decided they could live with it.

A modified version of the code went into my book (Internationalization with Visual Basic).

Of course the code included the RightToLeft property and its ability to be set (this was the one piece of the code that would fail in VB 5.0). This was used by several different add-ins and I am told some other projects though I never got a full list.

Now getting back to that property, the implementation was set up to only work on systems with "Right to Left" support, which sometimes included Windows 2000/XP but not always given the nature of What isn't in the default install for NLS. There is a generic dislike within Microsoft of hacks like hard-coding Arabic and Hebrew but there did not seem to be another option. Though luckily, or perhaps unluckily for reasons that will later become clear, some old code supporting WinMe/NT4 using an Arabic/Hebrew specific hack of a special flag to IsValidLocale was found and used instead.

Somehow using someone else's hack is more palatable than using one's own hack. :-)

Neither Windows Me nor NT 4.0 are covered by even extended support, and no one knew anything about what the hack was there for or why and everyone hated this kind of thing anyway. So after a small amount (some would say too small but I'm going to be broad-minded here) of due diligence they removed the hack (roughly akin to fixing the glitch!) and Windows 7 shipped that way.

Fast forward a small amount, and suddenly complaints start rolling in about the broken RightToLeft property on Windows 7. At least four sustained engineering requests for fix to Windows and perhaps some on VB and lots of public outcry including threads like this one and many others you could probably find if you tried for a few minutes.

Apparently people noticed that this little old property that was added because I complained enough to Jim one night a decade ago was broken.

Okay, first things first - the quickest/easiest thing to fix is the documentation problem. Which they did, in IsValidLocale:

Of course they also had to add the hack back so that Windows 7 would stop breaking VB6 here. That part was also fairly straightforward since all they had to do was put the code back that had been taken out. :)

The hotfix is officially available, but the KB article is perhaps not out yet (it was not when I just looked). You have to contact Microsoft Product Support and ask for the hotfix associated with KB979643 to fix the VB6 RightToLeft property when running on Windows 7 (Microsoft Product Support can look it up on their tools). Make sure you specify the flavor(s) you need (x86, x64, ia64) and they can get you the hotfix. It will also be rolled into the next service pack but the hotfix is good for the people broken now (a list that includes at least one police force, one government, one hotel chain, and one publisher!).

Now I am not going to try to take responsibility here for any of this since my involvement in the break was non-existent (I was no longer on the team) and my involvement in the fix was minimal (I reported one case and pointed out the underlying reason but they figured it out independently).

I suppose maybe it was because of me that the property was added and because of the person who added the property that the flag was used and because of the nameless MEPD dev that the flag no one knew about even existed.

There may even be a moral here about not deleting stuff if you don't know why it's there, but like I said there was some due diligence involved and code can get heavy enough from the hacks and workarounds you know about, let alone the ones no one understands.

The real moral of the story is that the original hack should have been commented better. This mistake was remedied in the re-inserted code:

And this change (which would have kept the break from happening in the first place) will certainly keep it from being broken again.

Michael, hello.

First I'd like to thank you for this post, as I have exactly the problem you described in my VB6 application.

I wonder if you have any suggestions on how to solve another problem - which is also related to multilingual support.

The problem is best described here:

"LoadKeyboardLayout is very slow on Windows 7"

http://social.msdn.microsoft.com/Forums/en-US/windowscompatibility/thread/fa5589d5-4090-465d-93c4-05ca549d4cb1

Although I develop in MS-Access, I believe this is essentially the same problem. The fields in MS-Access have "KeyboardLanguage" property. With this property set, it takes forever just to enter the field.

You already have high tier support engineers talking to core folks on the product team in that one, so I think you are already in better hands than mine. :-)

Though I will say you are changing the keyboard way too quickly and you are doing it with the wrong function -- you should be storing HKL values and using them.

i can't speak to the MSAccess issue, but I don't think they are using LoadKeyboardLayout, and once again it is doubtful one needs to switch as often as that....

But this is very offtopic for here, if you want it on the list the Suggestion Box is probably better. :)

what is the result of this topic?

how we can fix?

please upload a Project or Setup for fix this problem.

thx

I gave the answer above, in red. You must call Microsoft and ask for the fix in the KB article with the ID I listed.

Or you can wait for the service pack, whenever that might be.

No one has the legal right to upload a project or setup file.

It is internally published and people can request the hotfix from Product Support, which is all the KB article would have done anyway... and many have gotten the fix after following this advice.

hi.

this hotfix not work in win7 64 bit !

please help us : ((

There is an x64 hotfix available, make sure you download the right one and it installs properly. After that if you still have problems (it worked for me) you can go through support (as with all hot fixes)....

i have never installed hotfix, and i am pretty new in vb6. i am programming on windows xp and install the program that i built on windows 7 and the RTL does not work (it does work on XP, just as described above). should i just run my windows 7 get the hotfix installed and after that all my vb6 application will work? should i do something else? i should install the hotfix on the computer with the windows 7 and not on the computer that i program in, right?