Dmitry Timoshkov wrote:
> "Jeff Latimer" wrote:
>> The issue is that the client passes data using messaging or DDEML
>> there is no method in the api to inform the server whether the data
>> is Unicode or not. The only method I have determined is to use
>> IsTextUnicode() but that is guessing.
Dmitry Timoshkov wrote:
>> It highlights the problem and that the translation should take place
>> in the server. In earlier discussions last year this was an issue.
> Again, do you have a test case for that as a proof?
When solving the winebrowser problem, I was fixing the existing
translation
"Jeff Latimer" wrote:
>>> Agreed, the point I was making is that DDEML wraps the raw DDE, the
>>> translation occurs in the server not the client.
>> Does it really matter?
> It highlights the problem and that the translation should take place in
> the server. In earlier discussions last year
Dmitry Timoshkov wrote:
>
DDE and DDEML are supposed to interchangeable. A DDE client can
talk to a DDEML server and turnabout.
>>> DDEML is just a wrapper around raw DDE messages, and raw DDE messages
>>> don't have a translation layer in the user32 messaging system.
>> Agreed, the poi
"Jeff Latimer" wrote:
>>> DDE and DDEML are supposed to interchangeable. A DDE client can talk
>>> to a DDEML server and turnabout.
>> DDEML is just a wrapper around raw DDE messages, and raw DDE messages
>> don't have a translation layer in the user32 messaging system.
> Agreed, the point I wa
Dmitry Timoshkov wrote:
>> DDE and DDEML are supposed to interchangeable. A DDE client can talk
>> to a DDEML server and turnabout.
> DDEML is just a wrapper around raw DDE messages, and raw DDE messages
> don't have a translation layer in the user32 messaging system.
Agreed, the point I was maki
"Jeff Latimer" wrote:
>> Passing raw DDE messages should be
>> out of interest, it's the application's problem.
> DDE and DDEML are supposed to interchangeable. A DDE client can talk to
> a DDEML server and turnabout.
DDEML is just a wrapper around raw DDE messages, and raw DDE messages
don't
Dmitry Timoshkov wrote:
> "Jeff Latimer" wrote:
>
>> The issue is that the client passes data using messaging or DDEML
>> there is no method in the api to inform the server whether the data
>> is Unicode or not. The only method I have determined is to use
>> IsTextUnicode() but that is guessin
"Jeff Latimer" wrote:
> The issue is that the client passes data using messaging or DDEML there
> is no method in the api to inform the server whether the data is Unicode
> or not. The only method I have determined is to use IsTextUnicode() but
> that is guessing. However, it looks like Wind
I have resubmitted this patch for discussion purposes.
Patch "user32/tests: Clarify the msgs to differentiate Unicode and ASCII
in tests" cleans up existing tests for this situation and demonstrates
the functionality.
The problem remains that the application passes to the dde/ddeml data
that i
Dmitry Timoshkov wrote:
Then the first thing to do is to write some test cases.
I have had another look at the existing test cases that I added a few
months ago. I have rerun the tests before and after the patch "[3/5]
user32: Resend: Move character conversion logic to dde_server.d &am
Hans Leidekker wrote:
> On Wednesday 14 January 2009 08:29:33 Jeff Latimer wrote:
>
>
>> I have tested this a number of ways and I can not see a mechanism that
>> DDE can determine whether data passed is UNICODE (pData is of type
>> LPBYTE). In my tests, the case of the server uses a UNICODE
On Wednesday 14 January 2009 08:29:33 Jeff Latimer wrote:
> I have tested this a number of ways and I can not see a mechanism that
> DDE can determine whether data passed is UNICODE (pData is of type
> LPBYTE). In my tests, the case of the server uses a UNICODE window it
> is immaterial as to
13 matches
Mail list logo
