Tuesday, November 1, 2011

Windows Live Writer

This is a post written using Windows Live Writer. I like the idea of having a local copy of my blog, it seems less ephemeral than cloud-based content.

Cool, it works. Of course this paragraph is written using the browser based tools, lets see if I can get the changes round trip back in Windows Live Writer. 

So the open recent post option in WLW fetches the changes from the blogspot. Groovy. Now let’s see if I can get it to download the entire blog.

It doesn’t look like I can download the entire blog and open it in WLW. But I can export it to atom format. So, it kinda works. WLW will let me open any existing post though. So I can save my blog locally, and edit any existing post. It’s almost the functionality that I was looking for, but not quite.

Saturday, September 10, 2011

Creating a crash dump from within the running process

 The idea is that a running application, as part of its error handling could create a dump, preserving interesting information.
Sometimes a stack trace just isn't enough.
I used F# just for funsies.
let something =
    System.Console.WriteLine("Hello")
    let thisProcess = System.Diagnostics.Process.Start("C:\Program Files\SysInternals\procdump.exe", "ConsoleApplication1 dump.dmp")
    thisProcess.WaitForExit()
    System.Console.WriteLine(System.Environment.CurrentDirectory)
    System.Console.ReadLine() 

Procdump is a sysinternals tool, and more suited to this than anything like WinDBG or ADPlus. 

Tuesday, August 9, 2011

How to get powershell syntax highlighting in HTML

Step 1: Use PowerGUI.
Aside from the code-highlighting, it's all kinds of awesome.
Step 2: Select the code
Step 3: From the Menu: Edit->Copy As->HTML
Step 4: Paste and enjoy in your Blog.

Finding locked files with OpenFiles

OpenFiles is a command line executable that has been around since XP. It isn't a powershell command so it doesn't produce nice PSObjects to play with, just raw text.

To find a particular file in the daunting amount of output, I do this:

OpenFiles | %{ if ($_.contains("search string")) { $_ } } 

Powershell locks loaded assemblies. Remove-Module doesn't help.

I was testing an assembly generated by Visual Studio. I imported the module into powershell via Import-Module, created the class I wanted, invoked its members, and viewed the results. Then I tweaked the project in Visual Studio and rebuilt. Powershell had the output assembly loaded and locked, so the build failed.

No news there.

The first workaround was to just close powershell and reopen it.

But! I figured I could call Remove-Module and get passed the lock without actually closing Powershell...
While this seemed like a good idea. It failed. Powershell didn't remove the lock it had on the imported assembly and it was still listed in the modules that Powershell was using. Remove-Module didn't remove the module. It just stopped showing up in Get-Modules. In fact, the variables created using the .net dll were still alive in the powershell process. Remove-Module was no solution.

Next! I figured that I would load the module inside of a powershell session and then unload the session.
Enable-PSRemoting
$session = $New-PSSession
Enter-PSSession $session
#Do Stuff
Exit-PSSession
Remove-PSSession $session

This failed as well. :(

Next I figured that I could create an AppDomain, create a Runspace in the AppDomain, do stuff, and then unload the AppDomain. I'm certain that this approach would work, but it isn't worth the time, especially since the following pseudo-shadow copy solution will work just fine:

$fileName = [System.IO.Path]::GetTempFileName()
[Environment]::CurrentDirectory = "myProjectDirectory\bin\x86\Debug"
[System.IO.File]::Copy("MyDll.dll", $fileName + ".dll")
Import-Module ($filename + ".dll")

And thus the module is loaded, and doesn't lock the Visual Studio output files.

Monday, March 21, 2011

Loading the functions from a powershell script into session memory

.
The answer is ".".
Used like this:
. .\ApowershellScript.ps1
And then within the same powershell session I could do this:
SomeFunctionFromTheAforementionedScript ARandomArgument
And it would work.

I had been calling Process.Start, but the call started failing once I tried adding the call to the powershell function within it.
So this did not work:
1 ProcessStartInfo info = new ProcessStartInfo("powershell.exe");
2 info.Arguments = "{ . C:\\LivingRoom\\ir.ps1; sendIR " + command + " }";
3 info.RedirectStandardError = true;
4 info.RedirectStandardOutput = true;
5
6 info.UseShellExecute = false;
7
8 System.Diagnostics.Process process = Process.Start(info);

So this is what I did get to work:

1 Runspace rs = RunspaceFactory.CreateRunspace();
2 rs.Open();
3
4 Pipeline pipeline = rs.CreatePipeline();
5 Command command3 = new Command(" . C:\\LivingRoom\\ir.ps1", true, false);
6 Command command4 = new Command(" sendir " + command, true);
7 pipeline.Commands.Add(command3);
8 pipeline.Commands.Add(command4);
9 pipeline.Invoke();

It's all about the .

In order to use a Runspace in C#, I had to know the super-secret location of the .net assembly that contained the Runspace code.
C:\Program Files\Reference Assemblies\Microsoft\WindowsPowerShell\v1.0\System.Management.Automation.dll
The fact that they hid it is this odd location is weird. :P
Oh well.

Sunday, March 20, 2011

CoffeeScript and Chirpy

I've found some things that I think are cool:
CoffeeScript 
and
Chirpy

CoffeeScript allows me to use a language other than javascript to write javascript.
Chirpy lets me write that not-javascript inside of Visual Studio. It also does neat things with javascript minimization and packaging.

Saturday, March 19, 2011

World of Warcraft Automation using Coded UI Tests from Visual Studio 2010

Previously I discussed automating repetitive tasks in World of Warcraft using powershell. While that works well, there are some situations where the only thing that will work is a mouse click. SendKeys makes it easy to send keyboard input to a window, but for some reason, I could not find an easy way of sending mouse input using a .Net API. "Easy" is the key word here, I could always try sending a message directly to the window through the Windows API, or involve some expensive third party automated testing tool.

I eventually stumbled upon a new feature in Visual Studio 2010: a coded UI test. The tests themselves are easy to create, the wizard in VS walks you through them excellently. There are plenty of resources on the net that describe how to use this feature in VS, so I'll spare you a redundant and feeble attempt at doing that, and show you how to integrate the result into a powershell script for easy manipulation.

The coded UI test runs very well inside of Visual Studio, but we need to run it externally. The compiled dll from the test project doesn't run by itself though, we require a utility called MSTest to run it.

The finished powershell script integrated with MSTest, looks like this:

Import-Module C:\Windows\Microsoft.NET\Framework64\v4.0.30319\WPF\UIAutomationClient.dll
$a  = [System.Windows.Automation.AutomationElement]::RootElement.FindAll([System.Windows.Automation.TreeScope]::Descendants, [System.Windows.Automation.Condition]::TrueCondition) 
$wow = $a | Where { $_.Current.Name -eq "World of Warcraft" } 
$pattern = $wow.GetCurrentPattern([System.Windows.Automation.WindowPattern]::Pattern)
$pattern.SetWindowVisualState([System.Windows.Automation.WindowVisualState]::Normal)
for($i = 0; $i -lt 80; $i++) { 
     $mstest = "C:\program files (x86)\Microsoft Visual Studio 10.0\common7\ide\mstest.exe"
     Push-Location
     Set-Location "C:\Users\Ogre\Desktop\SVN\Powershell Samples\"
     & $mstest "/testcontainer:testproject1.dll"
     Pop-Location
     Sleep 4
     [System.Windows.Forms.SendKeys]::SendWait("=")
}

The Visual Studio test project was compiled to testproject1.dll and the output was copied into the same directory as this powershell script.

Creating a dll for a particular UI action in World of Warcraft as shown here does take a bit of doing, it certainly isn't as easy as using SendKeys, but you can, using this technique, automate any action in the UI, even the ones that Blizzard ordinarily has blocked from macro and lua programmatic usage.

Note that this only allows for automation of mindless repetitive tasks, if you want a full fledged bot, this falls far short.

Tuesday, March 8, 2011

Android TV Remote

TV remotes are simple devices. All that it takes to make one is an IR emitting diode and a small amount of logic to make the diode blink at the right intervals for the TV to interpret.
The total cost of the materials involved in the construction of such a device is small, probably 5$ at the most. I recently bought a TV remote from Radio Shack and took it apart to confirm the components involved. The device was nearly entirely molded plastic and buttons, plus the one IR diode and the one small chip to control it.

Now, I'm a very lazy person, as this blog post clearly demonstrates, so instead of keeping track of many small fist sized electronic devices that are involved with remote communications, I only want to keep track of only one -- my phone.
This would be a wonderful brilliant solution and a major selling point for whatever phone had incorporated the 5 dollars worth of parts required to make this work, but alas, I know of no phone that currently incorporates an IR LED.
>:P

But my laziness will not be denied, so after a bit of searching on the interwebs, I found a company called global cache which makes devices that facilitate laziness. Particularly ethernet connected IR emitters. So my solution begins to look like this:
Brilliant! Except that is not what I'm going to do. For one thing I opted for a GC-100 which is wired, not wireless. It also connects a relay, a serial, and 3 IR ports via TCP/IP. One of the IR ports has to be used to connect an IR Blaster which actually emits the IR signal.
Brilliant! But android-java is not my forte. So I made a solution that looks like this:
Well, I've removed the whole point of this exercise, which is to control the TV from my phone, but I'll add that back in later. In the meantime, the powershell script is exactly what I want to prototype the application and test that this much, at least, does work.

$msgOnOff = "sendir,2:1,1,37000,1,1,333,167,21,20,21,20,21,61,21,20,21,20,21,20,21,20,21,20,21,61,21,20,21,20,21,61,21,61,21,61,21,20,21,61,21,20,21,20,21,20,21,20,21,20,21,20,21,20,21,20,21,61,21,61,21,61,21,61,21,61,21,61,21,61,21,61,21,1576,333,83,21,740" + [char]::ConvertFromUtf32(13)
$msgMute = "sendir,2:1,1,37000,1,1,333,166,21,20,21,20,21,62,21,20,21,20,21,20,21,20,21,20,21,62,21,20,21,20,21,62,21,62,21,62,21,20,21,62,21,20,21,62,21,20,21,62,21,62,21,20,21,20,21,20,21,62,21,20,21,62,21,20,21,20,21,62,21,62,21,62,21,1572,333,84,21,740" + [char]::ConvertFromUtf32(13)
$msg = $msgOnOff
$ipaddress = [System.Net.IPAddress]::Parse("192.168.1.70")
$ipendpoint = New-Object System.Net.IPEndPoint -ArgumentList $ipaddress, 4998
$addressFamily = [System.Net.Sockets.AddressFamily]::InterNetwork
$socketType = [System.Net.Sockets.SocketType]::Stream
$protocolType = [System.Net.Sockets.ProtocolType]::Tcp
$socket = New-Object System.Net.Sockets.Socket -ArgumentList $addressFamily, $socketType, $protocolType
$socket.Connect($ipaddress, 4998)
$bytes = [System.Text.ASCIIEncoding]::ASCII.GetBytes($msg)
#$bytes
$socket.Send($bytes)
$socket.Close()

Running this script enabled me to turn the TV on and off programmatically, proving that I had the hardware set up right and that the whole concept would work. The strings: $msgOnOff and $msgMute were taken from using an IR learner and Global Cache's eLearn software.  It took me a bit of fiddling to get the  [char]::ConvertFromUtf32(13) at the end of the strings figured out, and until I did, the script did not work. 


So the next thing that I did was set up a web service that would launch the powershell script. This would enable me to test the set up with a simple web page. That solution looked something like this: 

The web service code looks like this: 


1 [OperationContract]
2 [WebGet]
3 public void ToggleMute()
4 {
5     ProcessStartInfo info = new ProcessStartInfo("powershell.exe");
6     info.Arguments = "-f \"C:\\LivingRoom\\sendirMute.ps1\"";
7     info.RedirectStandardError = true;
8     info.RedirectStandardOutput = true;
9
10     info.UseShellExecute = false;
11
12     System.Diagnostics.Process process = Process.Start( info);
13     return;
14 }

 That code runs a bit slow, so there's about a one second delay between when you launch that code and the TV actually turns off (or mutes itself in this case). I'll have to revisit this in the future and see if I can get it to run more quickly using runspaces or some other trick. 


And then there's the ajax that I use to call the web service: 

    function OnOff() {
        $.ajax({
            url: 'LivingRoom.svc/ToggleOn',
            type: "GET",
            cache: false
        });
    }


Once I verified that this worked from a browser, I was able to publish the website to my local server, and browse to it with my phone's browser, and click on the button that I put on the web page and I finally had my phone operating as a TV remote. 

At this point, the solution works with any device that has a browser (blackberry, iphone, android, random laptop). I could use windows scheduler to toggle the mute or on/off at any time (though I don't know how that would be useful). But what I really want it a native android application that is the User Interface, and not a web page, so after creation of an Android App the solution looks like this: 


public class NotesList extends Activity {
    /** Called when the activity is first created. */
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);

        final Button button = (Button) findViewById(R.id.Button01);
        button.setOnClickListener(new OnClickListener() {
            public void onClick(View v) {
                HttpClient httpClient = new DefaultHttpClient();
                HttpContext localContext = new BasicHttpContext();
                HttpGet httpGet = new HttpGet("http://192.168.1.76/LivingRoom/LivingRoom.svc/ToggleMute");
                try {
                    httpClient.execute(httpGet, localContext);
                } catch (ClientProtocolException e) {
                    // TODO Auto-generated catch block
                    e.printStackTrace();
                } catch (IOException e) {
                    // TODO Auto-generated catch block
                    e.printStackTrace();
                }
            }
        });
    }
}


So I've created an Android based TV remote, woot. 

Here's a list of some of the technologies and programs that I used in this little exercise:
Powershell
IIS
aspnet_regiis.exe
Visual Studio 2010
Javascript/JQuery/Ajax
C# Web Service
Eclipse
Windows 7 
Ubuntu Linux
Android Java
Enterprise Architect (for the diagrams)
Paint (for prepping the diagrams)

Monday, February 28, 2011

Fun with HTML 5

Flash had to make up the difference between what I wanted to do on a web page and what I could do before HTML 5 for two things:
1) Playing sound.
2) Drawing on a canvas.

I had the sound working with flash using a small utility called sound manager. It was a pain, difficult to get working and keep working, but it did work in the end. However, the HTML 5 audio tag makes things easy and straightforward. For example:


1 <audio controls="controls" src="http://www.ogresoft.com/Japanese/TortoiseSVN_error.ogg" tabindex="0">
2 Your browser does not support the audio element.
3 </audio>





 If your browser doesn't support HTML 5, then go download a new one.

I never got the drawing canvas working. I considered processingjs, but HTML 5 came along before I got bored enough to make it work.

Ogresoft Kanji Quiz

So you can draw the kanji for the specified English word, instead of just a multiple choice scenario. I'll trust you to grade yourself correctly.

But my stuff is boring and rudimentary. Here are a couple of sites that do it right with canvases and drawing:
Harmony
and
Sketchpad
and here's another:

http://juliamap.googlelabs.com/

Monday, February 14, 2011

Stuff that I only use once every 6 months: XPath

It became convenient to manipulate some XML inside of a field in Sql Server (2008 r2) recently.
I found the XML datatype and the modify function which operates using XQuery. XQuery is a superset of XPath and both are w3c standards.
The silly field wasn't the XML data type already, it was just an nchar stuffed full of Xml.
The query that I wrote looked something like this when I was done:

1 CREATE TABLE T(TheXml XML)
2 GO
3
4 INSERT T SELECT CAST(code as XML) FROM some_table WHERE name = 'that thing that I was looking for'
5 GO
6
7 UPDATE T SET TheXml.Modify('delete /Object/Object/Object[@name="That one name"]/../Object')
8 GO
9
10 DROP TABLE T
11 GO

Most of my time was spent in the act of realizing that I needed to look for help on XPath and not some weird microsoft thing. The syntax that I needed (in this case "..") was easily found once I googled XPath.

Saturday, February 5, 2011

World of Warcraft automation using powershell

I have some crafting that I do in World of Warcraft that is repetitive, lucrative, and boring. If I sit at the keyboard doing it, I'm essentially just executing a for loop in my head. Not my idea of fun, especially when it could be an opportunity to hone my 'leet programming skills.

I used to automate this activity with AutoHotKey (AHK). It worked great, however, it was a new pseudo-programming language that I had to learn, and a very specific one at that. I've done some neat things with AutoHotKey, but I would prefer to use something like powershell instead. Powershell has the advantage that it can be used in a much broader set of domains than AutoHotKey, and therefor more likely to be useful to me in the future for some as of yet unknown task. I had toyed with the idea of embedding AHK inside of powershell and executing AHK commands within a powershell script, but I have found a better solution.

Up until .net 4.0 I had considered making AHK commands embeddable in Powershell. But! .net 4.0 brings us the System.Windows.Automation namespace.

With this small bit of knowledge, I was able to craft the following sample:


Import-Module C:\Windows\Microsoft.NET\Framework64\v4.0.30319\WPF\UIAutomationClient.dll
$a  = [System.Windows.Automation.AutomationElement]::RootElement.FindAll([System.Windows.Automation.TreeScope]::Descendants, [System.Windows.Automation.Condition]::TrueCondition)
$wow = $a | Where { $_.Current.Name -eq "World of Warcraft" }
$pattern = $wow.GetCurrentPattern([System.Windows.Automation.WindowPattern]::Pattern)
$pattern.SetWindowVisualState([System.Windows.Automation.WindowVisualState]::Normal)
[System.Windows.Forms.SendKeys]::SendWait("{Enter}Hi{Enter}")

Making my character say "Hi", isn't terribly useful, but it illustrates how I could send any sort of command at all to Wow.

This uses .Net 4.0 which screws up in most default configurations of powershell and powershell editors. In order to configure your powershell environment to run on .net 4.0 and be able to run this script, add the following configuration file to your editor of choice.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
<startup>
<supportedRuntime version="v4.0.30319" />
</startup>
</configuration>

A more thorough discussion of .net 4.0 and powershell.

That config file wasn't working with PowerGUI though. I had to resort to the registry keys:

New-ItemProperty -Name "OnlyUseLatestCLR" -Value 1 -Path "HKLM:\software\wow6432node\microsoft\.netframework\"
New-ItemProperty -Name "OnlyUseLatestCLR" -Value 1 -Path "HKLM:\software\microsoft\.netframework\"

Sunday, January 30, 2011

Android TV Remote - Failure one

, I decided my phone should also act like a TV remote. The first problem with that is the missing hardware. It doesn't have an IR emitter. After a brief search, I decided that Android Phone - IR Emitter integration didn't exist, and I proceeded to begin building my own.

 My first attempt was to buy a 20$ universal remote from radio shack and attempt to wire up the buttons so that I could invoke them digitally. I took apart the remote and discovered that it was essentially a single board with an IR emitter at the front. I glued wires to the button contacts and glued the wires to the board with hot melt glue so that the fragile wire-glue connections would not break.

I connected the wires to a breadboard and could push the buttons electronically with the digital out from an arduino. I could then hook the arduino up to a webservice and I would have the first iteration of a working android/web phone remote.

 But! Then I saw this product from Global-Cache GC-100. It allows serial, IR, and other devices to be hooked up to an ethernet network and accessed remotely. So, although wiring up a TV remote to an arduino was fun, challenging, and a useful trick to have in my arsenal, it also wasn't better than the existing commercial solution. I have abandoned this avenue of attack and ordered a GC-100.