Neil

> Shouldn't you be releasing the pGFilters here so that you delete
> each of them rather than just the last?

 

Yes, I understand that now, thank you. That was the last resource
leak I couldn't understand, or find. Thank you very much. Without some
experience, it is difficult to determine which pointers are interfaces or
just data. There is even a info structure with an interface in it that needs
to be released. The documentation fusses about releasing each of the
IPin objects but is less pushy when describing the IFilter objects. The
Next() statement threw me ?? Newbie hell.

 

> Since you are using COM, you may need to CoInitializeEx or
> OleInitialize before loading Scintilla so that you can choose the
> threading model or OLE features. Scintilla does an old-style
> CoInitialize just to ensure drag and drop is available.

 

This info sent me in the right direction. My implementation goes
like this.
1. When the Scintilla control is created inside of the current
thread, it initializes COM for the thread. FilmCutter
requires the COM library be initialized for it's direct show
video player, the current documentation recommends that
I not worry about it, just coinitialize the COM if it is already
initialized good, if it is not it will be. Because FilmCutter
uses CoInitialize before creating the direct show interfaces,
FilmCutter should CoUnInitialize upon program exit.
2a Using OleInitialize before createwindow Scintilla works.
Using OleInitialize after createwindow Scintilla works.
Using OleInitialize in the flow anywhere makes the damm thing
work.
But only after the first call to the direct show interface.
After the second call it direct show it stops working again. ??
Using OleInitialize, OleInitialize, OleInitialize anywhere
works for three times then stops. ???
It appears that OleInitialize doesn't work the same as
CoInitialize. From the documentation.
"Typically, the COM library is initialized on an apartment
only once. Subsequent calls will succeed, as long as they do
not attempt to change the concurrency model of the apartment,
but will return S_FALSE."
Adding three makes it work until they are gone.
Wrapping the direct show interface with matching OleInit
and OleUninit does not work.
Using OleUninit after creatwindow Scintilla kills the drag
and drop.
I can go on but my direct show interface is OleUninitializing
the COM library for this apartment. For the thread it is good
but for the apartment, is gone as well as the Ole drag and drop.
Fix item 2a
Use OleInitialize before each call to my direct show interface.
This will add one leaving the one Scintilla came with on the dance
floor.
2b Add the OleInitialize at the end of the direct show call
restoring a COM library object and its many friends to the apartment.
If it were your choice, which do you think you would do?

 

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

 

> Controls act as thread synchronization objects: SendMessage
> synchronizes the caller to the target window's thread for the send.
With all due respect after the last couple of days, that is more than
I want to know.

 

This has been very helpful.
I have two workable fixes to choose from, a solution to a problem
I didn't plan on getting here, and a whole butt load of understanding
that I didn't have last week.

 

Thanks barely covers it, but thank you anyway.

 

How are you with the windows XP look and feel thing as it relates to
commonctrl32 and the win 32 api and the XP themes thing. And busted
or missing code in commonCtrl32.h and elsewhere that turns the common
windows tooltips control into sexy little shawdow without the tip.
Ever notice that many programs only have toolbar tooltips.

 

I am of course joking, you have better things to do. I just like digging
at Uncle Bill whenever I get the chance.

 

Robert
http://members.aol.com/avsfilmcutter

 

 

 

 

AOL now offers free email to everyone. Find out more about what's free from AOL at AOL.com.