shell programming
-
what is the preferred way to share instantiations between different "instances" of the explorer shell (explorer.exe)? I have read the Dunn articles on shell programming and can't seem to share object instantiations between explorer.exe "instances". I have a ATL created shell extension that implements the context menu interfaces and in a single instance of the explorer, the code works fine; If i fire up a second instance of explorer.exe from the start task bar, and right click on a file, the code crashes, and the debugger takes me to the windows malloc.c src file. my memory model is such that I keep instantiated objects in the main application object (derived from public CWinApp), and want to use these objects from the new instances of the coclass that implements the IShellExtInit interfaces. I have used the SHGetMalloc call to get an IMalloc interface and use that for my mallocs. one of the objects is a iDispatch class generated from a typlib via the class wizard.. other classes are straight C++ impl classes that hold session data. -- Any help is appreciated! - steves sas
-
what is the preferred way to share instantiations between different "instances" of the explorer shell (explorer.exe)? I have read the Dunn articles on shell programming and can't seem to share object instantiations between explorer.exe "instances". I have a ATL created shell extension that implements the context menu interfaces and in a single instance of the explorer, the code works fine; If i fire up a second instance of explorer.exe from the start task bar, and right click on a file, the code crashes, and the debugger takes me to the windows malloc.c src file. my memory model is such that I keep instantiated objects in the main application object (derived from public CWinApp), and want to use these objects from the new instances of the coclass that implements the IShellExtInit interfaces. I have used the SHGetMalloc call to get an IMalloc interface and use that for my mallocs. one of the objects is a iDispatch class generated from a typlib via the class wizard.. other classes are straight C++ impl classes that hold session data. -- Any help is appreciated! - steves sas
From my experince on shell extension you should never initialise anything during InitInstance or thread attach/detach calls. All initialization should be in the IShellExtInit interface implementation only. The call to initinstance is very unpredictable and should not be used to initialise internal data. For example, When the dll it registered, at that time too initinstance is called, and your design could fail if you are assumeing that initinstance is called due to loading of dll by explorer.
I'll write a suicide note on a hundred dollar bill - Dire Straits
-
From my experince on shell extension you should never initialise anything during InitInstance or thread attach/detach calls. All initialization should be in the IShellExtInit interface implementation only. The call to initinstance is very unpredictable and should not be used to initialise internal data. For example, When the dll it registered, at that time too initinstance is called, and your design could fail if you are assumeing that initinstance is called due to loading of dll by explorer.
I'll write a suicide note on a hundred dollar bill - Dire Straits
thanks for the reply. THe IshellExitInit initialize method is called each time the file's context menu is displayed; At the very least, I need to to persist certain data in memory across context menu invocations (which works, btw). best case scenario is when I can persist data in memory across invocations of the explorer.exe (which I can't get working yet) Has anyone had experience with doing the above, short of serializing and deserializing at every menu IshellExitInit::initialize call? sas
-
thanks for the reply. THe IshellExitInit initialize method is called each time the file's context menu is displayed; At the very least, I need to to persist certain data in memory across context menu invocations (which works, btw). best case scenario is when I can persist data in memory across invocations of the explorer.exe (which I can't get working yet) Has anyone had experience with doing the above, short of serializing and deserializing at every menu IshellExitInit::initialize call? sas
Are you tring to presist interface pointer(s) across different instance of the explorer ?
I'll write a suicide note on a hundred dollar bill - Dire Straits
-
Are you tring to presist interface pointer(s) across different instance of the explorer ?
I'll write a suicide note on a hundred dollar bill - Dire Straits
thanks again for the help. I'm trying to persist instations of native contructs (like stl maps) and a straight C++ class instantations across different "instances" of explorer.exe. by "instances" of explorer.exe I mean invocations from the start menu (looking in the task manager process table; there is only one explorer.exe process however). from what i understand, IShellExtInit releated coclass gets created every time the user right clicks on a file name (bringing up the context menu). I want these instances of the coclass to be able to access my instantiations of my straight C++ class that lives at the app level (CWinApp dervied class). i'm pretty sure my problem is memory related; -- is there a good description on how the shell works when executing a new isntance of the explorer? It appearsthat the Esposito Shell programming book is out of print; this book probably has good info in it. -- any info is further appreciated. sas