[wx-dev] IPC using DDE bug fix and changes

Vadim Zeitlin vadim at wxwidgets.org
Sat Dec 1 07:39:02 PST 2007


On Sat, 01 Dec 2007 08:47:23 -0500 Brian Vanderburg II <BrianVanderburg2 at aim.com> wrote:

BVI> Also, before I start on it, there is a bug in 'buffer.h' as 
BVI> well, wxUTF8Buf should be 'char*' in unicode-utf8 and wxCharBuffer 
BVI> otherwise.

 Thanks for noticing this, fixed in the svn!

BVI> In the current code OnExecute always gets called with wxIPC_TEXT.  But 
BVI> in a unicode build, the data received by DdeGetData with XTYP_EXECUTE is 
BVI> always unicode (even if the sending application sent it as ansi) so this 
BVI> would cause a problem if the user says if(format == wxIPC_TEXT) do 
BVI> something with ansi text (else if format == wxIPC_UNICODE_TEXT) do 
BVI> soemthing with unicode text from inside OnExecute
BVI> 
BVI> The change for that part was quite simple, pass wxIPC_TEXT in ansi 
BVI> builds and wxIPC_UNICODETEXT in unicode builds to the OnExecute function.

 This seems correct, thanks. I wonder if we shouldn't have
wxIPC_TEXT_STRING or something like that mapping to the right wxIPC_*TEXT
depending on the build. An alternative would be to change wxIPC_TEXT to
mean this (and rename the existing value to wxIPC_ANSITEXT) but I'm not
sure about the backwards compatibility implications of this.

 However it seems that we shouldn't use wxIPC_UTF8TEXT at all in ANSI
build. This is not necessary for compatibility (it didn't exist before) and
it's not clear how to do it correctly (as the encoding information is
lost). So it seems simpler to not handle it at all.

BVI> In unicode, it will convert wxIPC_TEXT and wxIPC_UTF8TEXT to wide
BVI> character and pass it.

 This seems reasonable.

BVI> Index: src/msw/dde.cpp

 I've applied your patch with some minor fixes (removed the do/while(0)
hack; fixed ANSI compilation), thanks!

VZ





More information about the wx-dev mailing list