Re: Unicode Button in VB6

Sorry, I know I don't really look very organised with all my posts here and
there, but here is what I saw about this fm20.dll:
I can't just include it in my installation routine for an external
redistribution.
(http://vbnet.mvps.org/index.html?code/faq/redistribution.htm)
However, I am allowed to Install the Microsoft ActiveX Control Pad with my
application (if I see that Fm20.dll isn't in the system folder for example),
and that would solve the problem.
I tried it on a fresh installed W98 and it worked fine.

Is this correct ?

Thanks!
Jérémie

"Jérémie Gent" <jer_kjr@xxxxxxxxxxx> wrote in message
news:OY1s%23cVYGHA.1192@xxxxxxxxxxxxxxxxxxxxxxx
Thanks so much Thorsten!
That's really something fantastic to have so complete and described
answers, thanks a lot for the time you took for me!
Thanks also to you Timo.

Hmmmm ..... As far as I can see, I've put my feet into something much more
complicated than I thought at the first time.
My problem is that the 'problematic' languages are a kindof lastminute
wish of my client, and the application has to work fine by the end of the
week (and I'm busy on other things too, so I won't have much time during
the week either). So going into this 'deep' programmation would maybe not
be the solution for this time. However, it'll be very usefull for future
projects!
That's why I come with a last and quick (I hope) question: Why shouldn't I
use Forms 2 ? I tried them and it seems to work fine for me, but does that
mean that the user needs to have Office installed on his computer (license
problem) ? If yes, it's no solution for me ... If no, what are the issues
?

Thanks again!
Thorsten: yes I live in Freiburg as well, and unfortunately, today's
weather isn't that great either, although I managed to go for a short
mountainbike ride with my dog this morning, up to the roßkopf, if you know
... Maybe tomorrow, we'll see the sun ... ?


"Thorsten Albers" <albersRE@xxxxxxxxxxxxxxxxxxx> wrote in message
news:01c660e4$c5a0d660$d052f8d9@xxxxxxxxxxx
Jérémie Gent <jer_kjr@xxxxxxxxxxx> schrieb im Beitrag
<uvdV92KYGHA.5012@xxxxxxxxxxxxxxxxxxxx>...
By the way, I will need to set Unicode caption not only for
Commandbuttons,
but also for labels and listboxes (and control arrays of that kind), but
that would be the next step ...
Let's start with the begining ... ;-)

Answering here all you three postings at once:

First of all: As you told Timo your application shall run on Windows 98
(SE) as well. So forget about the "W" version calls in your code and use
the "A" versions instead. Window 9x supports Unicode only in a very
limited
way. Either Windows 9x doesn't provide the "W" versions of the functions
at
all for which there is a "W" version on Windows NT/XP. Or the respective
"W" version is implemented only as a dummy function which returns
ERROR_NOT_SUPPORTED or the like. For only very few functions there is a
"W"
version on Windows 9x available too; as far as I remember these are the
following functions:

TextOutW
ExtTextOutW
GetTextExtentPointW
GetCharWidthW
GetTextExtentPoint32W
GetTextExtentExPointW

Maybe there are a few other functions with "W" versions.

Secondly: Forget about using WM_SETTEXT or something like that to force a
control to display Unicode text, it is not possible. Subclassing
WM_SETTEXT
isn't all of it.

Any window on Windows is created from a window class. If the window class
doesn't support Unicode it can't handle Unicode strings, it internally
uses
only the ANSI versions of Windows API functions. Even if you could set
the
text string of the window to a Unicode string the control would never be
able to display this Unicode string as Unicode text because it e.g. uses
TextOutA() to print the string instead of TextOutW().

What you have to do is to catch all window messages that are send by
Windows to the subclassed window to redraw the window text, prevent the
original window procedure from receiving and processing these messages
(so
that it will never draw the text), and process them in you own window
procedure. A rough sketch of what you have to do:

Public Function MyWindowProc(...) As Long
Dim hDC as long, PS As PAINTSTRUCT

If lMessage = WM_PAINT Then

hDC = BeginPaint(hWnd, PS)

Call TextOutW(hDC, 0, 0, ByVal StrPtr(MyButtonCaption),
Len(MyButtonCaption))

Call EndPaint(hWnd, PS)

Else
MyWindowProc& = CallWindowProc(pfnWindowProcPrev, ...)
End If

End Function

Here the original window procedure (pfnWindowProcPrev) never will recieve
the message WM_PAINT and therefore never will process it and draw the
button caption. This is done instead by MyWindowProc() which uses the "W"
version of TextOut() to draw the caption.

Unfortunately it might be possible that WM_PAINT is not the only message
that has to be captured and hidden from the original window procedure.
What
has to be done depends on the subclassed window.

This was on painting. Additionally there is the problem of storing the
Unicode text which shall be the control text. It is very difficult to let
the subclassed control do this for you, because the control can't be
forced
to the use of Unicode text; the VB standard controls even don't know what
Unicode is. Instead you should store the Unicode text in your application
separately in a VB string variable. Inter alia this is a good reason for
using a VB user control when subclassing VB standard controls.

By the way, I will need to set Unicode caption not only for
Commandbuttons,
but also for labels and listboxes (and control arrays of that kind), but
that would be the next step ...

The best advise I can give you for this: Forget about it. The work that
is
to be done to subclass the VB standard control completely so that it
displays Unicode text properly isn't worth the effort.
Instead build your own user controls which are providing the same
functionality like the VB standard controls but don't use them. It is not
as difficult as it seems to be. Especially a button and a label are
relatively simple controls which can be build out of a user control, not
too many lines of code, and the Windows API function TextOutW().

With a list box control it is a bit more difficult. There are two good
approoaches to it:

a) Code the list box completely in VB, use the user control window as the
list box window, and use e.g. TextOutW() to draw the text. The obvious
disadvantage is that you will have to do a lot of coding. The obvious
advantage is that you can equip (maybe instantly or maybe in the future)
your list box with features not provided by the VB standard control or
the
Windows list box window class, and that you can break the 32.767 item
limit
of the VB list box and the Windows list box class.

b) Take a user control.

Use the Initialize event of the user control to create a window of the
Windows list box window class (hWnd = CreateWindow("ListBox", ...); the
list box window has to be created with the LBS_OWNERDRAWFIXED or the
LBS_OWNERDRAWVARIABLE but not with the LBS_HASSTRINGS style.
After you have created the window subclass it as has been discussed
before.

Now you can set/retrieve the list box properties by sending LB_* messages
with SendMessage(). Your (subclass) window procedure will recieve the
WM_DRAWITEM message any time a list box item has to be redrawn which
enables you to draw the item text with e.g. TextOutW(). Store the text of
the list box items in e.g. a string array kept by the user control.

Use the Terminate event of the user control to destroy the created window
but only after you have 'unsubclassed' the window.

There is a good example for b) on www.vbaccelerator.com (unfortunately I
can't provide you with the complete link, you will have to search the
site). b) also is what the VB standard list box control does.

Jérémie
PS Thorsten: I hope the weather will be better tomorrow in Freiburg,
it's

kindof bad for an Easter week-end, oder ?

How do you know? Are you living in Colmar, Mulhouse, or Bale? Yesterday
indeed it was very bad here at Freiburg (and today (saturday) too). But
for
me and my friends standing on top of the "Kaiserstuhl" yesterday it was
possible to see that while it was raining in Freiburg there was sunny
wheather in the Alsace. We have been very envious... :-(

Just started google and saw that you are living in Freiburg as well...

--
----------------------------------------------------------------------
THORSTEN ALBERS Universität Freiburg
albers@
uni-freiburg.de
----------------------------------------------------------------------





.