StickyFront2 has been written to localise its operation to within each application - in other words, if one application crashes because of StickyFront2, no other application is affected. Hence it should be very easy to spot the application which StickyFront2 has trouble with. If after reading this troubleshooting guide you have bona-fide repeatable problems with a specific application, please feel free to fill in the bug report form.
Here are some common questions and answers:
That's a very good question, and we don't know why some people experience a noticeable slowdown when StickyFront is running whereas other people do not. StickyFront as part of patching itself in intercepts all window messages sent within the system - however, if it is not a message StickyFront is interested in (and there are only ten or so very infrequently called messages which are of interest) then extremely little code is executed. This in itself should not be noticeable when compared to the millions of wasted processor cycles caused by things like Explorer and etc.
Some applications open and then immediately shut a modal dialog box as part of their operation eg; when saving a file using a keyboard shortcut (eg; Ctrl-S) it may open a dialog, enter information for you, and close it. Normally this is so fast you don't ever see it, but because StickyFront alters the way modal dialog boxes work, the dialog will actually appear before being closed, causing screen redraw.
A big offender for this shown up during testing is MS Office 2000, in particular FrontPage 2000.
In short, you can't. StickyFront attempts to remove the redraw requests as they are generated through StickyFront's actions, but sometimes they slip through. Much of it depends on how the program is written to handle its window's being moved around and altered - some do redraw processing when this happens, resulting in the screen flicker you see.
If you could ask the author to stop using modal dialog boxes in their application, then StickyFront doesn't get itself involved and hence there wouldn't be a problem in the first place.
StickyFront only patches system "Edit" boxes. <techie> ie; all windows of global system class "Edit" </techie>. This is pretty much every writable text field in the system.
However, not all writable text fields are "Edit" boxes or derived thereof. Indeed, many writable text fields are entirely designed, created and managed by the application and hence there is no reliable way to know how to patch these successfully. Hence StickyFront leaves them alone.
One particular application which cannot be patched for drag & drop is MS Office 2000. Unfortunately it creates and manages its own explorer dialog's and for some extremely odd reason uses "RichEdit" boxes instead. The author has tried in every variation he can think of to patch "RichEdit" boxes, but for some reason just after inserting the path the entire application freezes, and there seems to be no explanation other than that clearly something in the control's handling code goes into an infinite loop. Who knows why, unless you're Microsoft?