Recommendations Concerning COM And Strings With Regard To New Compilers

[Frederick J. Harris]

Hi Jose!

I've just started using the new compilers (didn't get my disks till last Saturday), and today and yesterday I just started compiling my existing projects which contain a lot of Excel and Word COM.

I have to admit I haven't looked at your TypeLib browser yet, or your new includes, figuring I ought to become familiar with the PowerBASIC tools first.  An immediate question arose in my mind concerning the inc files generated by the new COM browsers.  Sure enough, there is an option button to export interface members that either return strings or WStrings, or take string parameters as either WString or String.  What would you recommend?

I came across this when I compiled one of my projects that accesses Excel...

Code Select Expand


Local strTmp As String
Local strSpecies() As String
Local vVnt, vSpecies As Variant

For i=0 To 26
   vVnt=strSpecies(i)
   Object Get oExcelWorkSheet.Range(vVnt).Value To vSpecies
   strTmp=Variant$(vSpecies)
   .....


I compiled the above with PB10, but using the PB9 generated include file for Excel, which of course just uses Ansi Strings.  What happened is that the call to oExcelWorkSheet.Range(vVnt).Value succeeded;  however, what got stored in Variant vSpecies was a wide character string.  In the next line of code strTmp just got loaded with the first character of the wide character string stored in vSpecies, which makes sense.  To fix it, I just did this...

strTmp=ACode$(Variant$(vSpecies))

All of this raises the question in my mind as to whether we ought to just abandon String and use WString for everything.  I'm wondering if in legacy code I should take the time to go through and redo the code to just use WString and generate WString interface declares, or if using the Acode$ conversion would be best.  Any thoughts on this?

[José Roca]

Sure enough, there is an option button to export interface members that either return strings or WStrings, or take string parameters as either WString or String.  What would you recommend?

The new PB COM browser has an option for this (I guess that for the sake of it, because it is useless with the new compilers); my new browser, not (use the older if needed).

When working with COM and the new compilers, forget UCODE$/ACODE$. COM always works with unicode strings, with the exception of Direct X 9, so use WSTRINGs and WSTRINGZs.

If working with legacy code, use the old includes, unless you're willing to modify the code.

To fix it, I just did this...
strTmp=ACode$(Variant$(vSpecies))

The correct way is strTmp=(Variant$$(vSpecies)).

With the new compilers, VARIANT$ assumes that the variant contains an ansi string, and with VARIANT$$ that it contains an unicod string. There are some other $$ functions, such CHR$$ and STRING$$, but not many.

In your code,

vVnt=strSpecies(i)

works because PB converts it automatically to unicode, but you should use a WSTRING array.

All of this raises the question in my mind as to whether we ought to just abandon String and use WString for everything.

In all my new code, I'm using unicode only. The Windows API is natively unicode and, if you call an "A" function, it has to convert to unicode and back to ansi, so is faster to use the "W" versions. The only API function with a parameter string that has not a "W" companion is GetProcAddress.

Use STRINGs and ASCIIZs only when needed, e.g. when calling functions of a DLL that doesn't support unicode or when using it as a buffer to store binary data.

Guess that it will take a long time to PBer's to get used to this, but using unicode strings has advantages both when using PB statements and the Windows API, the main one being that the strings don't need to be converted to unicode and back to ansi.

[Frederick J. Harris]

Thanks for the detailed explanation Jose.  I was tending to think that, as you said, we would be better off just using wide strings. 

By the way, I've seen in several posts of yours that you are attaching *.rar files.  I had to google that to find out what they were.  Never saw that extension before.  What app would you recommend we use to extract files out of those?

[José Roca]

WinRAR: http://www.rarlab.com/

It is much better than WinZIP. Also uncrompresses zip files and many others.

I have used it because one of the .zip files was bigger than 8 Mb and was unable to upload it to this forum. Compressed with the best compression option of WinRAR was about 2 MB less and was able to upload it.