On May 18, 12:10 am, Justin Hansen <[EMAIL PROTECTED]> wrote: > I have successfully embedded the Mozilla engine into the project I > work on as a developer.
cool :) > I have managed to fix all major known bugs at this point accept one. i hope if any of them are our fault that you've found/filed bugs for them and provided patches. > What happens with this bug is that while in > full screen mode, if a user drags text from the mozilla web browser, > the application immediately appears to completely freeze, although the > mouse cursor still moves. to my knowledge, this doesn't occur with gecko in firefox/seamonkey, can you confirm that for the same source pull, you don't have that problem w/ them? what you're going to want to do is to set up remote debugging, I'd suggest using windbg, it's publicly supported by microsoft's newsgroups and has by far the most available methods. note that you don't technically need to use remote debugging, in theory you could try to rely on ctrl-break or the kernel debugger key, however, ime debugging DND and Clipboard/OLE operations is inherently dangerous (it's theoretically slightly better on Vista, but I don't have vista, so I'm not even sure if that's true). Basically once you've started the drag and things become unhappy, break in your debugger and get a stack trace. You'll of course need to have symbols for the build you're using (hopefully you've set up an internal symbol server, they're really quite nice. for the windows symbols, you'll want to use |.symfix+ c: \symbols| or something, windbg has lots of good help so this part won't be a problem). > When you alt tab out of full screen mode, > you get kicked to the desktop as expected. However, when you get to > the desktop you get this annoying dialog that says: "You cannot drop > an item onto a button on the taskbar. However, if you drag the item > over a button without releasing the mouse button, the window will open > after a moment, allowing you to drop the item inside the window." It > appears that once you close this dialog everything will go back to > normal. It appears that whatever is causing this dialog, is most > definately causing the frozen behavior of the application. It sounds like your gecko is a drag source but not a drop target, so basically you're starting a drag and there's no place to drop. this makes perfect sense. I'm fairly fuzzy about the details, but at least theoretically when you start a drag, the OS controls the mouse and starts talking to apps asking for one that's willing to reply to something like CAN_DROP or DO_DROP, and your app is basically not being helpful. > Now to drag and drop. Mozilla's default drag and drop functionality is not > allowing me to drag text to an editfield, so based on this fact, I > don't want d&d at all anyways. Seems like you'd be much happier getting drop enabled than disabling drag, but to each their own. > However, at this point my fealing is > that if I could somehow disable drag and drop, I could keep this > strange mouse bleeding through to desktop problem and we would avoid > the frozen behavior. Does anyone have any idea how I can disable > d&d? Not offhand, it shouldn't be too hard to use mxr.mozilla.org <http:// mxr.mozilla.org/seamonkey/search?string=drag&find=windows> to find the drag and drop code. <http://mxr-test.landfill.bugzilla.org/seamonkey/search? string=drag&find=windows> says Found 280 matching lines in 16 files, so there isn't too much to read. > Windows documentation and Mozilla documentation I find > insufficient regarding these areas. Thanks. _______________________________________________ dev-embedding mailing list [email protected] https://lists.mozilla.org/listinfo/dev-embedding
