Neil, >> If it were your choice, which do you think you would do? >Don't uninitialize COM/OLE. A leak is less of a worry than drag and >drop failing. There's a good chance that there are unbalanced >initializes and uninitializes but it may be difficult to find them. No, no, of course not, no Uninitialize. I fear that I have not correctly asked my question. The direct show interface, when released, effectively performs an OleUninitialize, if it actually does or not I do not know. I can however mimic the behavior with repeatedly using OleUninitialize and OleInitialize. CreateWindow(0,"Scintilla"... ) ... dnd ok OleUninitialize ... dnd not ok OleInitialize ... dnd ok So createWindow(0,"Scintilla"...) ... dnd ok DShow up / down ... dnd not ok OleInitialize ... dnd ok What ever happens, when the filter graph manager is released, drag and drop is non functional when we return to the scintilla editor. I do nothing but pFGM->Release(). I am totally black-boxing the direct show interface ( I do not know how to do anything else ). I only call CoInitialize for the COM because before the use of Scintilla I had to, and I do as the documentation recommends call CoUninitialize at program termination. Probably to much information, but the question remains. Would you add a OleInitialize() statement before you bring up the direct show interface and call OleInitialize() after releasing the last direct show object? >> > You should read up on COM with threading. I haven't done any work >> > in this area for years. >> >> Ya think ? With threading ? Do you mean it gets worse.
> Don Box's book Essential COM is only around 400 pages and is a > much easier read than the alternatives. Thank you, I hope to never need that much information, I will add it to my reading list. More drag and drop stuff. I added drop files support to FilmCutter, there is something more my speed. I noticed that FilmCutter with Scintilla's drag and drop working acts as a drop source for an appropriate drop target on the desk top. But I noticed also that FilmCutter is never an appropriate drop target. So I have dug a little deeper into the subject and find myself a little frustrated at my limitations. I first considered that Scintilla's container would be required to provide the target object interface. Looking into the SciTE source code I came up a little empty. I see that the Scintilla's source has reference to the drop source and target objects, but so far I can't figure how you get the first drop target object pointer. My question, which part provides that drop target objects Scintilla or SciTE? If the answer is Scintilla, looks like I have broken something else. In my search for a container driven solution, I ran across _www.catch22.net_ (http://www.catch22.net) and Mr. Brown's drop target source example. What I discovered in his example uncovers another question regarding my original problem with Scintilla loosing its drag and drop. Mr. Brown uses the function CoLockObjectExternal to lock and unlock his drop target objects, which begs the question. Could using "CoLockObjectExternal" protect the Scintilla com library objects from whatever direct show does to them? Rob <BR><BR><BR>**************************************<BR> AOL now offers free email to everyone. Find out more about what's free from AOL at http://www.aol.com.
_______________________________________________ Scintilla-interest mailing list [email protected] http://mailman.lyra.org/mailman/listinfo/scintilla-interest
