Re : d3dx9_36: D3DXQuaternionLn computes as if the norm of the input is 1
>>2012/6/12 Nozomi Kodama : >> >> + if ( (pq->w >= 1.0f) || (pq->w == -1.0f) ) > >I think the second comparison should be '<=', if you want to avoid getting >NaNs. I checked in Vista. D3DX accepts -1.0f as input and returns what the patch does. However, any value < -1.0f is a unacceptable value for D3DX ( D3DX returns (-1#IND00,-1#IND00,-1#IND00,-1#IND00) ). Best regards Nozomi
Re: [10/11] windowscodecs: Handle IFD fields with count 0 same way as with count 1.
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=18988 Your paranoid android. === W7PRO (32 bit metadata) === metadata.c:505: Test failed: 20: expected count 3, got 4 metadata.c:506: Test failed: 20: expected abc, got abcd === W7PROX64 (32 bit metadata) === metadata.c:505: Test failed: 20: expected count 3, got 4 metadata.c:506: Test failed: 20: expected abc, got abcd === TEST64_W7SP1 (32 bit metadata) === metadata.c:505: Test failed: 20: expected count 3, got 4 metadata.c:506: Test failed: 20: expected abc, got abcd === W7PROX64 (64 bit metadata) === metadata.c:505: Test failed: 20: expected count 3, got 4 metadata.c:506: Test failed: 20: expected abc, got abcd === TEST64_W7SP1 (64 bit metadata) === metadata.c:505: Test failed: 20: expected count 3, got 4 metadata.c:506: Test failed: 20: expected abc, got abcd
Re: [11/11] windowscodecs: Implement GetMetadataFormat.
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=18989 Your paranoid android. === W7PRO (32 bit metadata) === metadata.c:530: Test failed: 20: expected count 3, got 4 metadata.c:531: Test failed: 20: expected abc, got abcd === W7PROX64 (32 bit metadata) === metadata.c:530: Test failed: 20: expected count 3, got 4 metadata.c:531: Test failed: 20: expected abc, got abcd === TEST64_W7SP1 (32 bit metadata) === metadata.c:530: Test failed: 20: expected count 3, got 4 metadata.c:531: Test failed: 20: expected abc, got abcd === W7PROX64 (64 bit metadata) === metadata.c:530: Test failed: 20: expected count 3, got 4 metadata.c:531: Test failed: 20: expected abc, got abcd === TEST64_W7SP1 (64 bit metadata) === metadata.c:530: Test failed: 20: expected count 3, got 4 metadata.c:531: Test failed: 20: expected abc, got abcd
Re: [09/11] windowscodecs: Add support for IFD_UNDEFINED field type.
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=18987 Your paranoid android. === W7PRO (32 bit metadata) === metadata.c:497: Test failed: 20: expected count 3, got 4 metadata.c:498: Test failed: 20: expected abc, got abcd === W7PROX64 (32 bit metadata) === metadata.c:497: Test failed: 20: expected count 3, got 4 metadata.c:498: Test failed: 20: expected abc, got abcd === TEST64_W7SP1 (32 bit metadata) === metadata.c:497: Test failed: 20: expected count 3, got 4 metadata.c:498: Test failed: 20: expected abc, got abcd === W7PROX64 (64 bit metadata) === metadata.c:497: Test failed: 20: expected count 3, got 4 metadata.c:498: Test failed: 20: expected abc, got abcd === TEST64_W7SP1 (64 bit metadata) === metadata.c:497: Test failed: 20: expected count 3, got 4 metadata.c:498: Test failed: 20: expected abc, got abcd
Re: [08/11] windowscodecs: Add tests for more types of IFD fields.
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=18986 Your paranoid android. === W7PRO (32 bit metadata) === metadata.c:494: Test failed: 20: expected count 3, got 4 metadata.c:495: Test failed: 20: expected abc, got abcd === W7PROX64 (32 bit metadata) === metadata.c:494: Test failed: 20: expected count 3, got 4 metadata.c:495: Test failed: 20: expected abc, got abcd === TEST64_W7SP1 (32 bit metadata) === metadata.c:494: Test failed: 20: expected count 3, got 4 metadata.c:495: Test failed: 20: expected abc, got abcd === W7PROX64 (64 bit metadata) === metadata.c:494: Test failed: 20: expected count 3, got 4 metadata.c:495: Test failed: 20: expected abc, got abcd === TEST64_W7SP1 (64 bit metadata) === metadata.c:494: Test failed: 20: expected count 3, got 4 metadata.c:495: Test failed: 20: expected abc, got abcd
Misspelt Portuguese in msvcrt
Is there a reason why Portuguese is misspelt in these two places? diff --git a/dlls/msvcrt/locale.c b/dlls/msvcrt/locale.c index 97b82ec..b26a9c8 100644 --- a/dlls/msvcrt/locale.c +++ b/dlls/msvcrt/locale.c @@ -85,7 +85,7 @@ static const char * const _country_synonyms[] = "german-swiss", "des", "italian-swiss", "its", "german-austrian", "dea", -"portugese", "ptb", +"portuguese", "ptb", "portuguese-brazil", "ptb", "spanish-mexican", "esm", "norwegian-bokmal", "nor", diff --git a/dlls/msvcrt/tests/locale.c b/dlls/msvcrt/tests/locale.c index 8d6a34f..638a3d2 100644 --- a/dlls/msvcrt/tests/locale.c +++ b/dlls/msvcrt/tests/locale.c @@ -472,7 +472,7 @@ static void test_setlocale(void) if(ret) ok(!strcmp(ret, "Polish_Poland.1250"), "ret = %s\n", ret); -ret = setlocale(LC_ALL, "portugese"); +ret = setlocale(LC_ALL, "portuguese"); ok(ret != NULL || broken (ret == NULL), "ret == NULL\n"); if(ret) ok(!strcmp(ret, "Portuguese_Brazil.1252"), "ret = %s\n", ret); -- Francois Gouget http://fgouget.free.fr/ E-Voting: Those who cast the votes decide nothing. Those who count the votes decide everything.
Re: po: Update Russian translation (try 3) (resend)
msgid "KeyID=" -msgstr "Код ключа=" +msgstr "Код ключа: " [...] msgid "Other Name=" -msgstr "Другое имя=" +msgstr "Альтернативное имя: " and many more like this. Why did you not fix this? Replacing the equal sign with a colon looks wrong to me but then I don't speak Russian. Still I have not seen anything to suggest that the typographic rules would be different in this regard. But Nikolay Sivov, who speaks Russian, seems to concur. Note that this was reported to you back in May: http://www.winehq.org/pipermail/wine-devel/2012-May/095672.html -- Francois Gouget http://fgouget.free.fr/ Good judgment comes from experience, and experience comes from bad judgment -- Barry LePatner
Re: d3dx9_36: D3DXQuaternionLn computes as if the norm of the input is 1
2012/6/12 Nozomi Kodama : > > +if ( (pq->w >= 1.0f) || (pq->w == -1.0f) ) I think the second comparison should be '<=', if you want to avoid getting NaNs.
Re: Command line parameters
On 12/06/2012 8:59 PM, John Emmas wrote: > Thanks Hin-Tak and Dan but I think we're at crossed purposes now. > Remember that my original question had nothing to do with paths. I > simply used paths as a convenient example. My question is about > command-line parameters and (more specifically) about UTF-8 string > conversion. Here's an example Consider a Windows user whose > name is Göran. The UTF-8 byte sequence for this is:- > > 47 C3 B6 72 61 6E -- (6 bytes) > > whereas Windows would expect something like this (depending on the > user's locale):- > > 47 F6 72 61 6E -- (5 bytes) > > Let's suppose that a Linux app launches a Windows child process > (via Wine). The (Linux) host app needs to pass the string "Göran" > as one of the command-line parameters. Linux uses UTF-8 and will > therefore pass the first sequence of bytes to Wine (6 bytes). But > Windows doesn't understand UTF-8. A Windows app would expect the > second byte sequence (5 bytes - or 10 bytes for a Unicode app). By "Linux uses UTF-8" you're saying that you have a UTF-8 locale active. > > Does Wine carry out the necessary conversion or does it simply > pass the original byte string unmodified? That's what I'm trying > to find out. Thanks. Wine first converts the command-line to Unicode according to the active host locale. Then any character set conversion from Unicode to ANSI or vice versa within the application is done according to the active Windows locale. If the Wine process needs to execute a native process, Wine converts the command line from Unicode using the active host locale. The default character set under Linux is ISO-8859-1, while the default character set under Windows is Windows-1252, which has all of the printable characters in the same places as in ISO-8859-1, with some extra printable characters in the C1 (0x80..0x9F) area. If no host locale is specified (i.e. the locale is POSIX), and the default Windows locale is used, then the only available characters an ANSI Windows program will be unable to be passed are the extra characters in the C1 area. All unrepresentable characters are replaced with question marks [?]. -- Ben Peddell IT Support Bowen, Collinsville and Proserpine Catholic schools http://klightspeed.killerwolves.net/
Re: Command line parameters
--- On Tue, 12/6/12, John Emmas wrote: > Thanks Hin-Tak and Dan but I think we're at crossed purposes > now. Remember that my original question had nothing to > do with paths. I simply used paths as a convenient > example. My question is about command-line parameters > and (more specifically) about UTF-8 string conversion. > Here's an example Consider a Windows user whose > name is Göran. The UTF-8 byte sequence for this is:- > > 47 C3 B6 72 61 6E -- (6 > bytes) > > whereas Windows would expect something like this (depending > on the user's locale):- > > 47 F6 72 61 6E -- (5 > bytes) > > Let's suppose that a Linux app launches a Windows child > process (via Wine). The (Linux) host app needs to pass > the string "Göran" as one of the command-line > parameters. Linux uses UTF-8 and will > therefore pass the first sequence of bytes to Wine (6 > bytes). But Windows doesn't understand UTF-8. A > Windows app would expect the second byte sequence (5 bytes - > or 10 bytes for a Unicode app). > > Does Wine carry out the necessary conversion or does it > simply pass the original byte string unmodified? > That's what I'm trying to find out. Thanks. I have already answered that question - it depends on your application, how it uses win32 API. win32 api's is divided into the older *A routines which expects ascii, and the newer *W routines, which expects WCHAR (UTF16LE).
Re: [PATCH 1/4] hhctrl.ocx: Add HTML to Unicode decoding capability (try 2).
On Tue, Jun 12, 2012 at 2:07 AM, Jacek Caban wrote: > ... > You didn't address most of my comments. Feel free to ask for > clarifications if something was not clear enough. I'm really sorry about that, for some reason gmail hid them as a quote. Erich
Re: [PATCH 4/5] wined3d: Set undefined vertex attributes to 0.0.
Am Dienstag, 12. Juni 2012, 17:03:49 schrieb Henri Verbeet: > +if (state->vertex_shader->reg_maps.input_registers & (1 << i)) > +GL_EXTCALL(glVertexAttrib4fARB(i, 0.0f, 0.0f, 0.0f, 0.0f)); Does an application need this? Afair Windows drivers have implementation- specific behavior here that pretty much matches their GL counterparts. signature.asc Description: This is a digitally signed message part.
Re: Command line parameters
On 12/06/2012 8:59 PM, John Emmas wrote: > Thanks Hin-Tak and Dan but I think we're at crossed purposes now. > Remember that my original question had nothing to do with paths. I > simply used paths as a convenient example. My question is about > command-line parameters and (more specifically) about UTF-8 string > conversion. Here's an example Consider a Windows user whose > name is Göran. The UTF-8 byte sequence for this is:- > > 47 C3 B6 72 61 6E -- (6 bytes) > > whereas Windows would expect something like this (depending on the > user's locale):- > > 47 F6 72 61 6E -- (5 bytes) > > Let's suppose that a Linux app launches a Windows child process > (via Wine). The (Linux) host app needs to pass the string "Göran" > as one of the command-line parameters. Linux uses UTF-8 and will > therefore pass the first sequence of bytes to Wine (6 bytes). But > Windows doesn't understand UTF-8. A Windows app would expect the > second byte sequence (5 bytes - or 10 bytes for a Unicode app). By "Linux uses UTF-8" you're saying that you have a UTF-8 locale active. > > Does Wine carry out the necessary conversion or does it simply > pass the original byte string unmodified? That's what I'm trying > to find out. Thanks. Wine first converts the command-line to Unicode according to the active host locale. Then any character set conversion from Unicode to ANSI or vice versa within the application is done according to the active Windows locale. If the Wine process needs to execute a native process, Wine converts the command line from Unicode using the active host locale. The default character set under Linux is ISO-8859-1, while the default character set under Windows is Windows-1252, which has all of the printable characters in the same places as in ISO-8859-1, with some extra printable characters in the C1 (0x80..0x9F) area. If no host locale is specified (i.e. the locale is POSIX), and the default Windows locale is used, then the only available characters an ANSI Windows program will be unable to be passed are the extra characters in the C1 area. All unrepresentable characters are replaced with question marks [?]. -- Ben Peddell IT Support Bowen, Collinsville and Proserpine Catholic schools http://klightspeed.killerwolves.net/
Re: [2/2] msxml3: Support xmlns[:*] attribute nodes intelligently.
Den 12-06-2012 13:21, Nikolay Sivov skrev:
> On 6/12/2012 11:55, Ulrik Dickow wrote:
>> Patch 2 of 2 from http://bugs.winehq.org/show_bug.cgi?id=26226 .
>>
>>
>>
>
>> +/* Emit appropriate fixme or warning in case of unsupported or invalid
>> namespace.
>> + * The W3C spec would like us to exit earlier for attempts to redefine
>> the namespace for
>> + * the reserved "xmlns" attribute or prefix
>> (http://www.w3.org/TR/xml-names/#ns-decl),
>> + * like
>> http://gdome2.cs.unibo.it/gtk-doc/gdome2-gdomeelement.html#GDOME-EL-SETATTRIBUTENS,
>> + * but since native msxml3 accepts anything here, it's safest to just
>> continue with warning.
>> + */
> The question is more like what libxml2 thinks about that. If it follows
> w3c here which is likely the question will be - won't it break somewhere
> internally in libxml2 code if we hack it that way?
I don't think so. We have already seen that libxml2 doesn't consider
the attribute "xmlns" to have any special meaning in relation to
namespaces, when setting an attribute. It hasn't given any problems in
my tests.
But maybe you are right that it is safer to return E_INVALIDARG, as I
did in an earlier version, to guard against future increased
intelligence in libxml2. Both of the applications in bug 26226 use the
correct W3C namespace, so they don't care. I'll change it back.
>> +if(namespaceURI && namespaceURI[0] && node_type != NODE_ELEMENT)
>> +{
>> +if(node_type == NODE_ATTRIBUTE)
>> +switch((!strcmpW(name, xmlnsW) ||
>> +!strncmpW(name, xmlnscW,
>> sizeof(xmlnscW)/sizeof(WCHAR))) +
>> + !strcmpW(namespaceURI, w3xmlns))
> Could you please simplify that, it's a bit hard to read.
I guess you mean I simplified it too much. But yes, it can be hard to
read/understand. I'll offer an expanded version using logical variables
and maybe several if-then-else instead of this overly simple switch.
BTW, as a funny side-note, at first I had added a "default:" clause with
a FIXME (or similar) stating that this should be impossible. 'gcc -O2'
was intelligent enough to know that for logical variables a and b in C,
a + b
can only be 0 (both are false), 1 (exactly one is true) or 2 (both are
true), so it completely optimized away the FIXME-string/statement from
the binary.
>> + * Note: We would be more in line with the native msxml if we only
>> detected a
>> + * redundancy/conflict for prefixes existing on the element itself (in
>> element->ns
>> + * or in the linked list element->nsDef). But as long as our
>> *_get_xml() doesn't
>> + * eliminate redundant namespace definitions in children, this
>> behaviour may be
>> + * an advantage in some cases. As disadvantage is that we incorrectly
>> regard the
>> + * redefinition in element 'b' in '' as
>> a conflict.
>> + * Libxml2 currently doesn't have a function or option to only search
>> for namespaces
>> + * on the current node; but it would be easy to make a reduced version
>> of xmlSearchNs
>> + * (currently defined in
>> http://git.gnome.org/browse/libxml2/tree/tree.c#n5871).
>> + * However, most apps probably set the ns to y on node b creation, so
>> no conflict here.
>> + *
> I don't think it's better to potentially break one thing while fixing
> the other.
In current wine, attributes named "xmlns" don't work at all in
setAttributeNode (an error code is returned instead of S_OK, and no
attribute is added, no matter whether a namespace is already present or
not at this level).
So fixing this issue doesn't break anything that worked before. I
consider it a step-wise improvement. Something better, nothing worse.
I wanted to keep that patch as small and simple as possible.
setAttribute also has this "dumb" use of xmlSearchNs.
> And I guess I like a thought on making xmlSearchNs version
> that will do what we want from it.
Ok, actually it'll only be about 10 lines of extra code, roughly, so
I'll add that -- and shrink the comment, less worries, more code :).
> Just to clarify - is that right that libxml2 problem here is a lack of some
> checks
> that lead to duplication and conflicts later? (that are visible in doc
> dumps too)
Well, yes, in a way: it doesn't check whether we try to set attributes
named "xmlns" or use prefix "xmlns" or use the namespaceURI
"http://www.w3.org/2000/xmlns/";. But maybe it shouldn't. It's a matter
of policy -- giving higher layers the freedom to enforce restrictions
themselves.
It turns out that the native msxml3 doesn't enforce restrictions. As
the doc dumps show, it too can give
1) duplication when setAttribute is used (but not when
setAttributeNode is used)
2) conflicts between the namespaces in visible XML (get_xml) versus
what get_namespaceURI tells us, both for setAttribute and setAttributeNode
The most problematic lack in libxml2 is not about treating (input)
attributes specially, but rather the whole concep
Re: Command line parameters
On 7 Jun 2012, at 21:43, Hin-Tak Leung wrote: > --- On Thu, 7/6/12, Dan Kegel wrote: > >> >> Example: >>wine notepad /home/dank/foo.txt >> This fails because notepad treats / as the beginning of an >> option (see http://source.winehq.org/source/programs/notepad/main.c#L616 >> ). >> >> So, no, Wine doesn't translate arguments for you. > > It would probably work in any of these though: > > z:/home/dank/foo.txt > h:/foo.txt > \\home\\dank\\foo.txt > h:\\foo.txt > > (the double backslash for its been interpreted by bash, or whatever shell you > use) > Thanks Hin-Tak and Dan but I think we're at crossed purposes now. Remember that my original question had nothing to do with paths. I simply used paths as a convenient example. My question is about command-line parameters and (more specifically) about UTF-8 string conversion. Here's an example Consider a Windows user whose name is Göran. The UTF-8 byte sequence for this is:- 47 C3 B6 72 61 6E -- (6 bytes) whereas Windows would expect something like this (depending on the user's locale):- 47 F6 72 61 6E -- (5 bytes) Let's suppose that a Linux app launches a Windows child process (via Wine). The (Linux) host app needs to pass the string "Göran" as one of the command-line parameters. Linux uses UTF-8 and will therefore pass the first sequence of bytes to Wine (6 bytes). But Windows doesn't understand UTF-8. A Windows app would expect the second byte sequence (5 bytes - or 10 bytes for a Unicode app). Does Wine carry out the necessary conversion or does it simply pass the original byte string unmodified? That's what I'm trying to find out. Thanks. John
Re: configure.ac: Get the needed libs from cups-config (for OpenBSD)
André Hentschel writes: > Inspired by Matias Colli, see bug 17896. > I made sure it doesn't hurt on other OS and send it because it doesn't seem > he will do it and it's a oneliner. It doesn't work for me on Debian testing, not without manually creating symlinks for the libs that cups-config requires. It sounds like OpenBSD should fix their libcups build. -- Alexandre Julliard julli...@winehq.org
Re: [1/2] msxml3/tests: Reduce code duplication for the namespace change tests.
On 6/12/2012 13:33, Ulrik Dickow wrote: Den 12-06-2012 13:11, Nikolay Sivov skrev: On 6/12/2012 11:52, Ulrik Dickow wrote: +/* create on element and try to alter namespace after that */ +doc = (doc_version == 0 ? + create_document(&IID_IXMLDOMDocument) : + create_document_version(60, &IID_IXMLDOMDocument)); +if (!doc) return; Please use something like CLSID array with every available Document CLSID, instead of only testing 2 of them. There's a lot of examples for that in saxreader.c. Yes, that would be a good idea later on. But note that I didn't invent this "only test 2 of them" thing. This first patch was meant as a tiny structural improvement to the code, without changing _any_ functionality at all (except that the line number info becomes a bit less useful). Sure, I'm not saying that it's your invention or that you're responsible for that, but since you're willing to change corresponding implementation it's better to have it fully tested and that means with all possible versions too. +test_namespaces_change(0); +test_namespaces_change(60); free_bstrs(); } It's better to avoid nested test calls like that imho, you could just add another call in main test list. Yes, I considered that, but again would make this patch change as little as possible, except for simplifying existing code. Ok, since I have to redo patch 2 anyway, I'll also make this improvement to patch 1. Thanks.
Re: [1/2] msxml3/tests: Reduce code duplication for the namespace change tests.
Den 12-06-2012 13:11, Nikolay Sivov skrev:
> On 6/12/2012 11:52, Ulrik Dickow wrote:
>> +/* create on element and try to alter namespace after that */
>> +doc = (doc_version == 0 ?
>> + create_document(&IID_IXMLDOMDocument) :
>> + create_document_version(60, &IID_IXMLDOMDocument));
>> +if (!doc) return;
> Please use something like CLSID array with every available Document
> CLSID, instead of only testing 2 of them. There's a lot of examples for
> that in saxreader.c.
Yes, that would be a good idea later on. But note that I didn't invent
this "only test 2 of them" thing. This first patch was meant as a tiny
structural improvement to the code, without changing _any_ functionality
at all (except that the line number info becomes a bit less useful).
>> +test_namespaces_change(0);
>> +test_namespaces_change(60);
>>
>> free_bstrs();
>> }
> It's better to avoid nested test calls like that imho, you could just
> add another call in main test list.
Yes, I considered that, but again would make this patch change as little
as possible, except for simplifying existing code.
Ok, since I have to redo patch 2 anyway, I'll also make this improvement
to patch 1.
>> +static void test_namespaces_change(int doc_version)
>> +{
>> +IXMLDOMDocument *doc;
>> +IXMLDOMElement *elem;
>> +IXMLDOMNode *node;
> ...
>> +
>> +IXMLDOMElement_Release(elem);
>> +IXMLDOMDocument_Release(doc);
>> +}
>> +
> When this is running on all CLSIDs please add free_bstrs() here.
Sure, already done in my second patch, where I began slurping up a lot
more bstrs in the function.
Re: [2/2] msxml3: Support xmlns[:*] attribute nodes intelligently.
On 6/12/2012 11:55, Ulrik Dickow wrote:
Patch 2 of 2 from http://bugs.winehq.org/show_bug.cgi?id=26226 .
+/* Emit appropriate fixme or warning in case of unsupported or invalid
namespace.
+ * The W3C spec would like us to exit earlier for attempts to redefine the
namespace for
+ * the reserved "xmlns" attribute or prefix
(http://www.w3.org/TR/xml-names/#ns-decl),
+ *
likehttp://gdome2.cs.unibo.it/gtk-doc/gdome2-gdomeelement.html#GDOME-EL-SETATTRIBUTENS,
+ * but since native msxml3 accepts anything here, it's safest to just
continue with warning.
+ */
The question is more like what libxml2 thinks about that. If it follows
w3c here which is likely the question will be - won't it break somewhere
internally in libxml2 code if we hack it that way?
+if(namespaceURI && namespaceURI[0] && node_type != NODE_ELEMENT)
+{
+if(node_type == NODE_ATTRIBUTE)
+switch((!strcmpW(name, xmlnsW) ||
+!strncmpW(name, xmlnscW, sizeof(xmlnscW)/sizeof(WCHAR))) +
+ !strcmpW(namespaceURI, w3xmlns))
Could you please simplify that, it's a bit hard to read.
+ * Note: We would be more in line with the native msxml if we only
detected a
+ * redundancy/conflict for prefixes existing on the element itself (in
element->ns
+ * or in the linked list element->nsDef). But as long as our *_get_xml()
doesn't
+ * eliminate redundant namespace definitions in children, this behaviour
may be
+ * an advantage in some cases. As disadvantage is that we incorrectly
regard the
+ * redefinition in element 'b' in '' as a
conflict.
+ * Libxml2 currently doesn't have a function or option to only search for
namespaces
+ * on the current node; but it would be easy to make a reduced version of
xmlSearchNs
+ * (currently defined
inhttp://git.gnome.org/browse/libxml2/tree/tree.c#n5871).
+ * However, most apps probably set the ns to y on node b creation, so no
conflict here.
+ *
I don't think it's better to potentially break one thing while fixing
the other. And I guess I like a thought on making xmlSearchNs version
that will do what we want from it. Just to clarify - is that right that
libxml2 problem here is a lack of some checks
that lead to duplication and conflicts later? (that are visible in doc
dumps too)
+/* Convenient helper function for creating an attribute node in a given
namespace.
+ * Note: CHECK_HR() should not be here, but in caller, to give optimal line
number info.
+ */
You mean EXPECT_HR here I guess.
+static HRESULT create_attribute_ns(
+IXMLDOMDocument *doc,
+const char *attr_name,
+const char *nsURI,
+IXMLDOMAttribute **attr_ptr)
+{
+HRESULT hr;
+VARIANT var;
+IXMLDOMNode *node;
+
+V_VT(&var) = VT_I1;
+V_I1(&var) = NODE_ATTRIBUTE;
+
+hr = IXMLDOMDocument_createNode(doc, var,_bstr_(attr_name),_bstr_(nsURI),
&node);
+if (hr == S_OK)
+{
+IXMLDOMNode_QueryInterface(node, &IID_IXMLDOMAttribute, (void**)
attr_ptr);
+IXMLDOMNode_Release(node);
+}
+return hr;
+}
Please null out pointer in case of failure, or better always before
createNode().
Re: [1/2] msxml3/tests: Reduce code duplication for the namespace change tests.
On 6/12/2012 11:52, Ulrik Dickow wrote:
Patch 1 of 2 from http://bugs.winehq.org/show_bug.cgi?id=26226 .
+static void test_namespaces_change(int doc_version)
+{
+IXMLDOMDocument *doc;
+IXMLDOMElement *elem;
+IXMLDOMNode *node;
+
+VARIANT var;
+HRESULT hr;
+BSTR str;
+
+/* create on element and try to alter namespace after that */
+doc = (doc_version == 0 ?
+ create_document(&IID_IXMLDOMDocument) :
+ create_document_version(60, &IID_IXMLDOMDocument));
+if (!doc) return;
Please use something like CLSID array with every available Document
CLSID, instead of only testing 2 of them. There's a lot of examples for
that in saxreader.c.
+test_namespaces_change(0);
+test_namespaces_change(60);
free_bstrs();
}
It's better to avoid nested test calls like that imho, you could just
add another call in main test list.
+static void test_namespaces_change(int doc_version)
+{
+IXMLDOMDocument *doc;
+IXMLDOMElement *elem;
+IXMLDOMNode *node;
...
+
+IXMLDOMElement_Release(elem);
+IXMLDOMDocument_Release(doc);
+}
+
When this is running on all CLSIDs please add free_bstrs() here.
Re: [PATCH] ntprint: Do not fail when the spooler service was stopped
Detlef Riekenberg writes:
> @@ -88,22 +92,25 @@ static void test_PSetupDestroyMonitorInfo(VOID)
> {
> HANDLE mi;
>
> -
> SetLastError(0xdeadbeef);
> pPSetupDestroyMonitorInfo(NULL);
> -/* lasterror is returned */
> -trace("returned with %u\n", GetLastError());
> +/* lasterror is untouched */
> +ok(GetLastError() == 0xdeadbeef, "returned with 0x%x\n", GetLastError());
Testing last error on success is not useful.
--
Alexandre Julliard
julli...@winehq.org
Re: [PATCH 1/4] hhctrl.ocx: Add HTML to Unicode decoding capability (try 2).
Hi Erich, On 06/11/12 21:01, Erich E. Hoover wrote: > Real Name: > Erich Hoover > > Description: > This patch adds the ability in HTML Help to convert HTML encoded > characters (e.g. ê) into the Unicode character equivalent. This > feature is needed by the table of contents and the index for > displaying international characters in some CHM files. With this > version of the patch the decoding is done manually by parsing the HTML > characters instead of using the web browser control. It is important > to note that HTML Help only supports characters within the ANSI code > pages, so support for multi-byte characters is not necessary. > > Changelog: > hhctrl.ocx: Add HTML to Unicode decoding capability. You didn't address most of my comments. Feel free to ask for clarifications if something was not clear enough. Jacek
Re: [1/4] msi/tests: Use only uppercase characters for the PID_REVNUMBER property.
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=18972
Your paranoid android.
=== WNT4WSSP6 (32 bit install) ===
install.c:6053: Test failed: Per-user icon file isn't where it's expected
(C:\WINNT\Profiles\Default User\Application
Data\Microsoft\Installer\{7DF88A49-996F-4EC8-A022-BF956F9B2CBB}\testicon)
