Vincent Béron wrote:
> Is it best to use MultiByteToWideChar() or
> RtlCreateUnicodeStringFromAsciiz()? I find that latter function much
> easier to use (no need to mess with string lengths, etc.).
Well for system DLLs this shouldn't be a problem. But for other DLLs
this might create an undiserab
iirc, RtlCreateUnicodeStringFromAsciiz has a limitation due to use of
the UNICODE_STRING structure - it can only deal with strings up to
2^16-1 bytes in length. Input to edit controls and other strings may be
longer than that, so be careful where you use it.
It also makes our DLLs depend on ntd
Vincent Béron wrote:
Is it best to use MultiByteToWideChar() or
RtlCreateUnicodeStringFromAsciiz()? I find that latter function much
easier to use (no need to mess with string lengths, etc.).
iirc, RtlCreateUnicodeStringFromAsciiz has a limitation due to use of
the UNICODE_STRING structure - it ca
Le lun 06/09/2004 à 14:04, Rolf Kalbermatter a écrit :
> "Diego 'Flameeyes' =?ISO-8859-1?Q?Petten=F2?=" wrote:
>
> >I have only a doubt:
> >
> >> - Is it possible to implement the ANSI version by converting to unicode
> >>then calling the wide version, rather than duplicate it?
> >
> >How can
"Diego 'Flameeyes' =?ISO-8859-1?Q?Petten=F2?=" wrote:
>I have only a doubt:
>
>> - Is it possible to implement the ANSI version by converting to unicode
>>then calling the wide version, rather than duplicate it?
>
>How can I convert an ansi string to a unicode one and reverse? So I can redo
>t
Mike Hearn wrote:
> Yeah, it's a bit of a pain keeping track of useful patches that were
> never merged. Maybe we need a list somewhere.
Yes, it can be very helpful, if I can be helpful in any way, I'm here :)
> A few things that jump out at me (not really reviewed the code itself):
Thanks a lot,
Yes. It is useful for printing large strings that would otherwise
overflow the static buffer and for strings that contain non-ASCII
characters.
I stand corrected (thanks to Uwe as well).
I also finder easier to read functions that have all the variables
declared at the top of each block. Don't k
Mike Hearn wrote:
The second thing is about the coding style. As I said before, I have
a patch
for shlwapi which fixes some MSXML/Borland XML Components problems
with the
builtin one, which wasn't accepted for some problem about the style
and the
placement of the variables. I posted it as a bug
> "Mike" == Mike Hearn <[EMAIL PROTECTED]> writes:
...
Mike> cheatsheet - Are you sure there is a debugstr_a?? I can't think
Mike> what it would do, ANSI strings can just be printed by regular
Mike> printf
...
hertz:/spare/bon/wine-realclean/wine> grep debugstr_a include/*/*
inc
> That's is very interesting and useful, but I think there's two things
that
can be improved: first the debug delay patch, I wasn't able to find it out
searching with gmane, maybe if you can add a link to the post on gmane it
should be better :)
Yeah, it's a bit of a pain keeping track of useful p
About handling Unicode strinsg you say:
> when allocating buffers for unicode strings use
> sizeof(string)*sizeof(WCHAR).
It's not very clear and most of the type the sizeof will not give the
expected result. I think it would be better to say to use
(strlen(ansi_string)+1)*sizeof(WCHAR). But rea
Mike Hearn wrote:
> Back in February at WineConf one of the issues (I) raised was that
> there's a lot of stuff you just have to know in order to hack Wine, and
> that raises the barrier to entry.
That's is very interesting and useful, but I think there's two things that
can be improved: first the
I like this Mike. It's even convenient if you aren't so new.
On Sat, 04 Sep 2004 13:31:52 +0100, Mike Hearn <[EMAIL PROTECTED]> wrote:
> Hi guys,
>
> Back in February at WineConf one of the issues (I) raised was that
> there's a lot of stuff you just have to know in order to hack Wine, and
> th
13 matches
Mail list logo
