COM Memory Allocation Functions

[Frederick J. Harris]

I've been working on a PB low level coded COM based grid control, and have it working very well in my PowerBASIC and C++ test clients.  However, it's not working quite as well as I had hoped it would with either old VB6, or the newer VB.NET.  It's completely unusable in VB6 and crashes as soon as an event fires.  In .NET it actually works perfectly, except it seems to be fouling up its reference counting, and it's not releasing the object.  No crashes or anything; just not releasing.  I picked it up in my debug output file or otherwise wouldn't have noticed it.

Anyway, the grid started out as a simple custom control - not a COM object, and I used GlobalAlloc/GlobalFree for all my memory allocation work.  When I converted it over to a COM based control, I only used the COM memory allocators for the COM related stuff in IClassFactory::CreateInstance, so on and so forth (to create the object).  The code using GlobalAlloc came over into my COM code from the custom control.  My question is, should I replace all the GlobalAlloc\GlobalFree calls with CoTaskMemAlloc/CoTaskMemFree in the grid code?  I suppose I should?

I'm wondering if something related to that could be the source of the problems I'm having with VB6/.NET?  In our posts just the other day over in the PowerBASIC forums you mentioned Jose about how the COM memory allocation functions are setup to facilitate marshalling.  I sort of knew that, but had been discounting its importance in the context of in process servers like I'm working on right now.  Perhaps there is something to it though?  Maybe there is some sort of surrogate process involved, and my non-COM memory allocation functions are involved?

Something about my control is fouling up VB6 bad.  In the design environment only one of my six or seven event procedures is showing up in the drop down list boxes where events are shown.  The f2 button brings up a type lib browser thing where properties/methods of loaded type libraries are shown, and they all show up there, but not in the code editor.  Something is messing up VB6.  That's not true in .NET though.  Everything seems to work perfect there except for the failure to release thing.

I'd appreciate any thoughts anyone might have on this.  

[Dominic Mitchell]

My question is, should I replace all the GlobalAlloc\GlobalFree calls with CoTaskMemAlloc/CoTaskMemFree in the grid code?
I suppose I should?

No.  If a client or COM subsystem will never free or reallocate a buffer, how the object allocates a buffer for internal use depends on the preferences of the programmer who created said object.
For example, one could use CoTaskMemAlloc/CoTaskMemFree for the virtual tables, but I sure would not.
 

It's completely unusable in VB6 and crashes as soon as an event fires.

I suspect it would also crash in Phoenix.  
In my opinion, if the OCX does not work in a least VisualBasic 4.0 or 6.0 it has not been written properly.

[Frederick J. Harris]

Thanks for the info Dominic.  I was wondering about it.