Huw Davies wrote:
dlls/user32/tests/clipboard.c | 7 +++++-- 1 files changed, 5 insertions(+), 2 deletions(-)
Was just about to sent a patch along those lines.
Isn't it better to mark that win9x (and winME as well btw) one as broken()?
On Tue, Apr 21, 2009 at 11:22:29AM +0200, Paul Vriens wrote:
Huw Davies wrote:
dlls/user32/tests/clipboard.c | 7 +++++-- 1 files changed, 5 insertions(+), 2 deletions(-)
Was just about to sent a patch along those lines.
Isn't it better to mark that win9x (and winME as well btw) one as broken()?
I was debating with myself whether to mark it as broken or not. My feeling was that it's not actually broken behaviour rather missing functionality. But I don't really care.
Huw.
Huw Davies wrote:
On Tue, Apr 21, 2009 at 11:22:29AM +0200, Paul Vriens wrote:
Huw Davies wrote:
dlls/user32/tests/clipboard.c | 7 +++++-- 1 files changed, 5 insertions(+), 2 deletions(-)
Was just about to sent a patch along those lines.
Isn't it better to mark that win9x (and winME as well btw) one as broken()?
I was debating with myself whether to mark it as broken or not. My feeling was that it's not actually broken behaviour rather missing functionality. But I don't really care.
Huw.
Maybe it's not broken() behavior but marking it as broken() makes sure we (Wine) will have CF_UNICODETEXT. Without that broken(), CF_UNICODETEXT can go missing without us knowing.
On Tue, Apr 21, 2009 at 11:34:04AM +0200, Paul Vriens wrote:
Huw Davies wrote:
On Tue, Apr 21, 2009 at 11:22:29AM +0200, Paul Vriens wrote:
Huw Davies wrote:
dlls/user32/tests/clipboard.c | 7 +++++-- 1 files changed, 5 insertions(+), 2 deletions(-)
Was just about to sent a patch along those lines.
Isn't it better to mark that win9x (and winME as well btw) one as broken()?
I was debating with myself whether to mark it as broken or not. My feeling was that it's not actually broken behaviour rather missing functionality. But I don't really care.
Huw.
Maybe it's not broken() behavior but marking it as broken() makes sure we (Wine) will have CF_UNICODETEXT. Without that broken(), CF_UNICODETEXT can go missing without us knowing.
Yeah, fair enough. I guess the point is it's broken behaviour for Wine. I'll resend, thanks.
Huw.
Huw Davies wrote:
On Tue, Apr 21, 2009 at 11:34:04AM +0200, Paul Vriens wrote:
Huw Davies wrote:
On Tue, Apr 21, 2009 at 11:22:29AM +0200, Paul Vriens wrote:
Huw Davies wrote:
dlls/user32/tests/clipboard.c | 7 +++++-- 1 files changed, 5 insertions(+), 2 deletions(-)
Was just about to sent a patch along those lines.
Isn't it better to mark that win9x (and winME as well btw) one as broken()?
I was debating with myself whether to mark it as broken or not. My feeling was that it's not actually broken behaviour rather missing functionality. But I don't really care.
Huw.
Maybe it's not broken() behavior but marking it as broken() makes sure we (Wine) will have CF_UNICODETEXT. Without that broken(), CF_UNICODETEXT can go missing without us knowing.
Yeah, fair enough. I guess the point is it's broken behaviour for Wine. I'll resend, thanks.
Huw.
Yeah, it's either broken() or some clumsy:
cf = EnumClipboardFormats(cf); if (cf == CF_METAFILEPICT) win_skip("Win9x/WinME don't have CF_UNICODETEXT\n"); else { ok(cf == CF_UNICODETEXT, "cf %08x\n", cf); cf = EnumClipboardFormats(cf); } ok(cf == CF_METAFILEPICT, "cf %08x\n", cf);
Maybe we should have behavior_we_dont_want_to_replicate() next to broken() ;)
-
Huw Davies -
Paul Vriens