tag:blogger.com,1999:blog-7433739558862985636.post606025758081653146..comments2024-03-24T09:33:15.490-07:00Comments on Rantings of a Selenium Contributor: Screenshots, SendKeys, and Sixty-Four BitsJim Evanshttp://www.blogger.com/profile/16744470953840993252noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-7433739558862985636.post-64786093184975366632016-03-09T02:38:59.165-08:002016-03-09T02:38:59.165-08:00Hi to all , just choose IEDriverServer_Win32_2.52...Hi to all , just choose IEDriverServer_Win32_2.52.1 Olga https://www.blogger.com/profile/12786539880627933587noreply@blogger.comtag:blogger.com,1999:blog-7433739558862985636.post-89787085641056036292016-01-11T15:31:49.806-08:002016-01-11T15:31:49.806-08:00Hey @Elmu: Consider toning it down some. Most of y...Hey @Elmu: Consider toning it down some. Most of your comments are coming across as extraordinarily rude. Perhaps you don't realize the tone.<br /><br />Regardless, why don't you spend some time contributing your ideas to the WebDriver project? In case you haven't noticed, all the project stakeholders happily accept reasonable pull requests.Jim Holmeshttps://www.blogger.com/profile/05869146736565695900noreply@blogger.comtag:blogger.com,1999:blog-7433739558862985636.post-16809142603354577852016-01-11T14:02:23.859-08:002016-01-11T14:02:23.859-08:00In response to your first assertion, how, exactly ...In response to your first assertion, how, exactly do you anticipate determining the hook can't be set? In the case of attempting to set a cross-bitness hook, SetWindowsHook *doesn't fail*. If it did, doing as you suggest would, in fact, be easy, and would have been implemented long ago. As it stands, the current implementation does check for the possibility of not being able to set the hook, and does log the issue. Whether the proper thing to do is rudely throw an exception (which would be a surprising change in existing behavior) is a matter for discussion in a different forum. I will not undertake the discussion here. <br /><br />As to your second assertion, the behavior you describe is a legacy of when the code in question was shared with the Firefox native events implementation. Now that it no longer is, perhaps changing to use SendMessageTimeout might be appropriate. If, y'know, you can get around the COM restriction from calling SendMessage or its derivatives from inside a COM message handler. <br /><br />On a personal note, I love comments that rudely call me incompetent. Honestly, it's uncalled for in a public place, and would be far better addressed in private. If you get paid to write code, I do hope your sense of professionalism is better at your place of employment than you've displayed here.Jim Evanshttps://www.blogger.com/profile/16744470953840993252noreply@blogger.comtag:blogger.com,1999:blog-7433739558862985636.post-29284727240963409902016-01-11T12:35:17.127-08:002016-01-11T12:35:17.127-08:00Hello Good article.
FIRST:
All you write is base...Hello Good article. <br /><br />FIRST:<br />All you write is based on sloppy programming style. If the driver would be programmed correctly it would notice that the hook could not be set and throw an exception "Please use the 32 bit driver instead on this computer." instead of typing 1 character per 5 seconds!<br /><br />SECOND:<br />It shows once again that the Selenium programmers are far from being Windows experts. What a nonsense to send keystrokes with PostMessage() and then implement a windows hook to check if the keystroke has been received! That is complete nonsense! <br /><br />The correct way would be to use SendMessage() instead. If they use PostMessage() for the reason that they think an event handler in Internet Explorer could eventually block the SendMessage() call, then there is a simple solution: SendMessageTimeout(). <br /><br />Remove this nonsense window hook and use SendMessageTimeout() and all is fine. This is very easy to fix! There is no need to hook another DLL into IE for something as basic as sending keystrokes to another process! Elmühttps://www.blogger.com/profile/14861142177093559353noreply@blogger.comtag:blogger.com,1999:blog-7433739558862985636.post-85655767617848690442015-12-24T02:32:00.229-08:002015-12-24T02:32:00.229-08:00I might suggest that it might be seen as convenien...I might suggest that it might be seen as convenient to have a single executable to allow the web driver to work. I am sure it is. However I think that for a lot of people who work in the test automation space, having a Selenium WebDriver that works reliably and predictably is considerably more important than how many files it consists of or whether it happens to use an installer or if it can run as a windows service.<br /><br />I can understand that it is a lot of work and IE is going to be sunset in the future. The reality is that with IE in general that a lot of organisations get stuck on old versions for a long time relative to the other browsers.<br /><br />Re-architecting the driver might also not be as bad if someone were willing to give you a hand...maybe..Anonymoushttps://www.blogger.com/profile/04464756156465286404noreply@blogger.comtag:blogger.com,1999:blog-7433739558862985636.post-60466815792326927142015-10-22T09:45:45.011-07:002015-10-22T09:45:45.011-07:00Thanks for the detailed explanation, Jim - excelle...Thanks for the detailed explanation, Jim - excellent article. <br /><br />Perhaps it would be worth adding an update since you fixed the screenshot issue in v2.47.0.3?<br /><br />It would also be good if #5876 could be updated with this fixed information too since it's one of the first links that appear in a Google search for issues with Selenium screenshots.<br /><br />(for others reading this page, see https://github.com/SeleniumHQ/selenium/blob/master/cpp/iedriverserver/CHANGELOG for fix details)Daniel Mhttps://www.blogger.com/profile/00658443933131714647noreply@blogger.com