One tool that I hadn’t seen before but have since come to rely on was an innocuous looking button with the label ‘Tidy Array’ that would resize an Excel range with an array formula in it. This is probably the biggest PITA in Excel: entering a formula that returns several values. However, unless you know exactly how many values the formula is going to return, you’re left either getting only part of the result back, or with unsightly #N/As framing the result. Tidy Array would evaluate the formula internally, check the size of the returned result, resize the range in which the formula had been entered, and then re-evaluate the formula to fill that resized range with the result.

Since leaving DKIB, I’ve been playing around with ExcelDNA, Govert van Drimmelen’s fantastic library for building XLLs in managed code, to build an Excel-based interface for my trading system. I missed Tidy Array, so I put something similar together (link below). It’s a little different in that after you run the function (from the ‘Pandora’ menu), it just resizes the selected range to the correct size rather than filling that resized range; the reason for this is that this prevents neighbouring cells from being inadvertently overwritten. (Note: GB’s version had logic to keep it from overwriting stuff, but I prefer to limit function behaviour rather than add behind-the-scenes logic.)

I tried to add a keyboard shortcut for it too (Ctrl + Shift + T) but I haven’t managed to get it to work yet.

To use:

1. Unzip to some convenient directory. Note the location of the TidyArray.xll file.
2. Start Excel and add TidyArray.xll as an Excel Add-in (In 2003, it’s under Tools -> Addins; in 2007, it’s under Excel Options -> Add-ins -> Excel Add-ins

TidyArray.zip

•  `{2}` — matches the preceding identifier twice
• `{2,3}` — matches the preceding identifier between two and three times
• `{2,}` — matches the preceding identifier at least twice
  

More reading is at MSDN’s Regular Expressions (Visual Studio) and Wildcards (Visual Studio) pages.

Anyway, since Atlas is a little ways off from being production-ready, I decided I’d see if I could put script.aculo.us to some use on my project (yes, the one with RI that I started many moons ago). I initially just wanted a quick solution for making some elements draggable, but since I discovered the shopping card demo, I’ve become quite keen on bringing Droppables into the mix as well.

Unfortunately, as I mentioned above, there’s little to no documentation on how to actually use the library — the website will literally go no further than to show you some source code. Ruby source code. Brilliant.

Thankfully, Javascript is simple and obvious since you can choose to ‘view source’ any website you come across.

Creating Draggable objects

Draggable is the JS class that describes objects that can be dragged (mouse-down on them and move the mouse around). Here’s how to create a draggable object:

<img id="image1" src="image.gif" />
<script language="text/javascript">
new Draggable ('image1', {ghosting:true});<script>

The ghosting option makes the image translucent when it is being dragged. There are several other cool options, including revert, which is often used with Droppable objects to make the Draggable return to its original position on mouse-up. Of course, seemingly none of this is documented, and you have to go digging through the code to find them. You’ll notice that the inevitable call to getElementById is hidden and script.aculo.us accepts simply the element ID you want to manipulate. Nice touches like that win hearts.

To make one of my FormView’s draggable, I wrapped the <asp:FormView> tag in my aspx file in a div and gave it a convenient name, to prevent having to register the script (see my post about name mangling).

An important thing to note is that once you’ve made your element Draggable, it’s tricky to manipulate it with your own re-positioning code. For example, suppose you’ve got a Draggable that you also want to be able to reposition by clicking anywhere on the page. If you write your own scriptlet to do this, you run into all the problems associated with relative and absolute positioning. Not insurmountable, but there goes half an hour…

Using Droppables

Here’s a trickier problem. Like I mentioned, I thought the shopping cart demo was really cool, and I was very keen on doing something similar on my page. Unfortunately, the code available is pretty cryptic:

< %= drop_receiving_element "cart", 
      :update => "items", :url => { :action => "add" },
      :accept => "products", :hoverclass => "cart-active",
      :loading => "Element.show('indicator')",
      :complete => "Element.hide('indicator')" %>

This is translated to the Javascript below:

<script type="text/javascript">
Droppables.add('cart', {accept:'products', onDrop:function(element){
  new Ajax.Updater('items', '/demos/shop/add',
  {onLoading:function(request){Element.show('indicator')}, 
  onComplete:function(request){Element.hide('indicator')}, 
  parameters:'id=' + encodeURIComponent(element.id), 
  evalScripts:true, asynchronous:true})}, hoverclass:'cart-active'})</script>

Again, not easy to interpret: what exactly is the add page returning? Merely a count of the various elements the cart contains, or the actual HTML to represent the cart?

For the answer, one need only visit http://script.aculo.us/demos/shop/add?id=item_2_0. This is the actual URL the demo hits when you drop a t-shirt into the cart (that item ID is out of the page source) . You might need to visit the actual cart first and add a t-shirt to get the server-side bit set up properly — I ran into a ‘null array’ exception when I tried it directly.

Hitting that URL shows that the add page is returning the full state of the shopping cart, serialized as HTML.

I haven’t gotten around to coding the equivalent ASP.NET yet, but it should be simple. Equally, given how cleanly the library interacts with HTML elements (eg. requiring only the element ID to be able to apply effects), it should be easy to use the other stuff provided.

Technically, it’s not mangling; VS .NET is qualifying the element name to prevent name clashes. Still, it’s irritating, because client-side Javascript can’t directly reference these elements, and finding them through some hack involving getElementByID() risks being broken if/when the format for mangling is changed. This guy ran into this problem, and the responses he got are fairly typical of the advice normally given.

The correct way to do it is to use the ClientID property of the control underlying the element you will be referencing. You can then form the Javascript at compile-time to accurately reference the rendered element.

So, for example, if you’re working with a FormView defined like this:

<asp:FormView ID="FormView1" runat="server" DataSourceID="DataSource">

On the client-side, this is rendered within a table something like this: <table id="ctl00_ContentPlaceHolder1_FormView1">

To address this element, form and register your Javascript like this:

string js = "<script language='javascript'>document.getElementById('" 
          + FormView1.ClientID + "').style.visibility='hidden'</script>";
Page.RegisterStartupScript("Invisibility", js);

Update: Bleh, use ClientScriptManager.RegisterStartupScript(...)…Page.RegisterStartupScript(...) has been deprecated.