JavaScript, Uncategorized, windows phone

WebBrowser.InvokeScript case study – running custom JavaScript

Last time I played with WebBrowser control (in WindowsPhone) as I wanted to automate navigation in some external web application. The first thought was to use InvokeScript method as it allows to run custom script. But the thing was not so obvious, that’s why I’d like to share my study here. Let’s start with a simple code snippet (WebBrowser is an instance of WebBrowser control):

script1

This code will throw System.SystemException: An unknows error has occurred. Error: 80020006. It appears that InvokeScript method can execute only functions that already exist. Weird, especially if you played with ExecuteScript in Selenium. So what, am I not able to execute my own code? Hopefully there is Javascript eval function:

script2

OK, now it’s better. Alert appeared. Let’s try to do something more than a single expression:

script3

Whew! Another success. What about returning values?  Failed! It returned empty string. Why not 2? Why empty string and not null? InvokeScript return type is object. Maybe I missed “return” keyword. Let’s check:

script5

Now there is: System.SystemException: An unknows error has occurred. Error: 80020101. After reading the Internet, I’ve found enigmatic: jQuery selector not working on Windows Phone 7. It seems that InvokeScript has problems with returning values from eval function. The solution here is to cast to string on JavaScript’s side

script6

Unfortunately it’s more complicated when we have more JavaScript to run as it should always cast to string:

script7

My approach to solve it was to use self executing function encapsulating the custom script. For better use of it let’f extract a method:

script8

Finally we have to remember about adding return keyword but that’s the price worth to pay.

Uncategorized

Use CapsLock to make your life easier

capslockisdeadReal professionals use keyboard only. It’s true, because it’s a lot faster if you don’t have to move your hand to find your mouse there and back. Unfortunately the mouse is not he only problem. There are still some useful keys, that lay far away from the homerow: Arrow keys, Navigation Keys, NumPad and a few other. That’s why “vim” exists – it makes you develop fast without moving hands far from the homerow. In our .NET world we have awesome VsVim plugin for Visual Studio, that enables vim mode in our IDE. In my opinion it gives you real performance boost if mixed with Resharper. Sadly, Resharper uses arrow keys for navigation.

And here is the place CapsLock can help. You can configure AutoHotKey to use CapsLock as a switch to simulate vim mode in the whole system. In my case when I hold CapsLock and press ‘j’ it emulates Down Arrow key. Everywhere!. It’s especially useful for:

  • all context menus
  • Intellisense autocomplete
  • quick edit dialogs (where VsVim does not work)
  • other system dialogs (like open file, explorer etc)

After using it for a while I cannot imagine my workday without it.

You can find the code here: https://github.com/chrisseroka/CapsLockVim. If you don’t want to install AutoHotKey there is also standalone executable: https://github.com/chrisseroka/CapsLockVim/blob/master/CapsLockWin.exe
Feel free to add new combinations.

Navigation:

    CapsLock + j: Down arrow
    CapsLock + k: Up arrow
    CapsLock + h: Left arrow
    CapsLock + l: Right arrow

Text selection:

    CapsLock + Left Alt + j:  same as Shift + Down arrow
    CapsLock + Left Alt + k:  same as Shift + Up arrow
    CapsLock + Left Alt + h:  same as Shift + Left arrow   
    CapsLock + Left Alt + l:  same as Shift + Right arrow

Remember to keep CapsLock pressed