tea time with meowkins

RadFileExplorer First File Always Selected Bug Solved

My latest challenge in the wonderful world of reporting software development was to figure out why when I selected an item from the RadFileExplorer, my client-side event handler for the itemSelected event always got the same file info.

My first thought was that the people over at Telerik were morons out to ruin my day, but fortunately, that is not true (although I still can't post to the forums for some reason, and I've never posted before).  No, the real problem was due to a bug in my custom FileBrowserContentProvider.  You see, the RadFileExplorer by default can only browse the raw file system, but I need to browse SharePoint document libraries, thus - custom file provider. 

Once I realized that it was most likely my custom file provider that was causing the problem, I felt somewhat relieved, because that would mean it was something I could fix and not have to wait on Telerik for, but it also depressed me a bit because I wasn't sure how to debug the code to find out what was actually wrong.  As far as I knew, my file provider was perfect.  I got a full list of the files and folders, and all the displayed information was correct, and so I had no hints to go off of, simply the fact that the same file item was being selected every time.

Then I remembered what Steve Maguire said about debugging in Debugging the Development Process.

"... the most efficient way to track down a bug is to set a breakpoint in the debugger, determine which piece of data is bad, and then backtrack to the origin of that bad data..."

So I did just that, I threw a "debugger;" line in my event handler, and began tracing backwards.  At first it totally sucked, because all of the callstack was anonymous javascript, but I pulled out a pen and paper, and I started working my way backwards, writing down what each mysterious variable was, and working out what was going on, and then it actually started to become entertaining!  I eventually found a method call to _findItemByPath(c), and I saw that the path, c, was the parent directory path of the file instead of the file itself.  I found the definition of _findItemByPath, and I saw that it was using this path (the parent directory) to locate the selected file.  But of course, all of the files in a directory have the same parent directory, and that's why the first file was always returned.  So I found the place where I was assigning that path, and changed it to the appropriate path.

Why was I setting the path to be the parent directory's path?  Well, I just read the method signature for creating a FileItem, and I saw that there was a location and a url to set.  I set the location to the parent directory and the url to the absolute url of the file.  But location is use used to retrieve the selected file, so I set that to the absolute url as well and everything worked peachy.

What did I learn from this experience?  Read the documentation a little more closely so that you don't create weird bugs that no one has an answer to in the community forums.  Also, follow Steve's advice when you can, and backtrack the bad data through the debugger until you find the origin of the bad data.

Creating Dialogs in Javascript or Passing Data Between Windows

For my latest project here at Windward, I needed to learn how to create a dialog using javascript.  It turns out that this isn't exactly a trivial step in javascript, and so if you're new to javascript like I am, then it takes a bit of effort to figure out what you have to do here.  Here's what I've worked out so far.

First, there are some canned dialogs that you can launch in javascript - alert, confirm, and prompt.  These are simple dialogs that display a message, ask for a yes/no, or ask for a text input.  That's all they do though, and they only display plain text data, so they're pretty lame.  If you want a more useful dialog, like a file browser or some kind of input form, these just won't do.

What you can do though is use the window.open method to load up your dialog.  You create an html file, let's call it dialog.html, and then you call window.open('dialog.html') from the window you want to open the dialog from.

Now window objects have an opener property that points to the window that called window.open.  So lets say our main page is index.html, and we click a button, and call window.open('dialog.html').  index.html is the opener of dialog.html, so by using the the opener property in dialog's javascript, you can get to properties and methods in index.html.

So using opener, there are at least two ways of passing data to the opener of the dialog.  Let's say your dialog is a file browser.  You can have the dialog set the value of a text box in the opener to the selected file.  This is the first way of passing data to the opener - find the appropriate controls in the opener, and set their values.

The second way of passing data to the opener is to call one of the opener's method.  So again, let's say your dialog is a file browser.  You can call opener.loadFile(fileName), for instance.  You're passing file name from your dialog into the opener's loadFile method.  Now the opener can do whatever it wants with that.

I'm thinking that in general, it will be a bit cleaner to call one of the opener window's methods, because then all you have to do in your dialog is stuff a data object and pass it to the method.  You don't have to know about any of the opener's controls.

Anyway, here's some example code to demonstrate this.  Mean time, I'll have to figure out how to make this a modal dialog.

This page is windowtest.html.  It's just a text box and a button, and the button opens the dialog window, browse.html.  browse.html will calls the loadFile method via the opener property.

<html>

      <body>

            <script type="text/javascript">

            function btnBrowse_Click()

            {

                  var browseWin = window.open('browse.html');

            }

            function loadFile(fileName)

            {

                  if (fileName == null)

                  {

                        alert("fileName null");

                        return;

                  }

                       

                  var txtFile = document.getElementById("txtFile");

                  if (txtFile != null)

                        txtFile.value = fileName;

                  else

                        alert("txtFile null");

            }

            </script>

            <input type="text" id="txtFile" />

            <input type="button" id="btnBrowse" value="browse..." onclick="btnBrowse_Click()" />

      </body>

</html>

This is the browser.html page.  It doesn't have any controls or text.  When it loads, it calls opener.loadFile("file.txt").  This is just a toy example, but of course, you can imagine having callLoadFile being called when an file in a list is clicked, and then passing that file's url to opener.loadFile.

<html>

      <body onload="callLoadFile();">

            <script type="text/javascript" >

                function callLoadFile() {

                    if (opener.loadFile != null)

                        opener.loadFile("file.txt");

                    else

                        alert("opener.loadFile null");

                }

            </script>

      </body>

<html>

How to use ASPxTreeList in Virtual Mode

I've had a lot of trouble figuring out how to use devexpress's ASPxTreeList in virtual mode, and after a lot of back-and-forth with the support team, I finally got a simple test one to work.  Now that I think about it, if I just tried to copy their example, it probably would have worked right away, but either way, I didn't truly understand it until now, so let me share what I've learned.

• You assign an event handler to each virtual mode event.  You must do this before adding tree list to Controls.
• Don't add any nodes manually, e.g., by AppendNode.
• VirtualModeCreateChildren will fire once for the root node.  Set the e.Children to the top level nodes.
• VirtualModeNodeCreating will fire once for each object in root node children.  Set the e.NodeKeyValue to a unique value, but it must remain the same value for the entire life of the tree list.  Also set the node column/field values here.
• The page is rendered.  The user now sees the top level nodes in the tree.
• The user clicks the plus (+) to expand a node.
• VirtualModeCreateChildren fires once for the root node.  Set the e.Children to the top level nodes.
• VirtualModeNodeCreating will fire once for each object in root node children.  Set the e.NodeKeyValue to the same unique value as before.  Also set the column/field values again.
• VirtualModeCreateChildren fires again for the node being expanded.  e.NodeObject is not null this time, it contains the value you assigned to the expanded node.  Set e.Children to the subnodes.
• VirtualModeNodeCreating fires once for each subnode.  Set their keys and values.  The keys must be unique and remain the same for the life of the tree list.

You have to build the tree anew each time from the root, down to the subnodes of the last expanded node.

Happy coding!