Added ability to use element in << operator

[soerennielsen]

Added ability to use an IWebElement as left hand side of an << operator
in addition to a cssSelector string.

Added matching test case.

Fixed another "pluggable finder test" that failed a bit.

[lefthandedgoat]

In your test you are doing an equality check on IWebElement == "John"

!^ testpage
let lastname = element "#lastname"
clear lastname   
lastname << "John"
lastname == "John"

Thats not currently supported but I could add support if you like.

[lefthandedgoat]

I fixed the test and I will build a new nuget w/o that Iwebelement == "text". If you would like that feature then open an issue and I will add it, or you can add it and send a PR.

Thanks for this contribution!

[soerennielsen]

Thanks.

Strange about that test. It did complete successfully in my tests. Strange. Perhaps I messed it up somehow ;)

I don't need that specific test for now.

My use case was that I have to run a small bit of test code a number of times. In that code I need to get the elements to read their y coordinates and execute some js. Then I change their value by getting the id and concatening '#' to get a CSS selector.
Now that bit is a lot cleaner :)

/soeren

-----Original Message-----
From: "lefthandedgoat" [email protected]
Sent: ‎18-‎05-‎2014 20:41
To: "lefthandedgoat/canopy" [email protected]
Cc: "soerennielsen" [email protected]
Subject: Re: [canopy] Added ability to use element in << operator (#151)

I fixed the test and I will build a new nuget w/o that Iwebelement == "text". If you would like that feature then open an issue and I will add it, or you can add it and send a PR.
Thanks for this contribution!
—
Reply to this email directly or view it on GitHub.

[lefthandedgoat]

I am having problems building a nuget package that works in VS 2013, 2012, and 2010 apps. I am building a build server now to try to eliminate my machine as being the source of the problem. It may be a few days before I get a working nuget package out there.

[soerennielsen]

Og, that can sometimes be quite a long job to build a complete new build server.

In my experience it always pays off afterwards though.

I find that the easiest option is if you're allowed to just install the various versions of visual studio. Otherwise you have to copy msbuikd files and targets from another dev machine. Tedious.

Let me know if there is anything I can do.

/soeren

-----Original Message-----
From: "lefthandedgoat" [email protected]
Sent: ‎19-‎05-‎2014 17:47
To: "lefthandedgoat/canopy" [email protected]
Cc: "soerennielsen" [email protected]
Subject: Re: [canopy] Added ability to use element in << operator (#151)

I am having problems building a nuget package that works in VS 2013, 2012, and 2010 apps. I am building a build server now to try to eliminate my machine as being the source of the problem. It may be a few days before I get a working nuget package out there.
—
Reply to this email directly or view it on GitHub.

[lefthandedgoat]

I finally figured it out. The solution file chooses what version of F# to compile with, 3.0 or 3.1 based off of the VS version #. I seems to pick based on the version of VS that you have open when you build, and if you build via command line, what is the latest version you have installed. Thus it was always picking F# 3.1 which won't work with VS 2010. I changed the build script to force VS 11.0 and the problem is now resolved. Sorry for the delay!

This is now in canopy 0.9.10 https://www.nuget.org/packages/canopy/0.9.10