|
Thursday, January 30, 2003 |
|
Debugging Drag and Drop in .NET I have been implementing a fairly straightforward drag and drop operation from a row on a Datagrid to a node on a Treeview in a Windows Form application. Of course I have made some mistakes along the way and want to step through the code in the debugger to find out what I have done wrong. However, every time I open a form that has drag and drop enabled controls, the application throws an exception "Unhandled Exception (blah blah): DragDrop Registration failed.". So there is clearly something unusual about debugging forms with drag and drop enabled controls. I wish I knew the trick. For now I have to display little messages in text boxes on the form. Feels kind of like I am back debugging COBOL programs from 20 years ago. 4:59:27 PM 
|
|
Custom Weblog Posting Renderer Since we can easily extend Radio's context menu to invoke our own renderer, we can control how the post gets marked up before it shows up on our Radio home page. My first step is going to be adding a Edit Context Menu item to the context menu. That way I won't have to always remember where the context menu is. I just open user.tools.menus.rightClickMenu, add a new item named Edit Context Menu, double-click its node (the black triangle) and enter edit(@user.tools.menus.rightClickMenu). Voila! The context menu now contains an item that allows me to edit the context menu.
Let's add another item to the context menu. This one will post an outline item to my weblog using my own custom renderer. Let's name the item Post Using My Renderer. The script to invoke will be simply user.radio.menuCommands.postUsingMyRenderer(). Now we have a context menu item that will allow us to post to our weblog from a selected node tree in a Radio outline. Next we need to build the custom rendering script.
Copy radio.outliner.menuCommands.PostToWeblog over to user.radio.menuCommands.postUsingMyRenderer (I created the menuCommands sub-table to hold this and future scripts). I made some modifications to the script: I want level 1 subheads to be treated as new paragraphs, level 2 and beyond as undererd list items. I published the script for interested readers. Here is a screen shot just to prove that all this was written in Radio's outliner. 2:51:17 PM
|
|
Maintaining One Weblog From Two Locations Here is an interesting thought. If I can create my day's postings in a Radio outline (and I have shown that you can today) and I can save a Radio outline as an opml document and Radio knows how to render opml documents and upstream them automatically.... then couldn't I use a shared opml file between home and work to edit a single weblog? The answer is .... no, not really. I mean, I could sort of do it with a modified template and everything would look just the same, but without additional custom coding the postings would never end up in Radio's table of postings and that means I would lose some functionality (like building a calendar, searching for posts, categories, etc.). But if you are really hard up for a solution, I guess it might work in a pinch. 2:20:20 PM
|
|
I did a little digging around, trying to find out what happens when I select Post to Weblog from the context menu in an outline. I found some interesting stuff. For one thing, I can extend the context menu myself. You can too. Just add menu entries to user.tools.menus.rightClickMenu. Any changes show up immediately! Hey, that's pretty cool because it means I can make adjustments to how stuff is posted into my weblog from an outline. More on this later. I also found that the Post to Weblog menu item results in a call to radio.outliner.menuCommands.PostToWeblog. This is sort of a mini-renderer (see A Busy Writers Guide to Radio Renderers for background) that takes your outline, marks it up based on the structure of the outline, and throws the resulting HTML into the new post text box on your Radio home page. This "default" renderer charges through the selected node and subnodes. The selected node is marked up with bold tags. Any indented nodes underneath it are marked up as list items for an unordered list. More thoughts are forthcoming... |
|
I often see Dave Winer pointing to screenshots where he is editing his weblog using Radio's outliner. I love writing in the outliner and use it for all of my stories, but I am not real familiar with using it for writing posts. I know I can do simple things like write the text for a post and then right-click to select the Post to Weblog menu. But how about paragraphs, lists, and titles? I am experiementing today. All of today's posts are being written in the outliner. I will document my findings as the day proceeds. 9:30:42 AM Google It!
|
|
Two years ago I was working on a claims application. It was (and still is) an application that our field adjusters use to put together estimates for property losses. Our guidelines was "if you turn the house upside down and shake it, anything that falls out is accountable by this application". That probably does not sound very exciting, but it is innovative in its own way. It is a browser application, but has to run on disconnected laptops (for adjusters that are inventorying loss items from a house fire). We teamed up with Inktomi and several brick-and-mortar stores to provide access to the latest pricing data within the application. We incorporated a self-updating mechanism for downloading and installing application upgrades. Some of the problems were hard to solve, but none of them were in the rocket science category and most of the features are commonplace in applications today. Well, except for that offline browser thing - trust me, there is a reason why you don't see that kind of architecture deployed. Our business clients were so thrilled they immediately filed a patent application. I bring it up now because they appear to still be working on the application. Though long gone from that team, I have been asked to review the application today. I advised against this for three reasons. First, we had not invented anything new; we used existing technology to build an interesting solution that met our needs. Second, we did not really have an asset worth protecting. If I were to design this application over, I would take a completely different approach (that whole offline browser thing caused us a lot of headaches). Third, our goal was to provide our customers with improved service by reducing the amount of time it takes to complete an estimate (and large fire losses involving thousands of household items can take quite a while) and improving the accuracy of the estimate. If we met this goal, then what need is there for a patent? After all, our customers would be happy. Could some other company steal market share from us by implementing a similar application? Maybe, but only if we fail to take advantage of this asset through its use and marketing. Depriving other companies of the ability seems kind of petty, to me. |
