Hi Piotr, thanks for your work, I'm really exciting with the oleacc works because Selenium IE Driver depends on oleacc and with oleacc implemented we can run Selenium IE test case on Wine builtin / native IE to make a more compatible IE!
+ atom = result; + if(atom != result) + return E_FAIL;
I can't understand these few lines, are they typo or did I miss anything?
Also I cc'ed you on http://bugs.winehq.org/show_bug.cgi?id=30353 which is related to Selenium IE Driver and oleacc, hopefully you don't mind have a look :)
Thank you again!
On 04/25/14 13:34, Qian Hong wrote:
- atom = result;
- if(atom != result)
return E_FAIL;
I can't understand these few lines, are they typo or did I miss anything?
result and atom has different size. This code checks if LRESULT describes atom or error. It may be used in case of LresultFromObject failure.
On Fri, Apr 25, 2014 at 7:52 PM, Piotr Caban piotr.caban@gmail.com wrote:
result and atom has different size. This code checks if LRESULT describes atom or error. It may be used in case of LresultFromObject failure.
I see, thank you, glad to learn that :)
Piotr Caban piotr.caban@gmail.com wrote:
On 04/25/14 13:34, Qian Hong wrote:
- atom = result;
- if(atom != result)
return E_FAIL;
I can't understand these few lines, are they typo or did I miss anything?
result and atom has different size. This code checks if LRESULT describes atom or error.
GlobalGetAtomNameW should handle this just fine, 'atom' is a misleading intermediate variable IMO.
On 04/25/14 14:02, Dmitry Timoshkov wrote:
Piotr Caban piotr.caban@gmail.com wrote:
On 04/25/14 13:34, Qian Hong wrote:
- atom = result;
- if(atom != result)
return E_FAIL;
I can't understand these few lines, are they typo or did I miss anything?
result and atom has different size. This code checks if LRESULT describes atom or error.
GlobalGetAtomNameW should handle this just fine, 'atom' is a misleading intermediate variable IMO.
No, it's not handling it. It can happen that cast from an error code is a valid atom.
Piotr Caban piotr.caban@gmail.com wrote:
On 04/25/14 13:34, Qian Hong wrote:
- atom = result;
- if(atom != result)
return E_FAIL;
I can't understand these few lines, are they typo or did I miss anything?
result and atom has different size. This code checks if LRESULT describes atom or error.
GlobalGetAtomNameW should handle this just fine, 'atom' is a misleading intermediate variable IMO.
No, it's not handling it.
Why? Are there any casts in the way that break this?
It can happen that cast from an error code is a valid atom.
In that case a simple test for HIWORD(result) would look less convoluted.
On 04/25/2014 02:18 PM, Dmitry Timoshkov wrote:
Piotr Caban piotr.caban@gmail.com wrote:
On 04/25/14 13:34, Qian Hong wrote:
- atom = result;
- if(atom != result)
return E_FAIL;
I can't understand these few lines, are they typo or did I miss anything?
result and atom has different size. This code checks if LRESULT describes atom or error.
GlobalGetAtomNameW should handle this just fine, 'atom' is a misleading intermediate variable IMO.
No, it's not handling it.
Why? Are there any casts in the way that break this?
It can happen that cast from an error code is a valid atom.
In that case a simple test for HIWORD(result) would look less convoluted.
In principle that is correct but you cannot use HIWORD on a 64 bit integer. You'll need something like IS_INTATOM from kernel32 / ntdll.
bye michael
On 04/25/14 14:18, Dmitry Timoshkov wrote:
Piotr Caban piotr.caban@gmail.com wrote:
On 04/25/14 13:34, Qian Hong wrote:
- atom = result;
- if(atom != result)
return E_FAIL;
I can't understand these few lines, are they typo or did I miss anything?
result and atom has different size. This code checks if LRESULT describes atom or error.
GlobalGetAtomNameW should handle this just fine, 'atom' is a misleading intermediate variable IMO.
No, it's not handling it.
Why? Are there any casts in the way that break this?
It can happen that cast from an error code is a valid atom.
In that case a simple test for HIWORD(result) would look less convoluted.
I've sent improved version of the patch (try3). I think it addresses this issue.
Thanks, Piotr