AnsweredAssumed Answered

vrf AW: Vee-Excel Despair

Question asked by VRFuser on Jun 2, 2004
> Sometimes it is a problem of a localized version of Excel.
> In my case it is german, and therefore it is Tabelle1 instead of
> Sheet1....for example.

And here Detlef deftly (sorry, couldn't resist touches on the best, IMO
the *only*, argument in favor of *anti self-documenting* code.

Most notably in enums, we have labels for all kinds of values. I'm one to
always suggest using the label instead of the value. But that only makes
sense in one particular language. English usually.

Long ago (must have been 10 years now) there was a big push to get Windows
programmers to internationalize prompts, and the way to do so was the string
table. Instead of placing fixed strings in the code segment, strings are
referenced by number in the data segment and applications were expected to
use LoadString to retrieve these UNICODE strings so they could be displayed
in any language. The idea is completed by offloading the string table in a
resource only dll that can be conditionally compiled for any language, or
just include all the languages you like in different string tables where
equivalent strings have the same number.

Well that works fine for compilers but the situation is a lot different for
interpreters. There is no string table as a low level concept and as far as
I know one has never been devised. As far as COM enums go (and, for that
matter, Properties), one could devise a new enum type that contains multiple
labels per value. Each label would be one particular language. Or one could
have one enum value table and multiple label tables which could be switched
depending on the locale of the computer the software was running on.
Properties would follow the same scheme. Either multiple labels per property
or multiple tables.

Any way you go about it though, storage requirements shoot up and efficiency
takes a hit. No matter what you do, there's always going to be multiple
dereferencing involved. Not that that's an expensive operation, but when you
start talking about dereferencing a table that's then searched only to then
dereference a value, then put that inside a loop that executes 10,000 times
the picture gets pretty dismal.

Then there's COM method invocations. Again, for a compiler it's no big deal.
A method invocation is simply a call to a function who's address is some
offset into a table (a vtable actually) pointed to by an "object pointer" -
the address of the vtable. The offset is labeled, but it's in source code.
The compiler takes care of looking it up. Again, an interpreter is a lot
different. Script languages like that in VEE and VBS and JScript rely on
type information in the object itself to resolve the method name. A method
invocation from a script involves a whole slew of operations before ever the
call is made via IDispatch::Invoke, which by the way is done with a number -
not a label! One has to use ITypeInfo::GetIDsOfNames to find the ID of the
method that matches the label.

Surprisingly enough, one parameter of Invoke is an lcid - a locale id that
allows the local interpretation of parameters, but not the base method name
label itself. And so method invocation runs into the exact same problem.

I'm still learning about the CLR and .NET, but as far as I can see
absolutely no effort whatsoever was expended on this issue. No provision at
all is made for alternative labels for anything in any namespace.

In short, internationalization *requires* a compiler. The tools necessary
simply don't exist at the interpreter level. For all practical purposes
anyway. You can certainly build a string table with an interpreter (well you
can with VEE anyway), and you can build all the tools necessary and come up
with an extended COM or .NET scheme that allows source code interpretation
in different languages, but that's an uber-task by any standard and the
execution time of such a system would be simply unacceptable.

It's kind of like building a COM object with VEE. Pure VEE. No additives, no
C#, no toolkit. Sure it can be done but it's insane!

And for the same reasons - unfortunately - any excursion into DDE or COM or
.NET basically rules out source code internationalization. It's Sheet1 in
English and it's Tabelle1 in German. It's stuck that way. Unless you check
what language is the default at run time (so you can execute different code
with the appropriate names), names will cause problems.

I wonder if Greg came up with any clever ways around this with vxl?

You are currently subscribed to vrf as:
To subscribe send a blank email to "".
To unsubscribe send a blank email to "".
To send messages to this mailing list,  email "". 
If you need help with the mailing list send a message to "".