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.
Comments