Dan,
 
The popup menu doesn't work from an IE window if the search bar is also open on the taskbar.  If you close the search bar on the taskbar, the popup menu should be displayed in the IE window (I put code in the control to handle either case--I'd be curious if it doesn't work).  Basically, it gets confused when there are two instances of the searchbar open period.  AFFAIR, the hotkey interception doesn't work at all when the bar is in a window.  I don't think either of these problems is a big deal, but they limitations/bugs.  Also, you can only open search.him in a window from the current install directory, which is a security enforcement by the ActiveX control.
 
A while ago I added a method to tools.js, 'appendToFile(filename, contents)', for debugging.  It's a quick hack, really suitable only for debugging (as the comment says) because it actually rewrites the entire file each time.  But, it can be more helpful for debugging than alerts in some cases.
 
Glenn
----- Original Message -----
From: Dan Martin
Sent: Friday, May 10, 2002 10:16 AM
Subject: [DQSD-Users] Debugging

There must be a better way to debug than what I am doing.  First, DQSD won't open in a standalone IE window.  Is there a way to temporarily disable this check and allow it to open?  I know in previous versions, it would open in another window - it just didn't look very good.
 
The function I've written to add folders to the menu recursively calls itself.  Obviously it must - folders contain folders.  But, right now I've got a bug in the function, because it's infinitely looping.  If any of you have ever had DQSD infinitely loop you know that it is a complete disaster.  You have to kill explorer.exe to recover - assuming you can pull up the task manager before your runaway code consumes all the memory.
 
Also, the only way I can figure to debug is to "alert()" the contents of variables.  It works, but it can be slow going.
 
Any tips from the more experienced developers?
-Dan

Reply via email to