Not surprisingly the valley of the Pequest was not the only natural obstacle faced by the engineers of the DL&W. Just 12.5 miles west of where the fill rejoined the mountainside at Greendel they had to leap another river valley, this time that of the Paulinskill. The word “kill” when referencing a river or stream derives from the Middle Dutch word “kille”, and that hints at the early role this watercourse played in providing a route to the south for Dutch and German immigrants from the settlements in the Hudson River valley to the northeast. They came seeking land to farm, and metals to mine, and they found both, here, and in far greater quantities as their descendants moved westward into Pennsylvania.

The valley of the Paulinskill was the last major obstacle before the DL&W’s new route would leap the Delaware, and fortunately it was not so daunting a challenge as the Pequest had been. At barely a quarter mile wide it could be crossed by a bridge, and so it was. The resulting span was at one time the largest reinforced concrete structure in the world. Variously known as the Paulinskill Viaduct, or the Hainesburg Viaduct, the bridge still sits there, casting its broad shadow across a river frequented by fly casters and kayakers. Unused since the road was abandoned by Conrail in 1984, it has now become perhaps the worlds largest planter. A few weeks ago I decided to head out and have a walk around, and if I could manage it, out onto, the Paulinskill Viaduct.

The structure itself is easily spotted in Google Earth, especially if you know the route of the cut-off. Getting to it is a matter of following a winding trail of scenic rural highways so characteristic of this part of New Jersey. Eventually you drop down onto Station Road and follow the edge of the valley around the shoulder of a hill , the river winding its way on your left, huge trees blocking out nearly all view of the sky, and suddenly there it is: a massive, crumbling concrete edifice reminiscent of some post-apocalyptic Roman aqueduct. Just under the span, between two huge pillars, frequent use has carved out a small dirt parking area. I pulled the truck in, parked next to the trucks of fishermen and the Subarus of kayakers, climbed out, and looked up.

My first thought was: holy crap that is a lot of concrete over my head. My second thought was along the lines of “someday that’s coming down.” It then also occurred to me that I had watched maybe one too many episodes of “Life After People” on the Mystory Channel. Yes, it is going to come down, but it’s not coming down anytime soon barring some geological event. Structures like this, and dams, and perhaps even superhighways, become a permanent part of the landscape. Miraculously transport yourself 20,000 years into the future and visit this spot and you’ll nod and say “Yep, that’s the Paulinskill Viaduct,” even if it is no more than a straight line of rubble at the lower end of a small lake.

The bridge itself feels right in place with all the abandoned remnants of past industrial prowess that can be found tucked here and there in this urban-accessible stretch of very beautiful, very rural countryside. Various partiers have covered its flanks in graffiti. Wierd NJ has published lurid tales of possible demonic ceremonies deep within the hollow pillars and damp service walkways, and this has led to round after round of board-it-up/tear-it-down as the adventurous and credulous try to penetrate its interior reaches. The area itself seems scoured, the brush around the bridge ground down by legions of feet, beer cans and bits of household refuse scattered in the little recesses where the concrete forms corners, presumably protected from the passing gaze of patrolling police.

After getting a few pictures I turned my eyes upward. I wanted to see what the view was like from the top of this thing for the same reason that I had hiked out onto the Fill: because that was the most visceral possible impression of it. Stand at the base of a sky-scraping office tower and look up, and you’ll be impressed. Stand at the rim of its uppermost terrace and look down, and I guarantee you will be more impressed. I wanted to stand on the Paulinskill Viaduct and look down. But for the moment there didn’t seem to be any easy way up.

I started to work my way up the side of the valley under the bridge. The ground had been scraped clear, and the gnarled roots of huge trees made for convenient footholds, but the way soon grew very steep and I found myself hauling my weight up by the arms. I used to be able to do that without feeling as if my lungs would explode. About halfway to the top a trail cut off to the right and followed a steep dry wash up to the level of roadbed. As I stepped out onto it I first looked east, and saw essentially the same view as on the Greendel end of the Fill: a cinder-black, narrow, very torn-up trail that is all that remains of the roadbed itself.

To the west the bridge, grass-covered and with mature trees growing along its entire length, presented a spectacle at once awe-inspiring and melancholy. A gate had been placed across the approaches but had long since been driven into the dirt. Out in the middle of the span a group of ATV riders had stopped to appreciate the view. The Lackawanna Cut-off is one long race track for them, from the Andover side of the Fill all the way to the Delaware. That may end someday if New Jersey Transit follows through on plans to re-open the Cut-off for a route to Scranton. If they do, they will have a lot of work to do on the Viaduct.

Everywhere the bridge shows the effects of age, disuse, and vandalism. Concrete is crumbling from erosion and trauma. The thick iron piping that formed the safety railing has in many places been pried or wrenched out, leaving an unprotected drop of 80-100 feet to rocks or the river. This is not a place you want to bring small children who aren’t leashed to you. The roadbed itself is just a dirt trail, indistinguishable from any other trail through New Jersey woodland, save for the concrete on either side, and the occasional open manhole that gives access to the drainage and service areas below. The previously mentioned trees lend an air of unreality to the scene. What are they doing here, 100 feet above the river on this concrete thing? I think the Mystory Channel people must have come here at least once.

The view from the center of the span is worth the climb. I hesitate to say that for fear that someone will read this, go out there, and get hurt or arrested. So before I say more let me add: the bridge is very dangerous, and you are not supposed to be out on it. If you go out on it, then your life and criminal record are in your hands, not mine. If you do, then when you reach the middle you’ll be rewarded by impressive views of the Paulinskill valley for maybe ten miles in either direction. To the west you’ll see Kittatinny Mountain and the Water Gap. Yeah, it’s worth it. But stay away from the edge, and watch for manholes. They tend to pop up at your feet, and I can’t say with perfect confidence how far you’ll fall if you step into any of them.

Back down in the valley, and quite a bit more breathless than when I arrived, I walked out under the bridge to the river, and looked up again, this time with a more critical eye. Yes, NJT will have their work cut out for them with the viaduct. The bridge is dying. The interior drainage system has failed in many places, corroded away or clogged into uselessness. Undirected flows of water are the enemy of all man-made structures, and concrete bridges are no exception. Water drips from seams between poured sections, and finds its way along rusty reinforcing rod, dissolving it until the rod is gone and only the water remains, forcing an ever-wider path for itself. Chunks of concrete have been pried loose by the seasonal forces of New Jersey’s climate.

So yes, unless NJT actually does rehab the bridge, it’s going to come down. If they don’t, then eventually someone is going to have to knock it down, or keep people out of the valley, and off the roadbed. That seems impossible, and maybe building a railroad to Scranton is easier. In the meantime it stands here with its furry crown of misplaced forest, a monument to a time when nothing, not a 3.5 mile-wide valley, and certainly not a comparatively puny little river crossing, was going to stand in the way of opening the west to American progress. The railroads of Northern New Jersey almost universally went broke. There were other routes west, easier routes, to the south and north, and none of these constructions in the long run did anybody any lasting good. But here they are, like so many other Ozymandian inventions, and as long as they are here people like me are going to be drawn to them, hearing some faint echo of the hopes and dreams of an earlier time.

You can view the full gallery of images from my visit to the Paulinskill Viaduct here.

As you continue north past Lake Tranquility, another of those quirky little resort towns that grew up around New Jersey lakes before there was such a thing as subdivisions and suburbia, you can’t help but notice that the gentle progress of the valley seems to be interrupted by something very high, very straight, and very flat. As you get close it seems almost as if someone has thrown a massive earthwork across the valley from mountain to mountain, and then let nature have its way. This is what Hadrian would have built, with a million more men and fifty more years, because this damn well would have kept the Scots out. Not far from where you gaze up in wonder 517 punches under this massive edifice in a narrow tunnel and continues ascending the valley.

Instead of following it you take a left on Kennedy Road and rumble northwestward, parallel to the earthwork that reaches heights of 110 feet not far to the right, until you reach the town of Greendell. Greendell is a quiet little burg hugging a country crossroads, with little left of whatever bustle and prosperity it may once have had, and although you may not know it yet, the coming and going of that prosperity, like the rise and fall of many another little milltown in the Highlands, had a lot to do with that impossibly big mound of dirt you’ve been tracking. Taking a right on Wolf Corner Road you spot a thin, gray line on the GPS, crossing the road at nearly a right angle, and then suddenly you’ve come to a wider spot next to a chain link fence, with room to park. You hop out and pretend not to notice the sign that says “State Property – No Trespassing.” Around the end of the fence and over a mudhole between two bushes and you’re looking at a little concrete railway station with a green roof.

This is the Greendell station of the Delaware, Lackawanna, and Western Railroad, opened in 1911, closed in 1934, and never of much use to anyone since. A muddy, cinder-black trail leads eastward past a concrete ramp and platform where cars were loaded during the brief time that the DL&W tried to serve Greendell. Bits of railroading history begin to appear here and there: concrete tower mounts, chair plates, old bolts and ties, lots of ties. Not very far along the muddy and undulating trail you see the remains of the Greendell Tower, its reinforced concrete shell as completely durable as every other structure the DL&W built when they made this line in 1911. It, and the station, stand as lonely sentinels on the western approaches to one of the most audacious, and remarkable feats of railroad engineering ever undertaken: the Pequest Fill.

When William Truesdale took over as chief of the DL&W in 1899 he confronted a serious problem. The railroad’s current mainline, known as the “old road” even then, had been built in 1856 on a circuitous route through Washington and Oxford to the Delaware River at Delaware, NJ. It was plagued by steep grades, low clearances, inadequate right of way, and most critically, by two choke-point tunnels at Oxford and Manunkachunk that could not be easily improved. The original logic behind the route, to make the railroad easily available for a connection with the CRNJ when a supposedly inevitable merger between the two roads was consummated, no longer applied when, by 1890, the merger was clearly evitable. Around 1905 planning began for a replacement route. More than a dozen potential routes were surveyed, nearly all of which would require more tunnelling than the current line. It’s an unfortunate fact for railroad engineers trying to get across northern New Jersey from east to west: you keep running into great piles of rock covered with trees.

As planning continued all of these other routes were rejected for obvious reasons, leaving only the one plan that nobody thought was possible. The route envisioned by this plan would be perfect: 11 miles shorter, with no grade steeper than 1.1%, and no curve that couldn’t be taken at 70 MPH by the steam-driven behemoths of the time. There was just this one little problem with the route: the Pequest Valley made a distinct, 3.8 mile wide, 120 foot deep gash right down the middle of it. If you have a railroad route running straight as an arrow at 750 feet above sea level, and you run into the valley of a river that is at 640 feet above sea level at the place where you have to cross it, then you have a 110 foot problem. This is the sort of problem that the average railroad engineer would solve with a trestle. But 3.8 miles is very long for a trestle. It would have required one hell of an expensive trestle, and it was that which had relegated this plan to the dustbin, until someone came up with a slight alteration to it: they would fill the valley with dirt.

In 1909 or 1910 the railroad began construction on what was known as the Lackawanna Cut-off, along with various other names. To span the valley of the Pequest the engineers required 6.6 million cubic yards of fill. To provide this fill the railroad acquired farm land, which they dug up as “borrow pits” to get the earth and rock they needed. Many of these pits became ponds which stud the landscape to this day. The bank itself would be an average of 110 feet high, and wide enough at the top for a double-tracked mainline and service road. At the base it was nearly 500 feet across, enough to completely bury the Huntsville schoolhouse, for which community the railroad agreed to build another. The original is still down there, entombed in the fill. To get the material to the spot and build a railroad required a railroad to transport it all, and so they stretched a cable across the valley and hung a set of tracks from it, onto which a small engine pushed cars loaded with fill which was dumped from the swaying platform more than 100 feet above the valley floor.

The enterprise was the marvel of its time, and remains the single largest railroad fill ever undertaken. Newspapers wrote awestruck articles, and foreign governments sent representatives to view the plans and methods, just as they had sent them to the inclined planes of the Morris Canal 70 or so years before. The Pequest Fill was the kind of thing that could only happen in the age of the great industrialists, when progress seemed the only worthy goal. The people of the Pequest Valley, by and large, were probably pleased with the arrival of the railroad and the possibility of prosperity. Some must have grumbled, too, at the bisecting of the valley and permanent replacement of the northward vista with an earthen dike. Try the same thing today and you’d be laughed out of the room or fired for even proposing it. Back then it made sense: there was anthracite coal in Pennsylvania, needed by the forges, furnaces, and factories of the northeast, and the DL&W needed a faster, straighter way to get to it.

My reason for coming to this spot on a day in May not long ago was twofold: on one hand I simply enjoy unravelling a mystery and following an old way to see where it leads; on the other, I wanted to walk out onto this thing and get a visceral sense of how big it really is. Over two and a half hours of a beautiful late spring afternoon I hiked 3.5 miles out from Greendell station, and 3.5 miles back. That took me to about the 3/4 point on the run to Andover, by which time I was pretty worn. It’s a strenuous walk, with the trail overhung by thick brush in places, and made rough and muddy by scores of ATVs that use the fill as a racetrack. Along the way I viewed the remains of a road that was a pivotal link in the northeast from 1911 until Conrail finally dismantled it on July 31 of 1984. I listened to the sounds of lawnmowers and kids in swimming pools floating up from far below me, looked down on farms and houses and sheds, and eventually I had my answer.  The answer is that the Pequest Fill is really, really huge. You can’t comprehend it until you’re out on the middle of it and looking down at the top of a tall silo in the yard of a farm 110 feet below. It’s mind-boggling, and it will be here in some form or other, I think, as long as there’s an earth, or at least as long as there’s a continent to hold it up. Never have so many worked so hard to pile so much dirt in one place.

If you’re interested in the history of the Lackawanna Cut-off and the story of the fill’s construction, you could do no better than to start with the Garden State Model Railroad Club’s page on the topic. There is also an excellent article on Wikipedia. In general there is a lot of information out there on the cut-off and the fill, all of it a lot more accurate and insightful than what I have here. You can also view the gallery of images from my hike.

If you plan on seeing the fill for yourself, a couple of words of warning before you go are appropriate. First, the right of way is now owned lock, stock, and barrel by the State of New Jersey on behalf of New Jersey Transit, which continues to discuss plans for rebuilding the cut-off to provide service all the way to Scranton. Only the area around the Greendell Station is posted, which is why I stayed out of the structure. Whether they want you walking out on the fill is a question I can’t answer. I’ve been there twice, parking on the side of the road by the station, and nobody has hassled me, just as they apparently do not hassle the ten or twelve ATVs and motorcycles that passed me at high speed during my walk. Which brings me to the second point: ATVs have torn the crap out of the service road. It’s muddy, and full of bumps and moguls, and makes for very tough walking, not to mention the danger of getting hit. Fortunately you can hear them coming a ways off.

When I started thinking about the plumbing needed to connect a DragHandle’s motion to the properties of a shape, I decided I wanted something that would be as generic, high-level, and simple as possible. I immediately noticed a couple of problems. For one thing, I had designed the DragHandle class to provide a Point in the arguments to the events it raises. The Point contains the new position of the handle, and is the source of information that I want to feed to the shapes. In fact, it will be helpful for understanding the rest of this if you think of a DragHandle as a source of two channels of information: changes on the x-axis, and changes on the y-axis. I’ll speak to that more later on.

Point is a good choice for some shape properties. An ellipse uses Point for its center, for example. But other properties are discrete coordinates, or distances. A line uses four doubles (x1,y1) (x2,y2) to specify its ends. And a rectangle uses a rect with a Point for location, and a width and height expressed as doubles. The location of all shapes in a Canvas is expressed as two doubles. So there isn’t always a direct mapping. I should mention here that all the shapes in my application are Paths, so in this case I am really speaking of LineGeometry, EllipseGeometry, and RectangleGeometry. The simple shapes Line, Ellipse, and Rectangle present a similar challenge.

Things got more complicated when I realized I did not want to connect DragHandles to just classes derived from Shape. I wanted to be able to feed information to any DependencyObject. This came about because I was in the process of writing my gradient editor, when it dawned on me that I wanted the DragHandles to affect the GradientBrush properties directly. Those properties are all in a normalized 0 – 1.0 coordinate space. So not only are there different types of properties, but there are different frames of reference as well. It was obvious I needed some kind of layer between the DragHandle and the object it was manipulating, that would be capable of transforming the axis information and passing it on to the right properties.

Enter the DragHandleConnector class, and its close relatives: DragHandleConnection and DragHandleTarget. Here’s a class diagram to illustrate the relationship between these types and the DependencyObjects they operate on:

In a nutshell, it works like this: DragHandleConnector is attached to a DragHandle, and subscribes to its Drag event. DragHandleConnector maintains a list of DragHandleConnections. Each DragHandleConnection represents a logical property of an object we want to manipulate. I say “logical property” because sometimes when we want to move something – the end of a Line for example – we have to update two DependencyProperties. This is accomodated by the DragHandleTarget class, which DragHandleConnection maintains a list of. Here’s what that class looks like:

public enum SourceAxes
{
	X,
	Y,
	Both
};

public class DragHandleTarget
{
	public DragHandleTarget( DependencyProperty p, DependencyObject o,
		SourceAxes s )
	{
		Property = p;
		Owner = o;
		Axes = s;
	}

	public DependencyProperty Property { get; set; }

	public DependencyObject Owner { get; set; }

	public SourceAxes Axes { get; set; }
}

DragHandleTarget is basically three properties and a constructor, but they are the three properties that make everything else work: Property contains the DependencyProperty that the target will set when the DragHandle changes; Owner contains the DependencyObject that owns the DP, giving us the two pieces of information needed to call SetValue to set the property. Finally, Axes contains a property of type SourceAxes. SourceAxes is an enum that specifies which channels of information from the DragHandle are passed to SetValue when something changes. The three possibilities are X, Y, or both. It boils down to this: if Axes is set to SourceAxes.X, then the target DP must be a double, and the value of the X axis will be passed to SetValue. SourceAxes.Y means the same thing for the Y axis. SourceAxes.Both requires that the target DP be a Point, and the value passed to SetValue will be a Point. DragHandleTarget encapsulates all of the information needed to update one DependencyProperty with one or both values from a DragHandle event.

DragHandleConnection represents a set of DragHandleTargets, and a callback to call when a new value is about to be passed down to the targets. Here it is:

public class DragHandleConnection
{
	public void AddTarget(DependencyProperty p, DependencyObject o,
		SourceAxes s)
	{
		_targets.Add( new DragHandleTarget(p, o, s) );
	}

	public CoercePointCallback CoercePoint;

	public List<DragHandleTarget> Targets
	{
		get { return _targets; }
	}

	List<DragHandleTarget> _targets = new List<DragHandleTarget>();
}

Again this is a very simple class. It contains a list of targets and a method to add targets, which simply streamlines usage, and the callback I mentioned. DragHandleConnection and DragHandleTarget solve one of the problems I talked about before: having to “carve up” a Point and send its values to different DPs (such as Line.X1Property and Line.Y1Property). The callback solves the other big problem by giving the calling code an opportunity to modify the Point generated by the DragHandle before it is passed on to the target DPs. For example, when I was using a DragHandle to modify the properties of a GradientBrush I had to convert the Canvas-relative coordinates to a 0 – 1.0 coordinate space. This is done in the callback. Here’s what the flow of activity looks like when this mechanism receives a Drag event from the DragHandle:

The overall control of this whole process is delegated to DragHandleConnector, which is meant to represent all the connections and all the targets associated with the functioning of one DragHandle. In the gradient editor I have DragHandles that each control an endpoint of a Line, as well as a property of a GradientBrush. So each of these has one DragHandleConnector, which has two DragHandleConnections. The connection with the LineGeometry object has two DragHandleTargets: one for Line.X2Property; and one for Line.X1Property. The connection with the GradientBrush has one DragHandle target – a property such as GradientBrush.OffsetProperty – and a callback to modify the coordinate space. Here is the declaration of the DragHandleConnector class:

public class DragHandleConnector
{
	public DragHandleConnector( DragHandle dh )
	{
		SetHandle( dh );
	}

	public void Disconnect()
	{
		if (null != _dh)
		_dh.Drag -= new EventHandler<DragHandleEventArgs>(DragHandle_Drag);
	}

	public DragHandle Handle
	{
		get { return _dh; }
		set { SetHandle(value); }
	}

	public List<DragHandleConnection> Connections
	{
		get { return _connections; }
	}

	private void SetHandle( DragHandle dh )
	{
		Disconnect();
		_dh = dh;
		_dh.Drag += new EventHandler<DragHandleEventArgs>(DragHandle_Drag);
	}

	private void DragHandle_Drag( object sender, DragHandleEventArgs e )
	{
		for( int i = 0; i < _connections.Count; i++ )
		{
			Point p;
			DragHandleConnection d = _connections[i];

			if (null != d.CoercePoint)
				p = d.CoercePoint(e.Position);
			else
				p = e.Position;  

			for ( int j = 0; j < d.Targets.Count; j++ )
			{
				DragHandleTarget t = d.Targets[j];
				switch ( t.Axes )
				{
					case SourceAxes.Both:
						t.Owner.SetValue(t.Property, p);
						break;

					case SourceAxes.X:
						t.Owner.SetValue(t.Property, p.X);
						break;

					case SourceAxes.Y:
						t.Owner.SetValue(t.Property, p.Y);
						break;
				}
			}
		}
	}

	private DragHandle _dh;
	private List<DragHandleConnection> _connections =
	new List<DragHandleConnection>();
}

There’s not too much to pick apart here. All the important stuff happens in the event handler for DragHandle.Drag. Essentially the connector runs through all the connections and for each it calls the callback if there is one, then visits each target and passes the coerced Point to the appropriate DependencyProperty. Before I run out of vertical whitespace for this post, lets look at how it all comes together in a demo… assuming I can get SL to work in a WordPress post… ah, there we are. If you see a Silverlight logo instead of the demo you need to install Silverlight 2.

If you have Silverlight 2 installed then what you see above is a single DragHandle, four Lines, and two TextBlocks. Go ahead and use the mouse to drag the lines around. This DragHandle has a single DragHandleConnector with four DragHandleConnections; one to the end point of each Line. To update the position and contents of the TextBlocks the demo hooks the DragHandle.Drag event. You could use the CoercePoint callback for this, but it would be a little misleading to convert numeric data into text and stick it into a textblock as a side-effect, so I decided to handle Drag. What this means is that there are two handlers hooked to the Drag event, and I think overall the performance here isn’t as good as in the gradient editor where there are no expensive numeric-to-text conversions being done whenever the handle is moved. But it does illustrate most of the stuff I’ve talked about. I’ll wrap this post up with the code for the demo. First the (very simple) xaml:

<UserControl x:Class="DragHandleDemo.Page"
	xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
	xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
	SizeChanged="UserControl_SizeChanged">
	<Grid>
		<Canvas x:Name="DhCanvas" Background="White">
			<TextBlock x:Name="Xlabel" />
			<TextBlock x:Name="Ylabel" />
		</Canvas>
	</Grid>
</UserControl>

As you can see the markup is just the Canvas to move the handle around on, and the two TextBlocks. The code-behind is where you see everything coming together:

using System;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Input;
using System.Windows.Media;
using System.Windows.Shapes;
using DrawControls;

namespace DragHandleDemo
{
	public partial class Page : UserControl
	{
		public Page()
		{
			InitializeComponent();
		}

		private void UserControl_SizeChanged(object sender, SizeChangedEventArgs e)
		{
			BuildDemo();
		}

		private void AddLine( double x, double y, DragHandleConnector d )
		{
			Line l = new Line();
			l.Stroke = new SolidColorBrush(Colors.Black);
			l.X1 = x;
			l.Y1 = y;
			l.X2 = DhCanvas.ActualWidth / 2;
			l.Y2 = DhCanvas.ActualHeight / 2;

			DragHandleConnection dhconn = new DragHandleConnection();
			dhconn.AddTarget(Line.X2Property, l, SourceAxes.X);
			dhconn.AddTarget(Line.Y2Property, l, SourceAxes.Y);
			d.Connections.Add(dhconn);

			DhCanvas.Children.Add(l);
		}

		private void InitLabels()
		{
			double x = (DhCanvas.ActualWidth / 2);
			double y = (DhCanvas.ActualHeight / 2);
			Canvas.SetLeft(Xlabel, x + 20);
			Canvas.SetTop(Xlabel, y - 7);
			Canvas.SetLeft(Ylabel, x + 40);
			Canvas.SetTop(Ylabel, y - 7);
			Xlabel.Text = x.ToString();
			Ylabel.Text = ", " + y.ToString();
		}

		private void BuildDemo()
		{
			InitLabels();

			DragHandle dh = new DragHandle(new Point(DhCanvas.ActualWidth / 2,
			DhCanvas.ActualHeight / 2));
			dh.HandleShape = new Ellipse();
			dh.HandleWidth = 10;
			dh.HandleHeight = 10;
			dh.HandleOffsetX = -5;
			dh.HandleOffsetY = -5;
			dh.HandleStroke = new SolidColorBrush(Colors.Black);
			dh.HandleFill = new SolidColorBrush(Colors.Orange);
			dh.HandleCursor = Cursors.Hand;
			dh.Drag += new EventHandler<DragHandleEventArgs>(dh_Drag);
			dh.HandleMinX = 0.0;
			dh.HandleMinY = 0.0;
			dh.HandleMaxX = DhCanvas.ActualWidth - 1;
			dh.HandleMaxY = DhCanvas.ActualHeight - 1;
			Canvas.SetZIndex(dh, 1);
			DhCanvas.Children.Add( dh );

			DragHandleConnector dhc = new DragHandleConnector(dh);
			dh.Tag = dhc;

			AddLine(0.0, 0.0, dhc);
			AddLine(0.0, DhCanvas.ActualHeight - 1, dhc);
			AddLine(DhCanvas.ActualWidth - 1, DhCanvas.ActualHeight - 1, dhc);
			AddLine(DhCanvas.ActualWidth - 1, 0.0, dhc);
		}

		void dh_Drag(object sender, DragHandleEventArgs e)
		{
			Xlabel.Text = e.Position.X.ToString();
			Ylabel.Text = ", " + e.Position.Y.ToString();
			Canvas.SetLeft(Xlabel, e.Position.X + 20);
			Canvas.SetTop(Xlabel, e.Position.Y - 7);
			Canvas.SetLeft(Ylabel, e.Position.X + 40);
			Canvas.SetTop(Ylabel, e.Position.Y - 7);
		}

	}
}

As you can see there is still a fair bit of code that has to be written to wire everything up, but it is pretty high level and compact, and if you think about all of the event handlers and property updates that would be needed to hook this up in an ad hoc manner for a single relationship, then these classes will save you a lot of work if you have many such relationships to implement. The demo I have presented here uses the controls in a traditional dragging-an-object scenario, but they are quite a bit more flexible than that. It would be easy to use them to create a slider, or to make the corner of a window draggable.

There are additional improvements I would like to make in this code at some point. One flaw is that updates only flow through to the DependencyObjects when the handle is dragged. If you call SnapToOrigin or set the handle position directly the DependencyObjects won’t get an update. I would also like to integrate the Canvas.ZIndex attached property into the design a little better. I currently set it manually outside the control to place the handle above the objects it is moving. But for now I think I will turn back to the drawing app, and let it drive the priority of future efforts on DragHandle.

Source Code:

DragHandleConnector.cs

Here’s a look at the current object model as it has been evolving over the last week and half. One of the things that I really enjoy about solo projects like this is having the time to conceive features and then really think through how to fit them into the framework in a generic and reusable way. It’s an organic growth process that leads to a Cambrian explosion once you get a critical mass of the architecture in place.

Needless to say, I am not at the Cambrian phase yet, but I’m hopeful. With that out of the way I can turn to something with a bit more fun factor, and what could be more fun than moving stuff around on screen? For the rest of this post I’m going to dive from the heights of abstraction all the way down to the smallest thing that will appear on the application’s window: a drag handle.

“Drag handle” is my name for the little widgets that appear on the edges of graphical objects in a drawing application. They are used for moving, resizing, or skewing objects by clicking on them with the mouse and dragging them, usually with the change to the object showing in realtime as the handle moves. Take a look at my Silverlight Gradient Editor. If you look at the gradient sample on the left you’ll see two orange squares attached to the line showing the direction of the gradient. Click on one and move it around. That’s a drag handle, or in my case, a DragHandle. There is a surprising amount of plumbing necessary to implement a little widget like this. You need the basic event handling, a way of measuring movement, a way of transforming coordinates, and a way of mapping the resulting values onto the properties of things you want the handle to control. In the end I am not sure whether the DragHandle class involves writing less code to do all these things, but it involves writing simpler, higher level code in a consistent way.

A DragHandle has a few key properties. First, you need to be able to click on it and drag it around. So it’s a control, with a shape, that handles mouse events and updates its own position. Second, you need to be able to specify some constraints on how it moves. In the gradient editor the two orange DragHandles are constrained to move within the area of the sample box only. If you change the brush type to RadialGradientBrush, you’ll see an ellipse with three kinds of DragHandles: one in the center that can move anywhere within the sample box; one at the minimum Y coordinate of the ellipse that can move in the vertical between the center and the edge of the box; and one at the maximum X coordinate that can move in the horizontal between the center and the edge of the box.

A third property is that you need some convenient way to wire the DragHandle up to the thing it is supposed to control. In the case of the editor’s LinearGradientBrush each DragHandle is connected to an end point of a Line object. The RadialGradientBrush example is more complicated: the center DragHandle is wired to the center of the ellipse, but also has to update the positions of the other two DragHandles, whereas they merely need to adjust the ellipse Y and X radii. Both are also wired to the properties of the brush that is being edited. This wiring involves another class called DragHandleConnector that I’ll get to in the second part of this. The full definitions of these classes is too big a topic for a post here. I hope to hit the highlights. See the links at the bottom of the post to download the source code files.

DragHandle is a UserControl, and the XAML markup is very simple, containing only a grid and child Canvas on which I position the handle shape. That Canvas may not in fact be necessary, and it’s possible I’ll get rid of it somewhere down the road. Here’s the markup:

<UserControl x:Class="DrawControls.DragHandle"
	xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
	xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
	<Grid>
		<Canvas x:Name="HandleCanvas">
		</Canvas>
	</Grid>
</UserControl>

As you can see, not much to it. All of the fun stuff happens in the code-behind, and in the connector class, so let’s start with the code behind. DragHandle is a basic UserControl that exposes dependency properties for a number of key attributes. These include the shape to be used for the handle, the brush to fill the shape with, the brush and width for the outlining stroke, the cursor to display when the mouse is over the handle, etc.

As every WPF programmer knows, implementing DP’s is one of the joys of Windows development on the 3.5 framework. However tedious, they do make the class much more useful and accessible. The meaning of many of these properties is self-evident, however a couple are worth discussing in more detail. The HandleDragConstraint property takes a value from the DragConstraint enum, which specifies the possible motion constraints on a DragHandle. I considered a number of different ways to represent these constraints, but settled on an enumeration as the clearest way to express them. I also considered making them “OR-able”, and I can think of some scenarios where that would be handy, but for now each of these constraints is mutually exclusive of the rest.

public enum DragConstraint
{
	None,
	EW,
	NS,
	NESW,
	SENW,
	NE,
	NW,
	SE,
	SW,
	E,
	N,
	S,
	W
};

The screen is divided into cardinal compass directions, where up (-Y) is North. Movement constraints are relative to the HandleOrigin, which is another dependency property. The HandleOrigin can either be set directly, or set by passing a Point to the DragHandle constructor. In either case it remains constant until explicitly reset. Other properties and methods rely on HandleOrigin. For example, the SnapToOrigin() method will move the handle to the origin. I’ll talk more about the mechanism for enforcing movement constraints relative to the origin a little further on.

Another interesting dependency property is ReferenceElement. The purpose of this property is to set the element whose coordinate space will provide a frame of reference for drag events. When handling mouse events in Silverlight (or WPF for that matter), the MouseEventArgs class provides a method called GetPosition(UIElement) that returns a point representing where the mouse is. The single parameter specifies the UIElement the reported coordinates will be relative to. If it is null then they are relative to the entire plugin area. In most cases a DragHandle will be trying to stick itself to a shape on a canvas, and we’ll want to translate movement of the handle to movement on the canvas. By setting the ReferenceElement to the Canvas of interest we can simplify that task, however, as you’ll see below more manipulation of the reported movements is necessary to get any real usefulness out of this class.

The rest of the dependency properties are for things like appearance, and don’t require a lot of explanation, so I’ll move on to talk about the mechanisms that make some of these properties and methods work for the DragHandle class, beginning with motion constraints.

The HandleDragConstraint property defaults to DragConstraint.None. If it is set the OnHandleDragConstraint PropertyChanged event handler gets called, and in turn calls a method named SetDragConstraint. The purpose of this method is to determine which of a set of small movement evaluation functions should be called when the user tries to drag the handle. It does this using a select statement, as shown below.

private void SetDragConstraint( DragConstraint d )
{
	switch ( d )
	{
		case DragConstraint.None:
			_evalMove = null;
			break;

		case DragConstraint.E:
			_evalMove = new MovementEvalCallback(Eval_MoveE);
			break;

		case DragConstraint.W:
			_evalMove = new MovementEvalCallback(Eval_MoveW);
			break;

		case DragConstraint.N:
			_evalMove = new MovementEvalCallback(Eval_MoveN);
			break;

		case DragConstraint.S:
			_evalMove = new MovementEvalCallback(Eval_MoveS);
			break;

		// remainder of select cases skipped
	}
}

The delegate _eval is a private member of the DragHandle class, and can be in one of two states: either it is null, and there is no movement constraint, or it points to a valid eval method that should be called when the user moves the handle. The chain of events begins with the method that handles MouseMove events on the shape that represents the handle. This method first gets the mouse position relative to the reference element, and then calls a method named RequestDragTo(ref Point position). The RequestDragTo method evaluates the user’s movement, and returns true if it is allowed, or false if it is not. If the method returns true the passed position may have been modified, which is why it is passed by reference. Let’s take a look at RequestDragTo.

private bool RequestDragTo(ref Point dest)
{
	if (dest == HandleOrigin)
		return true;

	if (dest.X < HandleMinX || dest.X > HandleMaxX ||
		dest.Y < HandleMinY || dest.Y > HandleMaxY)
		return false;

	return (null != _evalMove ? _evalMove(ref dest) : true);
}

RequestDragTo applies three rules to the incoming position. First, if the position is the same as the HandleOrigin it just returns true, since the handle can always move there. Second, if the movement is outside the bounding box specified by HandleMinX, HandleMinY, HandleMaxX, and HandleMaxY the method returns false, since the handle can never move there. If neither of those rules applies, the third rule requires the method to return true if _eval is null, or call _eval if it is non-null. If _eval is called it is passed the destination point by reference, and will return true if the movement is allowed, or false otherwise, and as described above it may modify the destination point. Each of the individual eval methods is very simple. I’ll show two of them by way of example.

private bool Eval_MoveE(ref Point dest)
{
	if (dest.X >= HandleOrigin.X)
	{
		dest.Y = HandleOrigin.Y;
		return true;
	}
	else return false;
}

private bool Eval_MoveNESW(ref Point dest)
{
	dest.Y = HandleOrigin.Y - (dest.X - HandleOrigin.X);
	return true;
}

As you can see these two methods behave slightly differently. The first is an asymmetric constraint, as it allows movement only in one cardinal direction; in this case from center to the East. So this method first applies a bounds rule, and then modifies dest.Y to make sure it is the same as HandleOrigin.Y. The second method doesn’t need bounds as it allows movement in two cardinal directions across the center, and movement too far in either direction will be caught in RequestDragTo when it violates the bounding box. So all this method does is coerce Y to move as much as X.
In addition to the dependency properties discussed above the DragHandle class exposes events that provide the main interface for client code, as well as an event arguments class to provide information to handlers.

private bool Eval_MoveE(ref Point dest)
{
	if (dest.X >= HandleOrigin.X)
	{
		dest.Y = HandleOrigin.Y;
		return true;
	}
	else return false;
}

private bool Eval_MoveNESW(ref Point dest)
{
	dest.Y = HandleOrigin.Y - (dest.X - HandleOrigin.X);
	return true;
}

Using these events the calling app’s code can be executed when the handle is clicked, when it begins to move, when it moves, and when it stops moving; fairly typical stuff for this kind of control. However, using these events directly would still require the application to put a lot of plumbing in place. The DragHandle as described so far is still a pretty dumb control. It can be dragged, and it will tell you when it’s dragged, and that’s about it. If you want the control to… ahem, control something, you have to provide the means to translate the changes in the DragHandle into changes to that something’s properties.

Take another look at the gradient editor. When you drag the orange handles around on the gradient sample box several things are happening. First, the end point of the line that is under that handle is being adjusted to move with it. Second, the properties of the LinearGradientBrush are being adjusted to reflect the change. No big deal, except that the drag handle and the line move in the coordinate space of the canvas, while the changes to the brush are in a 0 – 1.0 normalized coordinate space. To further mess with your head, the Line object doesn’t expose its end points as Points. Rather it uses X1, Y1, X2, and Y2. Why this is so I can’t say, anymore then I can say why occasionally a calf with two heads is born. They just are. So it isn’t simply a matter of assigning the X/Y values of the DragHandle’s position to the properties of the thing we want to control. We need more flexibility than that. In my next post I will discuss the thing that gives it to us: the DragHandleConnector class.

Source Code:

DragHandle.xaml – DragHandle.xaml.cs

WPF supports a rich set of control containers derived from the base Panel class. These include Canvas, DockPanel, StackPanel, WrapPanel, and Grid. Silverlight is a little more restricted, owing to its need to keep the runtime install as light as possible, and supports only Canvas, Grid, and StackPanel. In this post I will focus on those because they are common across both platforms. Even just these three are enough to gain a wealth of layout flexibility. Hopefully this post will help you take advantage of the different strengths and weaknesses of each. The best way to follow along with these examples is to use the XamlPad.exe tool included with the Windows SDK 6.0.

The most effective way to illustrate the differences between these container controls is to start with more or less identical definitions for all three so that we can plug them into XamlPad and see how they react. Here is the markup:

<Grid xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
	xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
	<StackPanel Orientation="Horizontal">
		<Grid Background="Gray" Margin="5"
			Height="200" Width="200">
			<Rectangle Fill="Blue" />
		</Grid>
		<Canvas Background="Gray" Margin="5"
			Height="200" Width="200">
			<Rectangle Fill="Blue" />
		</Canvas>
		<StackPanel Background="Gray" Margin="5"
			Height="200" Width="200">
			<Rectangle Fill="Blue" />
		</StackPanel>
	</StackPanel>
</Grid>

Ignore for a moment the root Grid and first StackPanel. Their only purpose is to arrange the three containers we’ll look at in a nice, horizontal package. As you can see from the code I have a Grid, a Canvas, and a Stackpanel. All three are dimensioned to 200 x 200 units, and all three have an identical Rectangle as the sole child element. If you plug this markup into XamlPad you should see the following (reduced for presentation purposes):

So, what’s going on here? The containers obviously don’t treat this identical child Rectangle identically. The Rectangle is dimensionless, it has no Width and Height attributes, and so when placed into a container it will take its default size for the layout strategy implemented by the container. In the Grid that means it expands to fill the entire available area, which in this case is the whole 200 x 200 space, because the Grid has no explicit row and column definitions. In the Canvas and StackPanel it doesn’t show up at all. So if we want to see it I guess we’ll have to give it some dimensions. Here is the updated code:

<Grid xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
	xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
	<StackPanel Orientation="Horizontal">
		<Grid Background="Gray" Margin="5"
			Height="200" Width="200">
			<Rectangle Width="100" Height="100" Fill="Blue" />
		</Grid>
		<Canvas Background="Gray" Margin="5"
			Height="200" Width="200">
			<Rectangle Width="100" Height="100" Fill="Blue" />
		</Canvas>
		<StackPanel Background="Gray" Margin="5"
			Height="200" Width="200">
			<Rectangle Width="100" Height="100" Fill="Blue" />
		</StackPanel>
	</StackPanel>
</Grid>

I apologize for the line numbers which make this code hard to copy. I use the CodeViewer WP plugin and I haven’t figured out how to turn them off. Click the download link and you’ll get a plain text version you can ctrl-c from easily. Anyway, plug this into XamlPad and you get a somewhat different result, which should look like what you see below:

Now we can see that there really are three Rectangles. We can also see that once again the three containers react quite differently to this identical element. In each container the Rectangle now has the specified size of 100 x 100 units. The default allignment is where things diverge. In the Grid a child element goes to the center of the cell. In the Canvas it ends up at top-left (0,0), while in the StackPanel it ends up at top-center.

This behavior makes sense given the design goals of these containers. The Grid’s purpose is to arrange content into cells. Within a cell it has no notion of (x,y) coordinates, and so lacking any other allignment directives it puts the child in the center. The Canvas, on the other hand, is designed specifically to allow (x,y) positioning of child elements. Since we didn’t tell it where to put the Rectangle it defaulted to (0,0). Perfectly reasonable choice. The StackPanel is a container that stacks its children one after another. You can control the direction it stacks in with the Orientation property, which defaults to Vertical. So the StackPanel in the example wants to stack its elements vertically. The Rectangle thus starts at the top, and since it is narrower than the panel the allignment defaults to center.

What if we add a second shape? Let’s try putting an Ellipse into each container along with the existing Rectangle. Here’s the code:

<Grid xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
	xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
	<StackPanel Orientation="Horizontal">
		<Grid Background="Gray" Margin="5"
			Height="200" Width="200">
			<Rectangle Width="100" Height="100" Fill="Blue" />
			<Ellipse Width="100" Height="100" Fill="Red" />
		</Grid>
		<Canvas Background="Gray" Margin="5"
			Height="200" Width="200">
			<Rectangle Width="100" Height="100" Fill="Blue" />
			<Ellipse Width="100" Height="100" Fill="Red" />
		</Canvas>
		<StackPanel Background="Gray" Margin="5"
			Height="200" Width="200">
			<Rectangle Width="100" Height="100" Fill="Blue" />
			<Ellipse Width="100" Height="100" Fill="Red" />
		</StackPanel>
	</StackPanel>
</Grid>

I’ve made the Ellipse the same size, but have given it a different fill color so that we can easily see what happens. And what happens, when you plug this markup into XamlPad, is this:

In both the Grid and the Canvas the second element is stacked on top of the first. Grid and Canvas both allow child elements to overlap and share coordinate space. This can be quite a useful trait if you want to create layers in your application. In a drawing package I am working on I have a shape layer and transparent tool layer created by stacking Canvases in a Grid cell. The StackPanel is doing what StackPanels do, i.e. stacking. In this case the Ellipse has been stacked under the Rectangle due to the default vertical orientation.

Now that we’ve looked at how these containers compare when defined as identically as possible, lets look specifically at three things that make each panel uniquely useful. For example, let’s make the Grid an actual grid:

<Grid xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
	xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
	<StackPanel Orientation="Horizontal">
		<Grid Background="Gray" Margin="5"
			Height="200" Width="200">
			<Grid.ColumnDefinitions>
				<ColumnDefinition />
				<ColumnDefinition />
			</Grid.ColumnDefinitions>
			<Grid.RowDefinitions>
				<RowDefinition />
				<RowDefinition />
			</Grid.RowDefinitions>
			<Rectangle Grid.Row="0" Grid.Column="0"
				Width="100" Height="100" Fill="Blue" />
			<Ellipse Grid.Row="1" Grid.Column="1"
				Width="100" Height="100" Fill="Red" />
		</Grid>
		<!-- Canvas and StackPanel removed -->
	</StackPanel>
</Grid>

The ColumnDefinitions and RowDefinitions collections tell the Grid how to carve up the screen area it owns. In this case I’ve given it two rows and two columns, resulting in four addressable cells. The cells are addressed by using the Grid.Row and Grid.Column attached properties on a child element. If you’re not familiar with attached properties they are context-specific dependency properties, that a child element acquires when it has a parent of a certain type, in this case a Grid. I have placed the Rectangle in cell (0,0) and the Ellipse in cell (1,1). This is what it looks like:

The Canvas has its own tricks as well. Obviously there must be a way to position elements. That comes in the form of the Canvas.Top and Canvas.Left attached properties. Let’s move the Ellipse away from the Rectangle:

<Grid xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
	xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
	<StackPanel Orientation="Horizontal">
		<!-- Grid removed -->
		<Canvas Background="Gray" Margin="5"
			Height="200" Width="200">
			<Rectangle Width="100" Height ="100"
				Fill="Blue"  Canvas.ZIndex="1" />
			<Ellipse Canvas.Top="50" Canvas.Left="50"
				Width="100" Height="100" Fill="Red" />
		</Canvas>
		<!-- StackPanel removed -->
	</StackPanel>
</Grid>

As you can see I have used Canvas.Left and Canvas.Top to position the Ellipse at (50,50) in the coordinate space of the Canvas, which happens to be dead in the middle. I have also used another attached property, Canvas.ZIndex, to move the Rectangle on top of the Ellipse. If you don’t use ZIndex the zorder is the same as the parse order from top to bottom. In WPF Grid also supports a ZIndex attached property with the same effect, but Silverlight does not. Here’s what the markup looks like in XamlPad:

As you can see, the Ellipse is positioned in the center, and the Rectangle is on top due to the ZIndex property.

There is a lot more that could be said about these three container types. We haven’t talked about content allignment, which can change the default behavior pretty significantly. But at least I hope this post has been helpful in terms of increasing your understanding of how these containers function. In the end each has its own set of applications. Grid is probably the most generally useful, which is why Visual Studio and Blend default to using one for the root of a layout. But when you want to position elements explictly to (x,y) coords you’ll need to use a Canvas, and when you want to arrange elements horizontally or vertically regardless of differences in element size, StackPanel will fit the bill.

What you do have to think about is how to organize and present that capability to the user, and how to connect the user’s intentions to the underlying systems. You need to think about how to do all that in a robust and extensible manner, in an environment that is quite a bit more constrained than the context in which a normal WPF app runs. In other words, you need everything but all the stuff I mentioned above, and that still leaves quite a lot to chew on.

I have a penchant for starting at the bottom of a hierarchy and designing my way upward. But in this case the bottom was pretty much defined, and I thought I could see how it would all fit together, so I began instead with the big picture. The first two ideas that popped into that picture were the concepts of a View, and a Tool. A View would be the thing that created and managed surfaces, and associated Tools with a surface, and a source of input events. A Tool would be the thing that knew how to take an input event, and a surface, and turn it into changes to a shape on that surface.

In WPF the Canvas class is the obvious choice for a surface. Canvas is derived from Panel, which makes it a container for UIElements. Shapes are UIElements which can be placed into a Canvas. Moreover, Canvas is the only Panel that allows direct x,y positioning of its child elements, something that will come in handy in a drawing tool. Canvas is also a UIElement itself, and can be styled and inserted into other Panels, so it is pretty versatile for this use. I initially began with a UserControl that wrapped a Canvas and added some management behavior, but as I worked those behaviors kept percolating up to the View, so at this point a Canvas is just a property of the View. As an aside, one of the longer range things I’m thinking about is how to move these drawings around. Nobody will want to create a drawing they can’t save. Rendering the Canvas objects out as XAML, pathdata, or directly to bitmaps are things I’m considering, and that I’ll probably write about later.

If the role of surface is easy to cast, that of Tool is less so. WPF defines almost all the stuff a user will want to create and manipulate, but it says nothing at all about how that will happen beyond defining some useful input events. When I started thinking about tools I knew right off that I wanted a couple of key characteristics: tools should be entirely generic – that is, nothing else in the application should have to know about any class below the base class for all tools; tools should define themselves in terms of their name, behavior, and appearance in a toolbox; and finally, tools should be dynamically loaded from an external assembly, so that I could add tool sets on the server side without any client changes. The concept of a Tool that I ended up with is flexible enough to support multiple toolboxes with tools that may draw, manipulate the canvas, drop text, or perform other actions.

So I had a general idea of the objects in the system, and it looked like this:

For me the most important place to go after I get an initial concept of the objects in an app is to delve into their lifecycles: how and by what are they created? Where do they live while they are alive? How are events routed to them? As I went through this process several things happened. Operations kept migrating away from the Stylus and into the View or Tool. I initially had this concept of the stylus as being attached to the tool, but I decided that was just a cute visualization, and at this point the stylus is just an abstract source of drawing events. Also, the View solidified as the arbiter of the relationships between the other classes. The View is the first thing created. It owns and manages the surface (a Canvas). It owns and manages the set of ToolBoxes that provide Tools. And it owns and manages the Stylus that serves as the source of input.

A few things are still being worked out as I go, such as the exact sequence of events that occurs when a user select a tool, moves the stylus out over the canvas, and presses the left button. Does the GeometryEditor create the object, select it, then start dragging? Or create it, drag it out, and then select it after the button is released. Another area that needs a lot of thought is how to present style editing for the shapes. That will be the subject of a future post. But for now, enough design. The next two posts will discuss dynamically loading the tools, and a handly little class I created to enable onscreen geometry editing.

The reasons for writing this up are twofold. First, I just spent several days pushing out some controls I needed and integrating them into some demo pages on this site. I didn’t feel like working on code tonight, so writing about working on code gave me an excuse not to. The two controls were a color picker, and a gradient editor. Check them out and let me know what you think. The second reason for writing is that I’m looking for a job, so I suddenly have time to work on some things that actually interest me and are fun, and worth writing about. If you knew what I had been working on for the last two years you’d know how pathetically needy I am in that department.

The application in question is a drawing program. It’s not an unobvious idea for a Silverlight app: WPF does a lot of the heavy-lifting for you, and has an object model naturally suited to moving and manipulating on-screen shapes. I’m sure Microsoft will have a SilverPoint somewhere down the road. My idea isn’t to compete in the drawing app space, though I have some ideas in that direction. At the moment I am working on a wholly different idea, about which I won’t say much now, that needs as part of its solution a drawing capability. Graphics applications are fun to do, and did I mention I am unemployed? It takes an hour to riff through Dice.com and email my contacts. What the hell else am I going to do with the rest of the day? So off we go.

My next post will talk about the overall design of the application, and some of the choices I’ve made, and the one after that will look at some handly classes that have come out of that work. Beyond that I am unable to predict, because I haven’t done the work yet. When I get back to work on the code tomorrow I hope to have the first three tools dropping and manipulating shapes, so there could be a demo in the near future as well.

This post is about an online fantasy role playing game called Warhammer Online: Age of Reckoning. It is developed and operated by Mythic, now a division of Electronic Arts. I’ve been playing it for about a month now, on the Iron Rock server, with a bunch of former Dark Age gaming buddies. You would think I am too old to be wasting time on something like that, and, in the end, the point of this essay may be that you’re right. At least, it may be that online role playing games have moved on, and I haven’t. In any case, this isn’t going to be a very positive post, and I’m sorry about that. Mythic got monthly subscription dollars from me for Dark Age of Camelot for years. I wanted Marc Jacobs to succeed with Warhammer Online, and it may well be that he will, but it doesn’t look good from here.

A wee bit of history: I’ve been fascinated by virtual worlds for twenty years; pretty much ever since I knew enough about computers to conceptualize what one is. The notion of creating a world as a mathematical model and then rendering it to some sort of display environment is very compelling to me, and has been ever since I saw a 3D maze game on my Tandy Color Computer in 1980. Add in a good dose of escapist personality traits and you have a natural affinity for computer role playing games, or CRPGs. I never did get into the tabletop RPGs much, but I played all the early computer fantasy games, including the Ultima Series, Might and Magic series, Eye of the Beholder, Krondor, and many others. Probably the series that provided the most virtual world wow factor for me was Bethesda’s Elder Scrolls series, the latest installment of which is Oblivion.

My first online role playing game was Everquest, which I played for several years with a group of developers at a small software company I co-founded in 1997. We would work on client stuff all day, then at night we would all log in to the Morrel-Thule server and go on quests, explore dungeons, fight monsters, and abuse each other in chat. We formed a guild and spent a lot of time together in that world. It was a blast. The addition of real people to the whole world in a box thing was very cool. I’d messed around with MUDs (Multi-User Dungeons) like Diku before, and was familiar with Ultima Online, but EQ was the first true 3D perspective rendered virtual world that was shared among thousands of simultaneous users, and it was amazing.

By today’s standards Everquest would be considered nearly heartless in its design. The world was absolutely huge. It was said to take over eight realtime hours to run across it, though I never tried. There were no in-game maps. If you wanted help you got a map online and printed it out. There were no indicators of a monster’s strength relative to yours; no signals when an NPC (Non-Player Character) had a quest or would converse with you. If you failed to check a monster’s strength, and died, then your corpse and everything on it dropped right where you were, and you respawned nearly naked at your bind point. You then had six realtime days to get back to the corpse and retrieve your stuff, or it was gone. Environmental effects were realistic. For example, when it got dark you couldn’t see very well, and the same went for heavy snow or rain. The behavior of monsters was similarly without pity. If they got near you, and hated you, they attacked you. If someone else was attacked and ran, they would all chase him. And chase in those days meant all the way to the border with the next zone. If he died or escaped, they would attack anyone else they encountered on the way back to where they came from.

These design choices were consistent with the traditions of role playing games up to that time, and they made for a thrilling environment. I remember the first time I logged my High Elf character into the Faydark, and walked out of the city into the woods. It was night, and I could barely see. There were dimly lit trails running off into the darkness, and huge Orcs trotting around and grunting in the shadows. All I knew was that I had been told by an NPC that my next step was to get to the Wood Elf city of Kelethin, and I had no idea where it was. Fortunately an older player led me there. The whole experience was very immersive and frightening. On another occasion I mistepped switching from one ship to another in the midst of the ocean and fell off. I ended up swimming for nearly an hour to find land far to the north of where I had dropped, in the middle of the sea between continents. The water was full of dangerous monsters, and had I died there it would have been almost impossible to retrieve my stuff. The risk and possibility of loss was a big part of what made EQ such a popular world.

After Everquest I played Mythic’s Dark Age of Camelot off and on for almost five years, with a group of guys whom I still game with today. While DAoC, as it is known, dumbed down some of Everquest’s tougher rules, it added a new thrill: players were divided into three realms, and the game world contained vast areas of frontier where they could fight one and other. There were keeps and towers that could be sieged and taken, and ultimately if you persisted long enough you could lay siege to one of two central castles for each realm, and sieze sacred relics that gave your realm added benefits and bonuses. You could not enter the other realms’ home territory, talk to them, or trade with them, and when you met them in the field all you could see above their characters was race and class. No names, no guild affiliation. It made the whole thing very dangerous and mysterious. While DAoC took some of Everquest’s edge off (no corpse runs, for example), there were still no in-game maps, the world was huge and easy to get lost in, and when you died in battle with another realm it could take a long while to get back out to the scene. Dark Age was successful for a long time, but dated mechanics and graffics, as well as some questionable design decisions in expansion packs, have pretty much killed it at this point.

After DAoC came World of Warcraft, Blizzard’s immensely popular hit that is being played, as you read this, by something like half the population of Canada. Ok, just kidding. It’s more like the population of greater New York City. I played WoW for about a year, with many of the guild members from DAoC. Some of them stayed on for almost three years, but I quit. WoW scored highly on atmosphere, and had a huge and interesting world, but Dark Age had spoiled me for something more intense, and the combat in WoW was pathetic. There was really no death penalty at all. Players killed in battle against monsters or other players would spawn at the closest graveyard, typically with a very short run back to the fight. This made it impossible to really make headway against an enemy force, which constantly reinforced itself with resurrected players. World of Warcraft also began the trend toward making these environments seem a lot more like a theme park than a virtual world. In-game maps pointed out every feature of the world. NPCs who would talk you you had symbols floating over their heads, you could pay a few coins and fly anywhere in the world in a couple of minutes. It was just getting easy, and what is easy is not very thrilling.

Many of us just gave up on online RPGs at that point, and waited for Mythic to release their long-awaited follow-up to Dark Age: Warhammer. Surely the originators of Realm vs. Realm warfare in online role playing games would take everything they had learned and produce a tour de force. If any team could put the thrill back into the virtual world of online gaming, it would be Mythic, right? Sadly, my perspective on Warhammer Online at this point is that it is a step backward in almost every possible sense. If there are thrills to be found in this game world, I haven’t located them yet.

Ah, where to begin. Well, the best place is probably with the design of the world itself. For almost two decades the goal of virtual world designers has been to get to more seamless designs. In Everquest the world was divided into zones, and the game client loaded each zone individually. In Dark Age areas were grouped together with zone boundaries between them. World of Warcraft did away with most zone boundaries, and Vanguard, a recent Sony flop that I played briefly, tried to do away with them completely, making the whole world one entity that could be travelled from end to end. I won’t go into the technical challenges of doing this, but they are considerable. Marc Jacobs, EA-Mythic general manager and lead designer of Warhammer, went completely the other way. The zones in WHO are small, mostly disconnected, and bounded by unclimbable hills. Within the zones content is organized along strictly linear paths. In fact the whole concept of the game is so linear that the land itself is organized into “chapters.” So you scan the map of the zone and see that the nearest warcamp is Dark Elf Chapter 4, and then further down is chapter 5, and so on. Look at the map and you don’t see a world (well, you do in one gratuitous view, but it is meaningless). Instead what you see is something like a Visio flowchart, with individual zones connected by lines showing the way that a character is supposed to progress through the world.

Aside from the remorseless linearity of the content and storyline, the world looks pretty, and has appropriate soundscapes and other cues. It is actually quite nice and competes very well with other games I have played in that department. Unfortunately the design choices make it look small, and feel small. At any given time you are in a place with one road, with the easier content behind you, and the harder content in front. Which is strange, because in this dumbed down simplistic environment the devs apparently still thought the player would need complete information in order to get around. The in-game maps show everything about an area once you’ve been there, including shading in the locations you need to visit for quests, and marking where your groupmates are. There is no challenge in getting around Warhammer’s world, or in figuring out what you need to do when you get where you’re going.

In fact there is no challenge in anything about the world of Warhammer online. There is no death penalty. You can’t drop a quest item. You don’t even need to loot quest items. The crafting system is trivialized and nearly useless. Monsters don’t chase you very far, are loathe to attack if you are higher than them (how does a bear know that?), and won’t help each other ever. Think about that for a minute. You walk up to a camp with a leader whom you need to kill for a quest. Standing around are all his trusted comrades. So naturally you step out into the open and attack him in their midst. He runs up and engages you as the rest of them stand there while he is killed. Yes, it’s gotten that absurd. Of course, there was always something absurd about these games, but at least there was some challenge. Warhammer has been boiled for so long that what results is mushy pablum. I was able to nearly solo my Zealot, one of the weakest characters, through level 31. While many of the game’s faults, such as a lack of dungeons and epic content, strange itemization, broken mechanics, etc., can simply be attributed to it being a young system, the things that remove the thrill from the world are not among them. They are fundamental choices made in an attempt to cater to a broader market of people who, apparently, will only go bowling if they are guaranteed a strike on every frame.

If there is no challenge there is certainly frustration. If only that were a desirable trait in a game Warhammer would do fine. The worst thing from my perspective is the distribution of NPCs and MOBs (mean old bastards, a gamer word for monsters). Perhaps sensing that their world was too easy to conquer, Mythic attempted to adjust for this by essentially scattering aggressive MOBs over every square foot of most zones. The re-spawn rate is insane throughout the whole game, and it becomes very difficult to move through the world from one point to another without being attacked, unless you stick strictly to the road. But wait, aren’t I contradicting myself? On the one hand I want a challenging game, but on the other I don’t want to be attacked? Well, not really. I do enjoy the challenge. I like it when monsters help each other, chase me down if I do something bad to them, etc. But there is no danger to dying in Warhammer, and so spreading the mobs out the way they have just seems like an exercise in silliness. Standing on a hilltop and looking out over a field where some aggro monster is standing every four feet does nothing to heighten the immersion or suspension of disbelief. It just looks stupid. In addition to challenging combat I also like to explore and enjoy the worlds that the artists create, and that’s a little difficult to do when you can’t put your foot down without stepping on some monster.

So, if the world isn’t all that sensible or thrilling, at least the realm vs. realm warfare must be, right? After all, the players are human, and they can always go out and have fun regardless of Mythic’s choices in the rest of the world, can’t they? Well, sorta. The players have to play within the mechanics that Mythic set up. And for the most part those aren’t bad. The classes work pretty well, although there are the usual balance issues and loud complaints about them. There are plenty of spells and weapons and potions and other tools. And yet, the realm war feels as flat as a two-dimensional space. This is due to several factors. The first is that the races are mixed up in each zone, rather than being from far countries reachable only across a vast frontier. This removes the air of mystery and danger that attended encountering them in DAoC. Second, the zones themselves participate in a complicated “locking mechanism” that relies on “victory points.” Gain enough of these and you lock the zone and can progress to attack in the next zone, hopefully continuing all the way to the enemy’s home city and their King.

Unfortunately nobody seems to fully understand how victory points accumulate, other than that it isn’t enough to take keeps and towers and move forward that way. You also have to complete quests, and fight in what the game calls scenarios. These are tiny instanced combat maps that operate like the fantasy version of a fragfest, and against all common sense and tradition in RPG design, they are currently the fastest way to gain experience and level your character. As a result the game has many, many players who do nothing more than log in, park at a warcamp, and queue up for scenarios over and over. There are entire stretches of pretty cool RVR content in the “Tier 4″ zones, that are for the most part empty of players. If you don’t fulfill the questing and scenario requirements then you can take all the keeps in a zone and still not “control it.” Conversely you can control a zone to the point of locking it, and still not control most of the keeps and objectives in that zone. It’s a nonsensical system that bleeds off any incentive to fight, because once you get enough people together and start succeeding on the battlefield you run into a little “lock” icon in the upper right corner of the UI that says “You can’t go any further until you go run some quests or scenarios.” I was in a warband once that dropped all the objectives in Reikland, and then ran into the lock issue. Within twenty minutes most of the warband had quit and were back to running scenarios.

For me Warhammer represents the evolution of really bad game design. Sid Meier, the designer of Civilization and many other successful games, has long been my favorite example of a person who knows what good design is. His games combine just enough challenge and reward to keep the player immersed. Marc Jacobs didn’t design Dark Age of Camelot, as far as I know, but he advertised himself as lead designer of Warhammer, and I simply don’t think he has done a good job. It’s too bad, because as I said before I wanted him to succeed with it. The parts that need to be simple and enticing are too complicated. The parts that need to be hard are too easy. There are no vast and dangerous territories to cross, few epic dungeons to explore, and little reason to engage enemy players in the frontiers other than for points, which can be had faster and more reliably in scenario play. I think the problem he ultimately has is there is no reason to play his game. The people who came from WoW are already drifting back there, while the people who last played DAoC are either going back to it or just quitting altogether.

For now I am having fun just because I haven’t played with this group of people for a couple of years, but that will wear off soon, and then I will likely be in the second category. I don’t think we’ll ever again see a game that delivers thrills the way EQ and DAoC did, if only for the reason that WoW has now set the standard for success at millions of subscribers, and apparently there aren’t millions of people who want to play a hard game. Hamburgers sell better in the mass market than chicken vindaloo, and so it is natural to expect game developers to cook a lot of burgers. It would be nice if someone, somewhere, would make a game like EQ + DAoC on a modern platform and be happy with a couple of hundred thousand subscriptions, because I think they would get them. But sadly I don’t see the fantasy RPG world’s Eve Online coming down the pipe, and that’s too bad.

There’s something a little melancholy, for me, in walking along an abandoned railroad. I feel it whenever I explore the remains of our national past, but old rights of way bring it out most strongly. Partly this is because I was always a little bit of a railfan, and partly it is the significance of these narrow strips of landscape, empty and overgrown where once great steam engines chugged along hauling the commerce of a young country. A century and a half ago the great men of the day gathered in smoke-filled rooms and clinked their glasses in celebration of the last rail layed and the last spike driven, and yet now it is all just memory.

Northwestern New Jersey is well-striped with the remains of these old iron roads. At first they were built to reach the output of colonial iron mines and furnaces, and to bring the produce of the state to markets in New York. Later they crossed our rugged landscape to connect the rich coal fields of Pennsylvania and the industrial regions of the midwest with New York and New England. Most were abandoned long ago. The story of northeastern railroading is one of shortlines, interconnects, big dreams and little success, corporate mergers, changing economic conditions, and finally, the financial debacle out of which Conrail emerged in the 1970′s. It was Conrail, whose name is an amalgam of Consolidated Rail, that proved the death of most of these old roads. There were too many of them going to the same places, and so the rails were pulled up, the ties tossed to the side to rot, the signals disconnected, and the station signs removed. But something always remains to tell the story.

Not far north of Hackettstown on state route 517 the road to Allamuchy forks off to the left. At the crossroads stands a general store, a couple of houses, and not a lot else. Take a left on the road to Johnsonburg and continue out past the township school and you will soon see a small, yellow frame building sitting on concrete pilings just off the north side of the road. A sign identifies it as the Allamuchy Freighthouse, and next to it a wide trail disappears into the forest, heading northeast. If you don’t have a GPS or map in hand, with the thin grey gray line crossing the roadway at nearly right angles, then the telegraph pole and crosstree next to the station is probably the first clue that here was once a railroad. Enter the leafy tunnel and walk northeast and other clues quickly emerge: the ballast stone underfoot; the piles of ties; more telegraph poles.

A glance at an old topographic map identifies this as the Lehigh and Hudson River Railroad, at one time a major interconnect line from the Pennsylvania RR at Belvidere, NJ to the big Central New England yard at Maybrook, NY. Not far up the right of way from the station at Allamuchy you can find a remaining milepost, showing 54 miles to Maybrook (“MB”) on the one side, and 18 miles to Belvidere (“BD”) on the other. Like many of New Jersey’s 19th century railroads, the LHRR got its start as a shortline built to serve local interests. A group of farmers in Warwick, NY got together in 1860 to charter a line that would haul their produce southwest to the New York and Erie line at Greycourt, NY. The line was completed in two years, and initially operated by the NY&E as the Warwick Valley Railroad.

In 1870 a railroad was chartered in Belvidere, NJ to build out across the Delaware river, and another to build northeast to the New York state line. Someone saw this new effort as a competitive threat, and promptly chartered the Lehigh and Hudson to build a competitive line, relying on the Wawayanda Railroad to cover part of the distance to New York. Sanity somehow prevailed, and the three companies were joined together as the Lehigh and Hudson River Railroad, later also attracting the Sussex Railroad and the Warwick Valley to form the Lehigh and Hudson River Railway with service from Belvidere to Greycourt by 1882. The final piece of the interconnect was put in place in 1888 when the Orange County Railroad was chartered to build from Greycourt up to the Central New England RR yard at Maybrook.

With the completion of the Maybrook extension the LHRR became an important interconnect between the Pennsylvania Railroad with service south to Washington, D.C., and the New York and Erie with service to New York and New England. When the railroad bridge at Poughkeepsie, NY was completed in 1888 the LHRR became part of the “Poughkeepsie Bridge Route” from Washington to Boston, and for many years the famed Federal Express trains of the Pennsylvania used this route. In 1972 the LHRR filed for bankruptcy when the Penn Central road decided to stop using the bridge at Poughkeepsie. In 1976 the road was merged into Conrail, and largely abandoned. Today its northern portion is still intact and in use to service some industries in the Sparta and Franklin areas, but most of the line shows little evidence of it’s former importance in the transportation web of the northeast.

There are a few more pictures in the gallery here. Those interested in exploring the route should be aware that I don’t know the ownership status of this right of way. I did not encounter any barriers or posted signs, but you may be walking on private land in places.

For more information on the Lehigh and Hudson River Railroad, see the following pages:

Lehigh and Hudson River Railway at Wikipedia

An LHRR scrapbook at Railfan.net

The LHRR at American-rails.com

The sandy loams of the Pine Barrens of Southern New Jersey are a porous filter for the water that trickles through purifying layers to feed one of the largest aquifers on the East Coast. Hours after the rain has fallen the ground is for the most part dry again, and undisturbed. Into this same ground has been poured, over the centuries, the hopes and dreams of generations of entrepreneurs. The woodcutters, colliers, iron and paper mongers, would-be glass barons, and land speculators have all thrown their best shots at these seemingly endless miles of forest, meadow, river, spung, and swamp, with as little effect. To decamp in the middle of these woods today, in Lacey Township, or perhaps old Shamong, is to find yourself set back 200 years to the turn of the eighteenth century. Before and behind you are the miles of rutted sand roads. Around you the wind moans in the cedars and oaks. There seems to be no sign of the place this once was, and yet, something gleams dully from under a thick carpet of spring greenery.

What comes up in your hands after you push aside the brush is a chunk of clay pipe, thick and cold even in the spring warmth, with a rich brown glaze and crackling that has here and there marred the surface. Henry Beck visited this spot once, following a map old Buzby had given him, and mentioned similar shards. Once clay was the latest in a long list of natural resources that would at last bring riches to the captains of Pine Barrens industry. Not far up the road the Adams Mining Co. dug the pits at Old Halfway and hauled the clay in narrow gauge cars to the rail line at Woodmansie. Northeast of there, and south of Whitings, the Hydraulic Press Brick Co. operated clay pits for many years. The clay all around these parts is of the Cohansey formation; good for terra cotta and pipe. Under this spot where the shards litter the ground a yellow-white variation of it lies in ten foot-thick layers. In 1858, according to state geologist George Cook in his 1868 report to the New Jersey legislature, the Union Clay Works was established in this place to work that yellow-white clay.

First they attempted to make brick. Many of these can still be seen on the site, bearing partial imprints. I haven’t found a whole one with a good imprint, but I have been told by people who should know that they typically read “Ocean Co. N.J.” and sometimes had the date “1850″ below that. You can see pieces of this inscription in some of the pictures of brick fragments in the gallery. According to “The Clays and Clay Industry of New Jersey” (Ries, Kummel, and Knapp, 1904) they also tried common pottery, but for whatever reason these products were not successful. Perhaps there was too much competition in the brick business from the Sayre works in Sayreville. You certainly find many of their bricks in the pines. In any event, by 1866 the plant had shifted over to making terra cotta sewer piping in a wide variety of sizes, styles, and configurations. It is this product which is found at the site in quantity today. Again the product was not successful over the long term. Ries, et al speculate that the distance from the railroad and the soft, sandy wagon tracks had something to do with it, but those seem small hurdles for the kind of people that persistently attempted to make enterprise work in the pines.

Whatever the reason, while other clay pits and works continued, Union Clay was abandoned in the late 1870′s. All of the pipe and brick you see in the images accompanying this article was manufactured before that time. Later, around the 1930s, the property was sold to a rod and gun club that maintained a hunting lodge here for several years, some remains of which can still be seen. Today the site is thickly overgrown forest, with few landmarks, waste-high brush, and an abundance of ticks and chiggers. I had visited it once before, nearly a year ago, but failed to muster the gumption to wade deeply into the woods. On a recent return I came more prepared, and spent nearly two hours searching for what I was sure I must have missed last time. The southern portion of the area, where I had been previously, has scattered pipe shards and the occasional brick. As I worked my way northward these dwindled, until in the center of the site I was seeing no remains at all.

I had almost convinced myself that there was nothing more to see when I came upon a pit full of foul, stagnant water. There was no reason for there to be a pit full of water here, unless some human had dug it out and left it to fill. I worked my way around the north side of it and began to see more shards, including one smooth chunk that had become embedded in the roots of a tree. Ahead of me a mound of earth obscured the ground beyond, and since mounds are always of interest in the Pines I headed toward it. On my right were what seemed to be piles of brick, whole and in fragments. On the other side of the mound I stumbled into a large dump pile of broken sewer pipe fragments. In “Forgotten Towns of Southern New Jersey” Henry Beck mentions finding a pile of pipe “draped around what might have been a kiln.” It’s possible that this pile I had located was the same one, or some other. How it got there is anyone’s guess. Very likely the workers at the plant dumped rejected product here, but it is also possible that the pipe was pushed here when the site was tidied up at some point in the past.

I had to move carefully as I photographed the pile, to avoid breaking anything underfoot. When I left I followed an old fire cut southward, as it was an easier trail than the one I had made for myself coming in. More bricks and shards were in evidence all through this area, and at one point I spied a series of six large iron bolts protruding from the ground. According to one historian I know the management at Union Clay once bought a steam engine and had it mounted at the works to provide power. It’s possible these bolts are part of the footings for that engine. There is more to see at Union Clay. There is a very old cemetery out there that was mentioned by Beck, and I think I know where to look for it now. There are supposed to be some cellar holes as well. And although I brought back my usual collection of tick and chigger bites as a reward for traipsing through their domain, I am looking forward to going back and giving them a third crack at me.

Note: updated on 6/14/08 with some corrections, with thanks to my friend Jerseyman, who knows more about this stuff than most people.

View the Full Image Gallery