Prev: New form on Main thread.
Next: Pasting text to browser
From: Dee Earley on 19 Jul 2010 07:57
On 19/07/2010 12:47, ralph wrote:
> On Mon, 19 Jul 2010 09:29:35 +0100, Dee Earley
> <dee.earley(a)icode.co.uk> wrote:
>
>> On 18/07/2010 16:44, ralph wrote:
>>> On Sun, 18 Jul 2010 16:40:31 +1000, Leo<ttdhead(a)gmail.com> wrote:
>>>
>>>
>>>>
>>>> I did mean to say a Standard DLL built using VB. I have vbAdvance
>>>> installed which will do the extra stuff for me.
>>>
>>> Ok. Always good to make sure.<g>
>>>
>>> What you do is compensate for the hidden conversion by converting it
>>> first. So your calls will look like this ...
>>
>> Note also that using a type library means it won't do any conversion at all.
>
> There are many advantages to using a Type Library instead of Declare
> directives for Standard DLLs, essentially removing some over-head in
> making the call, but unfortunately this is not one of them.

Yes it is.
I know it does this conversion when calling "Declared" functions, but
for typelib based DLL functions, they are passed straight through as
wide strings.

--
Dee Earley (dee.earley(a)icode.co.uk)
i-Catcher Development Team

iCode Systems

(Replies direct to my email address will be ignored.
Please reply to the group.)
From: Jim Mack on 19 Jul 2010 08:18
ralph wrote:
> Dee Earley wrote:
>>
>> Note also that using a type library means it won't do any
>> conversion at all.
>
> There are many advantages to using a Type Library instead of Declare
> directives for Standard DLLs, essentially removing some over-head in
> making the call, but unfortunately this is not one of them.
>
> The conversion VB does from a VB BSTR to an ANSI BSTR is built into
> the VB VM (Runtime), and always occurs when VB passes a BSTR to an
> external library (Win32 or anything else).

Nope. When you use a TLB for an external library -- even if it's not a
COM DLL -- you can completely specify how arguments are passed. If the
interface says "BSTR" then you get a true Unicode BSTR with no
conversion. If the interface says "LPSTR" then VB will perform the
usual conversions.

In this way, for example, you can provide direct access to the "-W"
versions of Win32 APIs without the caller doing anything special (like
"ByVal StrPtr...").

However, in this case I think it makes no sense. Since it's a DLL _in_
VB, if you call it from VB you'd be crazy not to use the provided COM
interface. And if you call it from a different language, the TLB may
not come into play at all, depending on whether the other language
understands OLE and conforms to those conventions.

--
Jim Mack
Twisted tees at http://www.cafepress.com/2050inc
"We sew confusion"

From: ralph on 19 Jul 2010 10:14
On Mon, 19 Jul 2010 08:18:37 -0400, "Jim Mack" <no-uce-ube(a)mdxi.com>
wrote:


>
>Nope. When you use a TLB for an external library -- even if it's not a
>COM DLL -- you can completely specify how arguments are passed. If the
>interface says "BSTR" then you get a true Unicode BSTR with no
>conversion. If the interface says "LPSTR" then VB will perform the
>usual conversions.
>
>In this way, for example, you can provide direct access to the "-W"
>versions of Win32 APIs without the caller doing anything special (like
>"ByVal StrPtr...").
>

I'll be damn you gentlemen are correct.
The conversion feature appears tied to the Declare Directives.
This is doubly embaressing as I too use a Unicode version of the Win32
Type Library all the time, for exactly that reason, thus should have
known better.
(My only excuse is that it has been years since I visited this issue.
Pretty lame, but I'm sticking to it. <g>)

eg:
Declare Function CharUpperA Lib "user32" (ByVal lpsz As String) _
_As Long
Declare Function CharUpperW Lib "user32" (ByVal lpsz As String)
_ As Long
' defined in Type Library:
' LPSTR WINAPI CharUpper(LPWSTR lpsz);
' entry("CharUpperW"),

Dim s As String
s = "string"
' works as expected on Win98 and WinNT
CharUpperA s
Debug.Print s
' fails on WinNT
CharUpperW s
Debug.Print s
' works as expected
CharUpper s
Debug.Print s

However, I'm having mixed results when creating a TypeLib for a VB
Standard DLL. Likely holding my mouth wrong.

I'll keep playing, just wanted to post my admission.

>However, in this case I think it makes no sense. Since it's a DLL _in_
>VB, if you call it from VB you'd be crazy not to use the provided COM
>interface. And if you call it from a different language, the TLB may
>not come into play at all, depending on whether the other language
>understands OLE and conforms to those conventions.

I agree.
COM is Unicode even on Win9x boxes.

-ralph
From: ralph on 19 Jul 2010 10:15
On Mon, 19 Jul 2010 12:57:46 +0100, Dee Earley
<dee.earley(a)icode.co.uk> wrote:

>On 19/07/2010 12:47, ralph wrote:
>> On Mon, 19 Jul 2010 09:29:35 +0100, Dee Earley
>> <dee.earley(a)icode.co.uk> wrote:
>>
>>> On 18/07/2010 16:44, ralph wrote:
>>>> On Sun, 18 Jul 2010 16:40:31 +1000, Leo<ttdhead(a)gmail.com> wrote:
>>>>
>>>>
>>>>>
>>>>> I did mean to say a Standard DLL built using VB. I have vbAdvance
>>>>> installed which will do the extra stuff for me.
>>>>
>>>> Ok. Always good to make sure.<g>
>>>>
>>>> What you do is compensate for the hidden conversion by converting it
>>>> first. So your calls will look like this ...
>>>
>>> Note also that using a type library means it won't do any conversion at all.
>>
>> There are many advantages to using a Type Library instead of Declare
>> directives for Standard DLLs, essentially removing some over-head in
>> making the call, but unfortunately this is not one of them.
>
>Yes it is.
>I know it does this conversion when calling "Declared" functions, but
>for typelib based DLL functions, they are passed straight through as
>wide strings.

I stand corrected.
See below

-ralph
From: se on 19 Jul 2010 11:59

"ralph" <nt_consulting64(a)yahoo.net> skrev i meddelelsen
news:h8m846to35dsss5tb3qherste5q70g5c70(a)4ax.com...
> On Mon, 19 Jul 2010 08:18:37 -0400, "Jim Mack" <no-uce-ube(a)mdxi.com>
> wrote:
>
>
> I'll be damn you gentlemen are correct.
> The conversion feature appears tied to the Declare Directives.
> This is doubly embaressing as I too use a Unicode version of the Win32
> Type Library all the time, for exactly that reason, thus should have
> known better.
> (My only excuse is that it has been years since I visited this issue.
> Pretty lame, but I'm sticking to it. <g>)
>
> -ralph


>> What IS a surprise to me is that you are somehow expecting ANY string
>> to number converstion process to automatically know what you want it
>> to do! (Been watching too much TV I think.)
>>
>>
>> -ralph

Whom ?.


First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: New form on Main thread.
Next: Pasting text to browser