If you try to run a .NET Compact Framework 2.0 application on Windows Mobile 5 Smartphone (ie no touch screen), you may get an error like this:

NotSupportedException at Microsoft.AGL.Common.MISC.HandleAr()

This is because Windows Mobile 5 actually comes in two 'editions' - Smartphone and PocketPC. Whether they're actually the same codebase I don't know, but depending on your device different functionality is supported. For example - the PocketPC menus you can build in the Mobile 5 SDK don't work on Smartphones.

So if you have an app with that error, either bug the software publisher to get a Smartphone version written with the simpler menus, or go buy a PocketPC phone with touch screen.

And if you're wondering - I have an Orange SPV C600 which is only the Smartphone version of WM5 :)

If you see an error about 'existing version alrady installed' then grab the .NET Compact v2 sp2 install - it seems as if the original install is a bit flaky on working out what version is already on the smarthphone.

So for some bizarre reason I decided to slap Tomcat on my Windows XP machine so that I could brush up my rather rusty Java skills with some web programming. Having recently had a remarkably pleasant install experience with MySQL I had high hopes for Tomcat.

So first I needed to work out what binaries I need. Please PLEASE Java world... realise that not everyone who wants to install your software is comfortable compiling stuff first and just maybe they'd like an easy link to the binaries! Yes I know they are there but it's not exactly obvious. Anyway - I got my ZIP package and ran my setup. It was like stepping back five years in time with a rather archaic install - but it seemed to do the job and after prompting me for the usual kind of things it was installed. Job done.

So I start it up and after it's entirely non-standard and rather obtuse status message it says 'Started'. Excellent. I hit the sample page. Server unavailable. No, I think... I said I started you.... restart the service. Same result. At this point I start to think maybe I've missed the point. Maybe I need Apache as well? Maybe I've utterly misunderstood what Tomcat is? It's a while since I last used it. A bit of googling later and I'm pretty sure I was right first time. This page should have worked.

Time to go digging. There's nothing in the Tomcat monitor to tell me anything is amiss. It seems to be hunky-dory. Well - I guess it seems so. There's no status messages or anything apart from 'started'. But it ain't working. So I start to refresh myself on the Tomcat directory structure and logs. There's a whole bunch of XML files containing various settings that I tweak and fiddle with - restarting Tomcat each time. I make progress, in a sense - Tomcat stops working altogether.

So I go back to all the originally installed files and start digging in logs. And then I find the problem in the catalina log. Not exactly the first thing that would spring to mind unless you knew what catalina meant and why, but there you go:

SEVERE: Error initializing endpoint
java.net.BindException: Address already in use: JVM_Bind:8080
 at org.apache.tomcat.util.net.JIoEndpoint.init(JIoEndpoint.java:501)
 at org.apache.coyote.http11.Http11Protocol.init(Http11Protocol.java:177)
 at org.apache.catalina.connector.Connector.initialize(Connector.java:1059)
 at org.apache.catalina.core.StandardService.initialize(StandardService.java:677)
 at org.apache.catalina.core.StandardServer.initialize(StandardServer.java:792)
 at org.apache.catalina.startup.Catalina.load(Catalina.java:518)
 at org.apache.catalina.startup.Catalina.load(Catalina.java:538)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
 at java.lang.reflect.Method.invoke(Unknown Source)
 at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:260)
 at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:412)
14-Aug-2007 09:17:30 org.apache.catalina.startup.Catalina load

I guess what this is trying to tell me is that port 8080 is already in use. A little netstat and process explorer later and I find that Sky AnyTime is using port 8080. In case you're wondering what that is - it's a PC-based service from my Satellite TV company that lets you download movies and stuff via a torrent-alike thing. Makes PERFECT sense for it to default to port 8080, which is commonly used for web servers. Makes even more perfect sense that it isn't configurable.

Oh well - at least Tomcat is, if you are happy to start cutting XML files. So a quick edit later and a couple of restarts due to a missed quote mark on one of my attributes, and Tomcat is running happily on port 9090. I hope. Of course, the shortcuts on the Start Menu don't work any more and aren't configurable, so I delete them all and create new ones and test my lovely new Tomcat.

Which now works pefectly :)  I grab a J2EE 'pre-configured' Eclipse and cut a quick hello world test. Yep - all is fine. Now to get down to some serious geekerism with Java, but I'm a little worried that the pain I felt just figuring out Tomcat and it's foibles is a taste of things to come...

So you've seen EPiTrace and very nice it is too. Especially as it's free. You've probably played with the live demo, downloaded it, followed the install instructions, created an EPiTrace page and voila! You got the following message:

Flash 8 required

This confused you as you're already running Flash 9. Well - the solution isn't anything to do with Flash itself. That error is just the contents of a div that gets replaced with the flash object once it's loaded. If the object doesn't load, then the message stays on-screen.

Thing is, there could be umpteen reasons why the movie doesn't load. And here's one... in the EPiTrace folder in your project you'll find a page called 'Application.aspx'. Have a look inside it and you'll see various references to /epitrace as an absolute path. If you're running your site in a virtual directory, then this of course won't find the resources it needs (like the flash object) and so you'll just see that standard 'flash 8 required' error.

To fix this, you could just hack the /epitrace references, but a cleaner option is to replace each of your absolute references such as

/epitrace/

with

And if you have the virtual directory issue then that should fix your problem.

Note that SWFObject is now at release 1.5 and supports background colours, and so you can now style the right-hand pane of EPiTrace with a nice colour instead of black if you like. Just replace the old SWFObject.js with the latest one and then add one more parameter to your 'new SWFObject' javascript call with the RGB value, e.g.:

var so = new SWFObject("<%= EPiServer.Global.EPConfig.RootDir %>epitrace/flash/epitrace.swf","epitrace","100%","100%","8","#AABBCC");

Note that I've also tweaked the path in the call to use a dynamic root.

Well I've been doing loads of pre-sales recently which has kept me off the development track - a necessary evil really. Thought I'd share a quick learning with you about a problem that sometimes happens with the Admin CSS in EPiServer.

On a project I'm doing alongside my colleagues, they set up EPiServer on a virtual directory on their default website, e.g. localhost/clientname/default.aspx. I was set up on the root a different site (but lets just say it was the default website, it doesnt matter), e.g. localhost/default.aspx.

I decided to change my project structure to match theirs, especially as the web.config referred to the root path which was different for me. Might as well be consistent. So I moved my EPiServer site into a virtual directory, grabbed a copy of their web.config and everything worked fine.

Almost.

I could log in fine to the admin site, but suddenly all my frames were weird sizes, my fonts were messed up and obviously a css was being missed somewhere. I had a look and it was System.css, and strangely that didn't even exist in the path it was looking!

Turns out I had forgotten to do something... set my 404 handler. For some reason the EPiServer devs decided to route System.css to System_template.css via the custom 404 handler. Well I set the 404 handler to the correct path and now it works fine.

Hope this helps someone!