I am writing me a com dll and to be sure i am asking if the methods should accept unicode strings or ansi code.
To my knowledge it should handle unicode strings.
I am currently converting every parameter internally to ansicode, outgoing strings i convert to unicode.
I wonder what happens if i specify this interface as dual?
The idea is that this dll works for any language and not only for PB users.
String parameters must be unicode. PB and C++ can use ansi strings with COM, but automation languages don't.
Will the dual option conflict with my internal unicode to ansicode conversion?
I can try of course.
What you do internally is your business.
I'm interested in Unicode support for the OxygenBasic compiler. And I wondered how far it should go. Automatic type conversion when Functions with string parameters are called. This is an obvious one, but should this facility also be extended to all string manipulation functions, or perhaps concatenating strings of mixed type?
Another question: what is the best notation to use for unicode string literals (quoted strings I mean).
Charles
Here is what i have tested, for some reason PB seems to understand UNI and ANSI bstrings when passed to the dispatch interface.
Odd is the last call in this example which appends the strings not with a CRLF but with a ?
Function PBMain
Local d As Dispatch
Local vIn As Variant
Local vOut As Variant
Local i As Interface1
i = Class "Class1"
d = i
? ACode$( i.TestUNI( UCode$( "Direct UNI" ) ) )
? i.TestANSI( "Direct ANSI" )
vIn ="Dispatch UNI"
Object Call d.TestUNI( vIn ) To vOut
? Variant$( vOut )
vIn ="Dispatch ANSI"
Object Call d.TestANSI( vIn ) To vOut
? Variant$( vOut )
End Function
Class Class1
Interface Interface1: Inherit Dual
Method TestUNI( ByVal x As String ) As String
x = ACode$( x )
x = x & $CrLf & x
Method = UCode$( x )
End Method
Method TestANSI( ByVal x As String ) As String
x = x & $CrLf & x
Method = x
End Method
End Interface
End Class
This may be another reason to abandon ansicode in com objects(?)
Quote
Here is what i have tested, for some reason PB seems to understand UNI and ANSI bstrings when passed to the dispatch interface.
Odd is the last call in this example which appends the strings not with a CRLF but with a ?
No it doesn't. What you call TestANSI doesn't receive an ansi string, but an unicode one.
Change:
Method TestANSI( ByVal x As String ) As String
x = x & $CrLf & x
Method = x
End Method
to:
Method TestANSI( ByVal x As String ) As String
x = x & UCODE$($CrLf) & x
Method = x
End Method
Quote
This may be another reason to abandon ansicode in com objects(?)
Ansi should be abandoned in everything, including the Windows API. PB should implement native unicode support and we switch to use the "W" api functions. If done right, we could work as now, transparently, using wide strings and wide null terminated strings, e.g. AS WSTRING and as WASCIIZ, instead of AS STRING and AS ASCIIZ. No more need for ACODE$/UCODE$ and STRPTRs.
>No it doesn't. What you call TestANSI doesn't receive an ansi string, but an unicode one.
Hah, of course, Variant$() converts it as well of course, i was confused.
:)
Conclusion is that we should implement com stuff meant for exported use in unicode.
(I will not use it for internal use, to much overhead)
>PB should implement native unicode support and we switch to use the "W" api functions.
Sure but to late for me.
I am working on my 'last' project, then an unlimited holiday from 'outside the office' hours :)
Quote, then an unlimited holiday from 'outside the office' hours
Did you win in the Lottery?