I'm curious.

By accident, my particular API viewer was generating W versions of APIs I
commonly use.  I only caught it because the APIs were failing.

Specifically I was using FindWindowEx.

The declare for the W was exactly the same as the A, the difference being
the Alias.  So why would it fail?  I'm on XP SP3, which I assumed supported
unicode apis.

And when I say fail, the return value was 0, versus the desired window
handle.

Show quote Hide quote Most likely because VB converted the Unicode string before calling the
function so the buffer it got was essentially garbage.  You can call the
unicode versions but you have to either pass a byte array or use StrPtr or
some such method to side-step the default conversions.

Kevin Provance pretended :
Well duh... if it was exactly the same as the A version then it was
wrong.  If you are going to use the unicode version, declare the
lpszClass and lpszWindow parameters as Longs and use StrPtr to pass the
address of the string variables... Alternately, use a typelibe declared
version.

Alternately? Why would he want to keep swapping between the two different
methods? Why not simply use StrPtr or alternatively use a typlelib version?
Surely that would make more sense than to keep swapping around?

Mike

Mike Williams pretended :
Show quoteHide quoteLOL... I  meant alternatively...  love those typos though :)

Yes, I know you meant alternatively. Common sense told me that. In fact that
was the point I was rather subtly making. Common sense. People who always
take things literally, as I deliberately did then for illustration purposes,
are generally not very smart, such as people who insist, as you have
yourself done many times in the past, that the
microsoft.public.vb.general.discussion group is for all versions of VB,
including the imposter, simply because the group has "vb" in its name.

Common sense, which is what some people around here seem to be short of,
would tell any sensible person that Microsoft, on whose server the group
exists, definitely intended that group to be used for versions of VB up to
version 6 (in other words, Classic VB) when they purposely and deliberately
created a brand new and different newsgroup for their brand new and
different dotnet product and when they ran it concurrently with the VB6
group. Common sense tells you that. If you take things literally, even when
common sense tells you otherwise, then you are not very smart.

Mike

on 8/3/2010, Mike Williams supposed :
Show quoteHide quoteNo... I have not insisted that... I insist that
comp.lang.basic.visual.misc is for all versions of VB - because of it's
charter.  Get it right.

But you /have/ been infesting the microsoft.public.vb.general.discussion
group with your evangelistic dotnet rubbish for quite some time, which
amounts to much the same thing. Your lack of common sense is showing again.

So, taking that in the context in which you said it, I can logically assume
that you do agree that the microsoft.public.dotnet.languages.vb group is
/not/ for the VB.Nxt imposter. Well, at least that's something. That's one
troll out of the way in the microsoft.public.dotnet.languages.vb group.
Thank you for that. It is a good start. Now we can forget your own
evangelistic dotnet outpourings on this group because you will not be
spewing them any more. That's good. Just a few more trolls to go and we will
be well on the way to having a group here that is entirely free of dotnet
trolls. Thank you once again.

Now I think I shall do what I had already mentioned, and leave the
comp.lang.basic.visual.misc group to yourself and to anyone else who wishes
to use it (unless and until its charter is changed of course) and I shall
post solely on this microsoft.public.dotnet.languages.vb group that you have
effectively agreed to stop trolling.

Once again, let me thank you for agreeing to stop trolling this group.

Mike

Actually I mentioned the wrong group there a number of times due to a copy
and paste error. But then of course common sense would have told you what I
actually meant. However, for the record, here it all is again, this time
with the correct group names:

But you /have/ been infesting the microsoft.public.vb.general.discussion
group with your evangelistic dotnet rubbish for quite some time, which
amounts to much the same thing. Your lack of common sense is showing again.

So, taking that in the context in which you said it, I can logically assume
that you do agree that the microsoft.public.vb.general.discussion group is
/not/ for the VB.Nxt imposter. Well, at least that's something. That's one
troll out of the way in the microsoft.public.vb.general.discussion group.
Thank you for that. It is a good start. Now we can forget your own
evangelistic dotnet outpourings in this group because you will not be
spewing them any more. That's good. Just a few more trolls to go and we will
be well on the way to having a group here that is entirely free of dotnet
trolls. Thank you once again.

Now I think I shall do what I had already mentioned, and leave the
comp.lang.basic.visual.misc group to yourself and to anyone else who wishes
to use it (unless and until its charter is changed of course) and I shall
post solely on this microsoft.public.vb.general.discussion group that you
have effectively agreed to stop trolling.

Once again, let me thank you for agreeing to stop trolling this group.

Mike

Mike Williams expressed precisely :
Show quoteHide quoteLOL... Mike I have not evangalized anything.  I have argued and
discussed .net here - no doubt.  But, I challenge you to find one
thread that I started here.  I have only responded to threads already
in progress and only to the remarks of .notters.

Anyway, it seems to me you are the one that's the troll now...

Well that's the problem. I really am surprised that you cannot (or will not)
see it! I accused you of insisting that the
microsoft.public.vb.general.discussion group is for all versions of VB,
including the imposter, and in reply you said:

       "No... I have not insisted that... I insist that
        comp.lang.basic.visual.misc is for all versions of
        VB - because of it's charter.  Get it right."

That statement of yours clearly implies, in fact the implication is
inescapable, that you do NOT believe that
microsoft.public.vb.general.discussion group is for all versions of VB,
including the imposter. And yet here you are, hours later, freely admitting
that you have "argued and discussed .net here - no doubt"!!! If that is not
the mark of a troll then nothing is!

Mike

Mike Williams used his keyboard to write :
Show quoteHide quoteI do not deny that I have been involved in discussions.  But, if I was
here to troll - wouldn't I be the one starting them?

I do not start those discussions - if you don't discuss .net here, i
won't.  simple as that.  comp.lang.basic.*  that's a different kettle
of fish entirely.

No. That is not a requirement. Trolls are happy to troll whether they
started the thread or not.

Mike

After serious thinking Mike Williams wrote :
LOL... Then you and kev are probably the biggest trolls here.

Trollish behavior right there, yet again dragging me into his sick
obsessions where I have not even weighed in.  If that isn't trollish
behaviour, I don't know what is.

Get over me Skelton.  I can't and won't give you what you want.  I'm sorry
Rob left this group, but I will not fill that void he left in your life.  I
prefer women.  <g>

Well that conclusion you have just drawn does not even make sense. No sense
at all. It is not a conclusion that can logically be drawn from the
statement you have drawn it from. It is a nonsensical conclusion. However,
nonsense seems to be the stock in trade of dotnet trolls such as yourself,
so it is not unexpected.

Mike

On 03/08/2010 23:58, Mike Williams wrote:
Show quoteHide quoteStop hijacking unrelated threads, you're going out of your way to stir
up trouble now.
(Isn't that the definition of a troll?)

Kevin Provance pretended :
And for some code...

Option Explicit

Private Declare Function FindWindowEx Lib "user32" Alias
"FindWindowExW" ( _
    ByVal hwndParent As Long, _
    ByVal hwndChildAfter As Long, _
    ByVal lpszClass As Long, _
    ByVal lpszWindow As Long) As Long



Private Sub Command1_Click()
    Dim calc As String
    calc = "Calculator"
    MsgBox FindWindowEx(0, 0, 0, StrPtr(calc))
End Sub

Show quote Hide quote In your case, the W version was seeing an ANSI string and was looking for
dual zero as a null terminator. So it probably interpreted it as Chinese
string of unknown length :-)

Personally, I prefer not using aliases with W functions, and use them as
is(FindWindowExW). This makes the code compatible of whatever source code
library I have and most code samples. With W functions, you always need to
pass your strings as "ByVal StrPtr(s)", and "ByVal 0&" or vbNullString to
pass null string.

Nobody wrote:

But, wouldn't this cause an error if the code is executed in a
Win95/98/Me machine? Because these systems do not support Unicode (W),
but ANSI (A) functions. What I have been doing lately is checking for
the high-order bit from the GetVersion() function. Only Windows NT,
2000, and above have this bit set to 0. I use that to determine whether
I call the "A" or the "W" version. Of course that is to write code that
is compatible with old Windows (95/98/Me). Although, I'm wondering if
all that is worth the trouble, since I personally do not know anyone who
still uses those old OSs.

That's what I've been doing lately and it has always worked, but that
seems to apply only to "W" functions that have those parameters as
inputs. What do we do for those string parameters that are outputs?

Thanks! -Satchmo

Yes, but you need to check the OS version before using a function that came
after Windows 95, or the minimum OS that you are trying to support. VB6 and
all its OCX's require Windows 95 minimum, so if you use a function in later
OS, try to document the minimum OS to use, perhaps in top of the source file
that it appears in, or in project documentation.

I think you can use the "Microsoft Layer for Unicode", but for each function
that it supports, you have to replace the DLL name in the Declare from
something like "Kernel32" to "UnicoWS.dll", and put "UnicoWS.dll" in the
same folder as the EXE. It's actually easier to use this DLL in VB rather
than C++. C++ developer have to do things to fool the linker so they can use
that DLL instead of Kernel32.dll, User32.dll, etc.

When using "UnicoWS.dll", you always call the W function with the same name
in "UnicoWS.dll" and use "ByVal StrPtr(s)", or "ByVal 0&" to pass the
parameters, and in turn, "UnicoWS.dll" would call the OS version of the
function directly(In NT), or after doing the necessary Unicode to ANSI
conversion when running under Windows 9x.

Same syntax for input and output.

Nobody wrote:
Show quoteHide quoteNobody, this is great news! Thanks for the info! I did not know about
this. I searched MSDN and found this great article about MSLU here:

http://msdn.microsoft.com/en-us/goglobal/bb688166.aspx
http://msdn.microsoft.com/en-us/magazine/cc301794.aspx

As you said, with MSLU I can just write a single Unicode version of my
application and have it run properly on all platforms! The best of all:
using it won't slow down the app on Windows NT/2000/XP, because it will
not load the MSLU unless the app runs on a Win95/98/ME machine!

It will always load the MSLU, which is just a simple wrapper DLL, about 233
KB, which is not a big deal, but under NT, there is no need to do ANSI to
Unicode conversion, so there is very small overhead in terms of speed when
running under NT.

This is an interesting discussion, but I wonder how
much it matters. Are there cases where the difference
in speed between unicode calls and VBs normal ANSI
conversions is actually notable? I'd be curious to see
a demo if anyone has created such a thing.


Show quoteHide quote

On Thu, 12 Aug 2010 09:51:48 -0400, "Mayayana"
<mayayana@invalid.nospam> wrote:


Show quoteHide quote"How much does it matter" is a common question and just as commonly
has a range of answers - all dependent on the comfort level of the
programmer, the service requirements of an application, or the system
as a whole.

There is the simple fact that anything that adds 'clicks' to a running
process has a scalar impact on performance, thus it always "matters".
"Noticeably" however, always depends on scope and frequency.

For example, the programming of a text editor.
It spends most of its total time waiting for keystrokes. The actual
time to process a keystroke is often but a fraction of the time the
program takes to process it, making less than optimal routines
"unnoticeable' on a low load desktop. But every click added is one
less click available to a system to do something else. So running the
same program on a desktop with a ton of running background processes,
or with a hundred users from a terminal server - wasted clicks may
become quite noticeable.

Whenever the subject of performance or optimization comes up I'm
reminded to two adages - "It doesn't matter how fast it is, if it
doesn't work", and "If it has to work, it doesn't matter how long it
takes".

The OP due to his requirements has to adopt the latter.

-ralph

Nobody wrote:
I just realized the following scenario and I'm worried now: what if the
app uses controls on forms. MSLU will have nothing to with their
operation right? Are Microsoft's standard controls (Common Controls 6.0
SP6) Unicode-ready? Can they display Unicode text on forms? And what if
they make their own internal calls to Unicode functions "W" and "A"
versions, how would they accomplish the same distinction than MSLU? I'm
just trying to understand functionality and limitations. I'm quite
confused now.

On Thu, 12 Aug 2010 22:41:55 -0400, Nando
<hight***@att.net.no.to.sp.am> wrote:

Show quoteHide quoteAnd well you should be. <g>

I normally don't respond to "control questions" simply because I use
3rd party libraries, or create my own, so I'm mildly biased against
VB's inherent controls, and you can take what follows with a few
grains of salt. <g>]

In general VB Common Controls are not fully Unicode complaint.
Occasionally in some cases, for some languages (encoding), and a bit
of massage they can serve. It all depends on the control, the
encoding, and what you are doing.

Frankly, if full Internationalization (I18n) is your goal and your
budget can stand it, seek out more compliant controls. There are a
number of products available. Some are full suites, others specific
controls. Some are priced astronomically, some moderate, a few are
freeware.

Most come with additional features that make their price well worth it
even if Uncode wasn't a major requirement.

-ralph

ralph wrote:
Show quoteHide quoteI'm new to internalization so any feedback is useful and appreciated.

"Full internationalization"? (Hmm, I'll get up to speed with the
terminology after I receive and read "Internationalization with Visual
Basic" by Michael Kaplan, which was hard to find (out-of-print) but
someone recommended to me earlier).

Very interesting stuff. I'm doing internationalization for the first
time. My apps are tiny :-) Although most of my intentions are more
oriented to learn this stuff. Currently, I do not have any ambitions of
creating an app in all languages. LOL! But all these facts are fascinating.

Obviously not easy, but I'm curious: Has Microsoft made
internationalization simpler and more transparent with the latest
development tools?

Thanks Ralph!

On Fri, 13 Aug 2010 23:28:44 -0400, Nando
<hight***@att.net.no.to.sp.am> wrote:

LOL!  I'm not falling into that trap.

It is sufficient to say that all development tools produced in the
last 15+ years are more "I18N Aware" if nothing else.

It should be noted (and as that book clearly points out) that
"internationalizing" an application involves far more than simply
providing translated strings, or alternative currency and date
formats.

In the early ninties I was working for a large corporation that was
going international and in-charge of providing client software for
multiple locales. We were predominately a C/Unix shop.

I, like most developers at the time, approached the problem by
designing one-size-fits-all fully aware front-ends. With custom
re-drawn dialogs and forms - to manage different lengths and sizes,
redirected custom controls - to manage formats, and tons of swap-out
resource files - to manage everything else.

The result was a fine example of the C/SDK programmer's art. They were
also bloated, slow, and a maintenence nightmare. The latter came not
from the constant surfacing of bugs, but from what might be called
purely social and cultural problems. [Appreciate that this was also
before computer idioms had infiltrated other countries.]

We were constantly replacing obscene, insulting, or nonsensical icons
and phrases, and it often wasn't just a particular word, gesture, or
digit placement that was a problem, but the very color of a particular
garment or object could lead to chuckles.

The solution (and a very unpopular one with my fellow associates at
the time*) was Visual Basic (VB2-VB4). I found that I could bring in a
group of associates from any locale, and teach them the basics of
creating dialogs and forms in VB in less than a week, then turn them
over to a subject matter expert and an interpreter, and forget it. A
tad slow in the beginning but near the end we could produce a new
suite of several dozen applications with full localized documentation
for any locale in less than two months. Luckily we had enforced a
strict separation of Presentation from the beginning, so swapping out
front-ends became trivial.

So perhaps the least of all I18N development tools, became our primary
I18N tool. <g>

-ralph
[*as a C programmer myself, I wasn't too thrilled at selling this idea
to management, but it was obvious that what we were doing wasn't
working. There was also a very large and very vocal anti-Windows
segment. (I used to cover my VB books with brown paper so no one at
work would notice what I was reading. <g>)

They wanted a pure client-server solution through terminal boxes. Not
a bad idea. But it was obvious even back then that Windows was going
to be the Users choice. There were going to be Window boxes in those
offices whether the gurus liked it or not, and sooner or later we
would be mimicking or supporting utilities on those boxes. Second,
Windows also provided a ton of secondary productivity tools - I had no
interest in going into the word processing, ad hoc data management,
spreadsheet, calendar, scheduling, or email business. Plus trying to
decide on which 'Unix' or adding yet another variety of 'ports' to the
mix.

For a final laugh. I picked VB over the many other "visual designers"
of the day, not only because of its ease of use and seemless
integration with our C/C++ code, but because Microsoft had an
excellent reputation of always being backward-compatible. Thus our
code-base would always be safe. <bg>
]

ralph wrote:
No trap :)) honestly

Show quoteHide quoteWow! That's some serious I18N experience!

LOL!

That's interesting Ralph. The same happened to me (hmm.. how many others
alike I'm wondering now). Years ago, when the Visual Studio 6
development kit was the hottest thing, I abandoned C and my other
programming skills in order to favor the large adoption of Microsoft
products for the large company I was working for. After trying so many
other development platforms, I adopted Visual Basic because it was
simply (and without a doubt) more efficient:

Efficient: "a. Acting or producing effectively with a minimum of waste,
expense, or unnecessary effort. b. Exhibiting a high ratio of output to
input." (The American Heritage® Dictionary of the English Language)

Visual Basic was not only very efficient (compared to the other tools),
but it was *everywhere* and it was highly implementable (is that word?).
All Microsoft's products (Word, Excel, PowerPoint, Access, Outlook, ..)
could be customized and expanded with Visual Basic (VBA). All the
development teams in my company got tons of time-sensitive solutions
done all the time (fulfillment systems operations across the company's
business units).

However, it never crossed my mind Microsoft would turn out to commit
homicide against its own child, dismantling the VB work after so many
years of pushing it to include it in all their applications, just to
favor a continuous and endless pop-ups of sdk platforms and business
solutions. If I knew then what Microsoft was going to do ....

On 14/08/2010 04:28, Nando wrote:
Yes :)

When I last looked at it a year or so ago, you would set any string
properties you wanted, then could change the "Locale" property then just
change the strings as required.

I don't have anything concrete to hand though.

As for i18n in VB6, I use numeric string resources and the Win32
resource file string tables and a function that just loads all the
strings it can find.
If needed, I can then do locale specific changes in code (Most stuff
resizes to fit automatically).

Show quote Hide quote Correct.

No, all controls that came with VB are ANSI.

No.

They don't go through MSLU, and you can't "make" them. The only calls that
go through MSLU are the ones that you directly make.

The following site offers free Unicode controls, but I haven't used them:

http://www.timosoft-software.de/

Nobody wrote:
Oh, I see. So what languages should I expect to be supported by Windows
Common Controls? Or perhaps I should re-phrase the question as: With
what kind of languages I will be *safe*?

On 13/08/2010 09:07, Nando wrote:
Show quoteHide quoteAnything that matches the "codepage for non Unicode applications"
setting in Windows.

I've happily used my app localised to Japanese with (little) problem as
long as that codepage is set correctly to Japanese.

Dee Earley wrote:
Show quoteHide quoteJapanese? Really? I thought that was Unicode. I'm confused.

On 14/08/2010 04:23, Nando wrote:
Show quoteHide quoteA language isn't Unicode, it can just be represented by various
different encodings (including Unicode or ANSI with a codepage).
As the VB controls don't really do Unicode, they convert back to Ansi
chars using the codepage setting.

I just treat everything internally as a full wide character and hope
that the codepage is set correctly.

Nando wrote:
Show quoteHide quoteThose languages that use our (latin?) alphabet - that is, Western
European languages.

Jason Keats wrote:
Show quoteHide quoteI see. According to Wikipedia:

<http://en.wikipedia.org/wiki/Western_Latin_character_sets_(computing)>

the list of "Western European languages" (or languages that use the
Latin alphabet) is:

Italian, Spanish, Portuguese, French, German, Dutch, English, Danish,
Swedish, Norwegian, and Icelandic.

So I guess then those will be the languages I'll be limited by if I
decide to internationalize using MS VB6 Common Controls.

Show quote Hide quote Actually all languages are safe except those that require Right-to-Left
reading order, such as Arabic and Hebrew, and languages that use Multi Byte
Character Set(MBCS), such as in the far east. I think you can support these
languages with extra work, or perhaps they work fine, I am not sure.

You also may want to use functions that take localization into account, such
as CStr(), CLng(), etc. when interacting with UI controls, or saving/reading
from files, instead of Str(), Val(), etc. However, using Str/Val is fine.
One thing that you need to be aware off is that CLng and similar functions
generate run time error 13(Type Mismatch) if you give them empty string, or
string containing text other than numbers, while Val() returns 0 without
errors, so make sure that the input is valid, see IsNumeric Function.

http://en.wikipedia.org/wiki/Multi-byte_character_set

Nobody wrote:
Show quoteHide quoteOh, I see I'm understanding. So MS Common Controls do not support
Unicode and won't display Unicode characters, however they will display
DBCS characters (ANSI), so Japanese, Korean, and Hindi. Oh boy...
everythime I got more questions (altough I'm less confused now) I can't
wait for that book arrive.

Thanks Nobody! Quite interesting that I have been using all these
functions all these years and haven't been aware of their localization
features, since I didn't care because I was only programming for
in-house production systems and never internationally. That information
is very helpful. I have also been doing good reading at MSDN about VB6
International Issues here:

<http://msdn.microsoft.com/en-us/library/aa242115(VS.60).aspx>

Quite interesting is Microsoft's zigzags using ANSI (one-byte and DBCS)
instead of just using Unicode.

- Windows 95/98/Me (1995/1998/2000) [ANSI]
- Windows NT4 (1996) [Unicode]
- Visual Basic (1998) [ANSI + Unicode internally only]
- VB controls (1998) [ANSI]
- Windows 2000/XP/2003/XP/Vista/7 (2000/2001/2003/...) [Unicode]
- .Net [Unicode]

Sounds like dyskinesia, doesn't it? I'm glad they finally settle down.

Impressive use of the word.  Had to toss that in there.  <g>

On Sat, 14 Aug 2010 22:39:21 -0400, Nando
<hight***@att.net.no.to.sp.am> wrote:

It wasn't just MS. Everyone else was twitching as well. Wait till you
find out that there is "Unicode", and then again there is "Unicode",
and ALL your tools had to match. <g>

-ralph

Nobody wrote:
Thanks!

Get Selected Path From Explorer
How to save a picturebox's image to a .PNG file? (VB6)
RegClean
create user on AD server
the vb letter
Problem automating page in IE 8
Intermittent problem in data transfer MSAccess to Oracle using VB
Form Z order across the divide
System Timer Callback?
Are PDB files used by VB6