MR Michael Robellard (5314) schrieb:
> Thomas,
>
> Thanks for your help... Worked like a charm... I am not sure why your IE
> was calling translate from IURLSearchHook instead of
> TranslateWithSearchContext on IURLSearchHook2 on your machine, but we
> made the suggested changes to the generated file to a POINTER(c_wchar)
> and we started getting calls. We had to make a few changes to your
> suggestion for clearing the buffer and writing it back out because the
> slice operations weren't working right:
>
> def TranslateWithSearchContext(self, this, lpwszSearchURL, cchBufferSize,
> pSearchContext):
> # lpwszSearchURL is a POINTER(c_wchar) instance.
> rawdata = lpwszSearchURL[:cchBufferSize]
> # rawdata is now a unicode string of length cchBufferSize, filled
> with NUL characters
> # at the end. The [in] unicode string can probably be get by this:
> url = rawdata.split('\0')[0]
>
> # Maybe ctypes.wstring_at(lpwszSearchURL) would also work.
>
> # The [out] string must be written into the lpwszSearchURL buffer,
> maybe this works:
> for i in range(cchBufferSize):
> lpwszSearchURL[i] = '\0'# clear it
>
> urlout = searchgenerator.GenSearchUrl(url, {'f':'web', 'sbs':'1',
> 'from':'ie'})
> for i in range(len(urlout)):
> if i >= cchBufferSize: break
> lpwszSearchURL[i] = urlout[i]
> return S_OK
Fine, it's great that you got it to work. Maybe sometime I find out why it
doesn't work for me...
>
> Does codegenerator.py need to be changed to look for 'out' parameters
> for strings and change them to POINTER(c_wchar) and POINTER(c_char)?
Maybe it would be a good idea to let the codegenerator generate POINTER(c_wchar)
and POINTER(c_char) instead of STRING == c_char_p and WSTRING == c_wchar_p. You
can even patch codegenerator yourself by changing the line 'ASSUME_STRINGS =
True'
to 'ASSUME_STRINGS = False' in your installation.
The real problem is that ctypes (and even C) does not define what 'char *'
really means.
Sometimes it is a pointer to a single character, sometimes it is a pointer to a
character
array of a certain size, and sometimes it is a pointer to a NUL-terminated
string.
Sometimes the buffer is mutable, sometimes not ('char *' vs. 'const char *').
There
is no way for the code generator to determine what is correct.
The 'ASSUME_STRINGS = True' assumes NUL-terminated strings, which is most often
true,
but not always. Probably 'ASSUME_STRINGS = False' should be the default,
leaving it
up to the programmer to tale the correct action. I'll think about it.
> In the meantime we can keep the generated .py file in another place and
> use it explicity correct?
Sure. That's what I would recommend anyway for interfaces when no type-library
is provided.
I use the code-generator only to create an initial module, then move this
somewhere else, rename
it and change it to my needs - most comtypes interface definitions have been
created in this way.
Thomas
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
comtypes-users mailing list
comtypes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/comtypes-users
