With common controls v6 (available since XP), we can use VB's own textbox (some limitations explained later) for a simple input-only textbox, and have it accept unicode text. Of course, you can get the unicode text also. No subclassing, no custom controls.
CAVEAT: Not perfect, but for many scenarios, this is as simple as it gets without subclassing or adding other controls to your project for the sole purpose of an input unicode-aware textbox. Requires common controls v6 manifest.
Limitations.... If the textbox is only meant for input, these limitations are not that bad.
1. This 'trick' requires the textbox to be multi-line. You can kind of imitate a single-line textbox by setting the scrollbar to horizontal only, then hiding the scrollbar during form_load. This will prevent the text from wrapping when the caret goes past the visible horizontal boundary. What this doesn't do is prevent a user from getting to a new line via Enter or Ctrl+Enter, nor does it prevent the user from pasting multiple lines of text from the clipboard. With a little effort you can overcome this limitation with keyboard events and/or keyboard-related APIs; along with monitoring the textbox change event. A simple Enter key can be prevented with something like:
Code:
Private Sub Text1_KeyPress(KeyAscii As Integer)
If KeyAscii = vbKeyReturn Then KeyAscii = 0
End Sub
2. You can't really edit the text other than sending text to the clipboard in unicode format and pasting it to the textbox. This is why I suggest limiting this trick to just input-text boxes, i.e., custom inputbox, textbox on a usercontrol's property page, etc.
3. Must include a manifest with the project, textbox has got to be themed with common controls v6. An external manifest can be applied to VB6.exe to have the IDE themed, allowing you a WYSIWYG experience while in IDE.
4. Use of APIs to hide the horizontal scrollbar and get text
How to set it up.
1. Place a textbox on your form. Size it the way you need and ensure at least these properties are set:
Mutliline = True
Scrollbars = Horizontal
2. If you actually want a multiline textbox, then set the scrollbars how you want & ignore this step. In form_load, hide the scrollbar
Code:
Private Declare Function ShowScrollBar Lib "user32.dll" (ByVal hWnd As Long, ByVal wBar As Long, ByVal bShow As Long) As Long
Private Const SB_HORZ As Long = 0
Example: ShowScrollBar Text1.hWnd, SB_HORZ, 0&
3. Retrieving the text in unicode, requires several APIs. The reason why a multiline textbox is required is that EM_GETHANDLE message is invalid for single line textboxes. And simple APIs like GetWindowTextW don't return unicode from the textbox; neither does VB's .Text property.
Code:
Private Declare Function SendMessageW Lib "user32.dll" (ByVal hWnd As Long, ByVal wMsg As Long, ByVal wParam As Long, ByRef lParam As Any) As Long
Private Declare Function lstrlenW Lib "kernel32.dll" (ByVal lpString As Long) As Long
Private Declare Function LocalLock Lib "kernel32.dll" (ByVal hMem As Long) As Long
Private Declare Function LocalUnlock Lib "kernel32.dll" (ByVal hMem As Long) As Long
Private Declare Sub CopyMemory Lib "kernel32.dll" Alias "RtlMoveMemory" (ByRef Destination As Any, ByRef Source As Any, ByVal Length As Long)
Private Const EM_GETHANDLE As Long = &HBD
Example:
Dim s As String
Dim lCount As Long, lHandle As Long, hGlobal As Long
lHandle = SendMessageW(Text1.hWnd, EM_GETHANDLE, 0&, ByVal 0&)
If lHandle = 0 Then Exit Sub ' fails on single-line textbox controls
hGlobal = LocalLock(lHandle)
lCount = lstrlenW(hGlobal)
s = String$(lCount, 0)
CopyMemory ByVal StrPtr(s), ByVal hGlobal, lCount * 2&
LocalUnlock hGlobal
' variable s now contains the unicode text
4. Pick a decent, scalable true-type font for your textbox.
For a bit more control without the 1st limitation mentioned above, you can always create an API unicode textbox, setting the window style as you need. Still shouldn't need to subclass or add external controls.
The best solution is a full-blown unicode textbox, but this thread is simply meant to offer a suitable substitute if the scenario fits.
Screenshot below simply shows that this will not work if the project is not themed via a manifest. When the text was retrieved, here are the hex values of each character (AscW), after pasting those Chinese characters: 5C0F 7EA2 72D0 72F8
FYI: Google Translate -- great place to get various language translations & unicode characters for copying and pasting for testing.
Edited: I hosed up the lstrlenW API, sorry about that. Always a risk of leaving in test code. Oops & fixed the sample code above.
Last edited by LaVolpe; Jun 15th, 2017 at 07:48 PM.
Insomnia is just a byproduct of, "It can't be done"
Or just use an InkEdit control. We've had these in Windows for over 10 years now and you can use them single or multi-line. These are independent of the Common Controls assembly selected for a process.
If you don't need ink recognition just turn that off (.InkMode = IEM_Disabled). You can use these for either plain text or RTF, they are fully Unicode-enabled.
The only frustrating thing is the lack of an AutoVerbMenu property, probably because of their main purpose as part of the Tablet PC subsystem where pen/touch is used for handwriting input.
Not sure what you are looking for, but I found this thread very interesting. I have already used this control in an application. Now if I could only find something similar for a ListBox.
J.A. Coutts
Code:
Option Explicit
Private Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (Destination As Any, Source As Any, ByVal Length As Long)
Private Function HexToByte(HexStr As String, bHex() As Byte) As Boolean
Dim lLen As Long
Dim lPntr As Long
If Len(HexStr) > 1 Then
lLen = Len(HexStr) / 2
ReDim bHex(lLen - 1)
For lPntr = 0 To UBound(bHex)
bHex(lPntr) = Val("&H" & Mid$(HexStr, lPntr * 2 + 1, 2))
Next lPntr
HexToByte = True
End If
End Function
Private Function ByteToUni(bArray() As Byte) As String
ByteToUni = bArray
End Function
Private Sub Command1_Click()
Dim sTmp As String
Dim bTmp() As Byte
Call HexToByte("0F5CA27ED072F872", bTmp)
sTmp = ByteToUni(bTmp)
InkEdit1.Text = InkEdit1.Text & sTmp & vbCrLf
InkEdit1.SelStart = Len(InkEdit1.Text)
InkEdit1.SetFocus
End Sub
couttsj, I am looking for answers on my questions on post # 5.
I prepared a project (look post # 5), as described on 1-st post, but it doen't work as Jonney show in post # 2. All unicode characters are '?????'.
I want to know what I done wrong.
couttsj, you show example for InkEdit control, but this topic describe how to add unicode support for TextBox control.
This will not work in IDE unless the IDE is manifested to be themed. In fact, based on Jonney's post #2. May not even work for keyboard input. That is something I should have verified before creating this thread and will attempt to do so today or tomorrow.
P.S. By the term "input only", I was trying to say that you cannot use it for output, i.e., display unicode text by setting the .Text property, using SetWindowTextW and other APIs. At least I haven't found a way to do that. But if keyboard input isn't working; there is no point displaying pasted unicode text only, is there?
Insomnia is just a byproduct of, "It can't be done"
This will not work in IDE unless the IDE is manifested to be themed. In fact, based on Jonney's post #2. May not even work for keyboard input. That is something I should have verified before creating this thread and will attempt to do so today or tomorrow.
This appears to work with the keyboard also，but not with Chinese & possibly other languages? More testing would be required. Though not explicitly said, a manifest must be applied.
Edited: Got Chinese to work. In the regional settings, there is an "Administrative" tab that specifies what language to use for non-unicode applications, i.e., VB6. When I set that to Chinese then the textbox not only accepted Chinese characters, the code from post #1 also retrieved them.
Last edited by LaVolpe; Jun 15th, 2017 at 03:47 PM.
Insomnia is just a byproduct of, "It can't be done"
It should accept Chinese input from keyboard if you are using Chinese Windows (and you know how to use it, e.g. to enter a Chinese character by spelling out the character phonetically with keyboard keys). The hand-writing input device I mentioned is just another media, pasting is also okay of course. (The hand-writing input device I got was given to me as a gift by one of my program users about 10 years ago - one can just hand-write out the characters, much like one would do on an iPad.)
Actually I myself can vouch that (1) a manifest is definitely not required and (2) there is no problem running the code in IDE.
If I recall, the only shortcoming manifested so far is the use of arrow keys. If you don't click the textbox control once, despite the caret is already blinking inside the textbox, using an arrow key to navigate the cursor position among the entered characters may not behave as you would expect.
Here are my results. If you see a flaw, please let me know. This unicode testing is still rather new to me. Using Win10
Regardless of the language, but will use Chinese here. Tests were compiled. One with manifest, one without.
Test 1: Ran exact code as in post #1, only adding a msgbox to display the ASCW() value of 1st character in textbox.
a. Regional settings: set language to Chinese & country to China. Non-unicode language remains English
b. Signed off & back on to make changes take effect
Unmanifested textbox (sunken borders) + manifested (themed) both showed ??? characters
Test 2: Changed non-unicode language to Chinese which required a reboot. No other changes
Unmanifested textbox showed ???? characters & returned 63 for ASCW(). Manifested worked perfectly
Edited： Same results within the IDE when IDE was manifested.
I will assume that someone running VB on their local machine, has their local machine setup for their preferred language. Whether that requires changing the non-unicode language to other than US, I don't know but would think so.
In all tests I was using the windows keyboard utility from the taskbar which is available when you have multiple language packs installed on your box.
Last edited by LaVolpe; Jun 15th, 2017 at 07:46 PM.
Insomnia is just a byproduct of, "It can't be done"
This appears to work with the keyboard also，but not with Chinese & possibly other languages? More testing would be required. Though not explicitly said, a manifest must be applied.
Edited: Got Chinese to work. In the regional settings, there is an "Administrative" tab that specifies what language to use for non-unicode applications, i.e., VB6. When I set that to Chinese then the textbox not only accepted Chinese characters, the code from post #1 also retrieved them.
Caution: I am afraid Brender's ucUniTextBox or by CreateWindowExW doesn't really work for Unicode, at least on my Win10 32bit 1607. My non-unicode setting is Simple Chinese (PRC), but I got question mark.
Long time about some months ago ,With Win10 upgrading to 1607 or something happening, I suddenly found VB6's TextBox can't typing Chinese (wrong char or question marks) even with Simple Chinese (PRC) setting for regional non-Unicode. The reason still can't identify until now. Luckily Krool's textbox always works.
Last edited by Jonney; Jun 15th, 2017 at 08:34 PM.
Jonney. My previous comments were not about Brenker's control. In fact the point of this thread was "no custom controls, no subclassing". Yet I get links to custom controls and ocx's.
On my Win 10 1607, when manifested, the VB textbox appears to work as long as I changed the regional setting's "administrative" tab's non-unicode default language to Chinese (Simplified)
Insomnia is just a byproduct of, "It can't be done"
Jonney. My previous comments were not about Brenker's control. In fact the point of this thread was "no custom controls, no subclassing". Yet I get links to custom controls and ocx's.
On my Win 10 1607, when manifested, the VB textbox appears to work as long as I changed the regional setting's "administrative" tab's non-unicode default language to Chinese (Simplified)
Of course, It's well-known that VB6 TextBox work perfectly for Chinese Char with non-unicode default language to Chinese (Simplified). It works for many years. But recently, I found my VB6 TextBox got weird problem, it can't typing Chinese any more. I never had such problem. Just now, I tested few codes which were worked for many years such as Version from 'Vesa Piittinen aka Merri' and your lvUniText. All failed. CyberActiveX and Krool's are OK.
My lvUniText? Sheesh. Forgot about that -- it was one of my first attempts a long time ago. Wouldn't be surprised it doesn't work; never pursued it.
But if this attempt of a manifested VB textbox also fails, then I say this is not a good enough alternative. Would like to know if this fails for you too, when manifested and using a truetype font?
Insomnia is just a byproduct of, "It can't be done"
But if this attempt of a manifested VB textbox also fails, then I say this is not a good enough alternative. Would like to know if this fails for you too, when manifested and using a truetype font?
Previously, before few months ago, VB6 Textbox works w or w/o manifest, everything works. I had re-installed VB6 for many times and copy/paste/register comctrl32... ocx for many time, but still failed. Very weird in my life.
As I posted early, the method @#1 only works with manifest and MultiLine applied when we pasted Chinese from somewhere such as IE/Chrome with Chinese (PRC) or English (US) non-unicode setting.
But for my problematic win10 1607, I can't typing Chinese on VB6 textbox with Chinese (PRC) non-unicode region, #1 method also failed with typing, though paste is OK. But on normal functioning windows except my weird problem, typing should be OK w/o problem if we set Chinese as non-unicode setting.
Up to now, CyberActiveX's free Textbox and Krool's TextboxW works on my weird win10. Most of previous working examples created by CreateWindowsExW failed to typing Chinese. I assume it is just my case, I don't know whether others have the same problem.
Last edited by Jonney; Jun 15th, 2017 at 09:38 PM.
Thank you for the feedback. It does work on my Win10.
I assume it is just my case, I don't know whether others have the same problem.
I doubt it. Maybe others too. I would think there should be others on the net asking about this problem. It is odd to hear API textbox is suffering from same problem. I wonder if some of the API textbox controls are failing due to messages they are handling incorrectly, but Krool is handling correctly. In other words, if you place a API textbox on a test form and do no subclassing, nothing, will the textbox accept your keyboard characters?
Insomnia is just a byproduct of, "It can't be done"
Thank you for the feedback. It does work on my Win10.
I doubt it. Maybe others too. I would think there should be others on the net asking about this problem.
I searched the website, nobody report such case. I assume it is my specific case. it may come from 1607 upgrade or some install/uninstall.
In other words, if you place a API textbox on a test form and do no subclassing, nothing, will the textbox accept your keyboard characters?
all question marks or wrong characters. it is very weird. Usually, If we set Chinese as non-Unicode, typing Chinese in VB6's textbox or API textbox should work. I never got this kind of problem along those years. NEVER.
I wonder if some of the API textbox controls are failing due to messages they are handling incorrectly, but Krool is handling correctly.
Krool's textboxW works OK which is independent of non-Unicode setting.
Last edited by Jonney; Jun 15th, 2017 at 10:31 PM.
I haven't got a chance to try my Unicode TextBox on Win 10 1607. When I run it, it was on Vista, Win 7 and the earlier Win 10 - all these times, I never had to touch a non-Unicode setting (e.g. to select Chinese), nor change any of the original English/French settings in the system since Windows installation.
Would Jonney like to try to select one of the following font to try specifically? [Arial Unicode MS], [FangSong], [KaiTi], [Microsoft YaHei], [NSimSun], [Segoe UI], [SimHei], [SimSun] or [Tahoma]. The purpose is to test whether the failure is due to a failure in "auto fall back" when the font used is without Chinese characters.
I haven't got a chance to try my Unicode TextBox on Win 10 1607. When I run it, it was on Vista, Win 7 and the earlier Win 10 - all these times, I never had to touch a non-Unicode setting (e.g. to select Chinese), nor change any of the original English/French settings in the system since Windows installation.
Would Jonney like to try to select one of the following font to try specifically? [Arial Unicode MS], [FangSong], [KaiTi], [Microsoft YaHei], [NSimSun], [Segoe UI], [SimHei], [SimSun] or [Tahoma]. The purpose is to test whether the failure is due to a failure in "auto fall back" when the font used is without Chinese characters.
I believed you used Chinese Windows. If you used English version, you have to set non-unicode for native VB6 textbox for Chinese displaying and typing.
I am using English Windows. The only time I had come across a Chinese Windows was last year when some one in the neighborhood asked me to help her and her son on a Win 7 problem. I found that I had difficulties understanding the Chinese terms, e.g. in menu and submenu names.
I am confirmed that we have to properly HOOK WM_IME_CHAR/WM_UNICHAR/WM_CHAR to resolve IME issue. API TextBox created by CreateWindowsExW doesn't apply such techniques will be potentially failed while IME/3rd keyboard input typing on 1607 Windows 10.
Hi LaVolpe. Sorry to jump in mid-thread (especially when you've already been plagued by thread hijacking, ugh), but with Jonney's help, I wanted to briefly expand on his discovery re: potential Unicode input limitations on recent versions of Win 10. Hopefully this is at least partially on-topic as your original code focused on an input-only edit box.
Traditionally, Unicode-enabled textboxes in VB6 have been "easy enough" to solve. I think many people have used a CreateWindowsExW solution of some sort, with the added fix (originally suggested by @georgekar, to my knowledge) of subclassing WM_KEYDOWN and caching character codes at module-level. These cached character codes can then be substituted during the WM_CHAR message if VB's message pump garbles the Unicode character codes en route.
But as Jonney discovered, this solution is no longer sufficient. For some reason, certain Win 10 versions (possibly coupled with other criteria - I don't know) may now down-convert Unicode characters to ASCII characters in other situations, even if the legacy setting for "Language for non-Unicode programs" is configured. This is worrisome for a number of reasons, and it's an OS behavior I wouldn't expect to change after so many years of working just fine. Sigh.
For those using a subclassing solution, there's a relatively easy fix. Jonney helped track this down by studying a few different Unicode textbox implementations, and figuring out which ones still work and which ones don't. Krool's was one of the solutions that still works, and we found that he goes to the extra work of manually intercepting WM_IME_CHAR messages, and directly dispatching corresponding WM_CHAR messages via SendMessage (instead of relying on the default handler). When this step is added to a subclassing solution, voila - even on Win 10, the Unicode characters come through unscathed.
I wish I had a better understanding of why this extra step has suddenly become necessary, but at least it's straightforward to solve if you're already working from a subclass-based solution. Unfortunately, I don't know if any of this helps your current project. Possibly not a dealbreaker for certain use-cases, but something to be aware of.
@Tanner. Think your post could help others that are having similar issues as Jonney.
BTW, gotta say hats off to Krool. Gotta wonder why he added that extra step if it wasn't a problem until just recently. Well planned.
Edited: Anyone know if this can be replicated on demand? With all these "unicode-compatible" controls, both commercial & amateur, how do we know which can break & which won't? Do we subclass every unicode edit-control just to be safe? Seems like that's overkill. For example, the DataGrid is built by Microsoft, wonder its textbox (the input mechanism for the grid) is broken. Would be nice if we could determine whether potential failure exists.
Last edited by LaVolpe; Jun 19th, 2017 at 10:02 PM.
Insomnia is just a byproduct of, "It can't be done"
Sorry that I had "hijacked" your thread and I was not aware of it till now. I have now removed my posting in #13 and made the following remark there accordingly:
(Overlooked that although the thread is for an input textbox, it is not intended to be of a control.)
BTW, gotta say hats off to Krool. Gotta wonder why he added that extra step if it wasn't a problem until just recently. Well planned.
These rare input issues actually did show up on certain machines prior to win10. Thanks in part to the large number of (international) people that were testing Krool's controls.
Anyone know if this can be replicated on demand? With all these "unicode-compatible" controls, both commercial & amateur, how do we know which can break & which won't? Do we subclass every unicode edit-control just to be safe? Seems like that's overkill. For example, the DataGrid is built by Microsoft, wonder its textbox (the input mechanism for the grid) is broken. Would be nice if we could determine whether potential failure exists.
For true Unicode support, I believe subclassing *is* required on all edit boxes (and RTBs) tested so far. Like DEX says, Krool's controls have helped turn up a number of edge cases where non-subclassing solutions fail. For example, since at least Vista, certain locales haven't worked correctly with un-subclassed Unicode text box solutions. That's why the "cache char code during WM_KEYDOWN, restore during WM_CHAR" trick became necessary.
Microsoft has discussed some of these problems in the past... this page comes to mind:
Please take this as "for info" / "for reference" / "for feedback" only.
We all know and agree that for a full-blown and sure-win usage, something like the user-control done by krool is required. However, from the keyword "Simple" in the thread title, LaVolpe is just to explore the possibility of having a much simpler approach, e.g. to handle a Unicode input only. It is in this "Simple" spirit that I entered into the discussion, and submitted my light-weight user-control in #13 (which I subsequently removed - see below).
The difference between what LaVolpe's #1 and my light-weight user control is that, the former uses a textbox and code on the spot and the latter uses a textbox and code in a custom control instead. Both don't involve subclassing, manifest or a third party DLL/OCX. Despite that, my posting in #13 is still against the criteria set in #1 (no custom control). As soon as realized it, I had the said #13 removed (see posting #31).
In #24 (prior to #31), I said that "I haven't got a chance to try my Unicode TextBox on Win 10 1607", but now I got a chance to do that, after I got a new PC with Win 10 1709.
Everything remains the same, no subclassing, no manifest, no 3rd party DLL/OCX and no need to set anything in the system, only a textbox and the code -- if you still have my user control, you can verify that. Per the two screenshots below, you can see that my user control accepts Persian/Iran and Chinese (Remarks: I know the meaning of the two Chinese characters, but I have no idea what the Persian means - I got it at random after adding Persian in Google's Language setting. The original intention was to test out whether a program of mine could load a JPG file with a Persian file name, I pasted the copied Persian to replace an English file name, the result proved it could load the JPG file. I then went back to Google's Language setting to remove Persian entry, leaving only English (U.S) entry behind. After that, it occurs to me about this thread, that is how I am here.)
As said earlier, there is basically no difference between what LaVolpe is doing and what my user control is doing. Therefore I come back to "feed" this piece of information, in case LaVolpe is still doing experiments on the subject.
Edited:
The above implies that if my user control can do that, LaVolpe's #1 should be able to do that also, albeit there may be some difference in code lines used. The textbox in the screenshot with a red circle is my user control. The font, font size and color etc settings do not affect the text box entry, they affect the actual text writing on PicureBox when user clicks Proceed button in the Antialiased Text dialog shown.
Last edited by Brenker; Feb 19th, 2018 at 06:51 PM.
I "played" a little bit further. This time I didn't go through Google's Language setting (see my last posting), anyhow I had no way going back to where I had been last time to copy the same text. So this time I just typed "good luck translated in Persian" in Google's Search box. It is not easy to get to a place where I could do Copy this time, because in most cases I couldn't highlight what I saw. Finally I got one somehow.
Shown below are two JPG files. One is a cropped screenshot of my "Antialiased Text" dialog, with Persian text entered in the user control. The other one is a picture I obtained when I clicked Proceed button in the said dialog. The resultant text was dragged to the wanted position on the picture, before saving it to the JPG file.
Last edited by Brenker; Feb 19th, 2018 at 09:33 PM.
I did upload my project, see #34. Later on I removed it when I realized it was against the criteria set by LaVolpe (no user control), see #31.
I thought LaVolpe should know what I am talking about. Before I removed the project LaVolpe run it and commented something. Besides, if LaVolpe no longer has the copy and wants to see it again, he can say so. If LaVolpe doesn't want to pursue further, then things should stop here. It is clear enough that here what I am saying is that his #1 code should be workable, that is all.
Brenker, I don't care if LaVolpe saw your control code.
I also would like to see and maybe use it and express my gratitude. That's exactly what CodeBank intended for.
Actually I did upload the subject project once long time ago, when I was new and under a different name (I might still remember the name but surely I forgot the password). At that time, there was no "Simple" concept (I am afraid even now), immediately some one ruled it out saying it just wouldn't work. Disheartened by that I took it down.
BTW, you might have noticed that often I "fool around" some of your postings, that is because you are the only one I know here who likes to code without engaging a 3rd party DLL/OCX, and still care to cover older Windows systems while coding for a new one, and similar to myself who can handle almost any PNG stuff without even relying on GDIplus.
Reply With Quote
.
Originally Posted by LaVolpe
Possibly not a dealbreaker for certain use-cases, but something to be aware of.