|
Din Krop wrote:
SAFEARRAY *pString = StringParam.parray;<br />
BSTR *bstrArray;<br />
CComBSTR bstrRet;<br />
SafeArrayAccessData(pString, (void**)&bstrArray);
I did the following when using variants + safearrays:
long lowerBounds, upperBounds;<br />
SafeArrayGetLBound( StringParam.parray, 1, &lowerBounds);<br />
SafeArrayGetUBound( StringParam.parray, 1, &upperBounds);<br />
long nArgs = (upperBounds - lowerBounds) + 1;<br />
CComVariant* pvVariant;<br />
HRESULT hr = SafeArrayAccessData(StringParam.parray, (void**) &pvVariant);<br />
<br />
USES_CONVERSION;<br />
for(int i = 0; i < nArgs; i++)<br />
{<br />
char szTemp[255];<br />
if (pvVariant[i].vt == VT_BSTR)<br />
strcpy(szTemp, OLE2T(pvVariant[i].bstrVal));<br />
}<br />
hr = SafeArrayUnaccessData(StringParam.parray);<br />
if (pvVariant)<br />
delete pvVariant;<br />
This may help.
Regards
Barry
|
|
|
|
|
1. The following is wrong on several levels, it will create huge runtime problems. Please do not follow that example.
if (pvVariant)
delete pvVariant;
2. I am not familiar with CComVariant, but the next 2 lines look dangerous as well
CComVariant* pvVariant;
HRESULT hr = SafeArrayAccessData(StringParam.parray, (void**) &pvVariant);
safer approach fould be
VARIANT* pvVariant;
|
|
|
|
|
AleXO wrote:
it will create huge runtime problems.
Funny, never had any, boundschecker, + lint never complained either. Why would it cause problems then? Or should you really leave a dangling pointer?
Regards
Barry
|
|
|
|
|
1. It is not dangling pointer. It is a pointer to the memory allocated by ::SafeArrayCreate.
It should only be deallocated by matching SafeArrayDestroy.
2. This memory most probably allocated through HeapAlloc delete can not be applied here
3. even if #1 and #2 were not true (they are). the object that is allocated is of type VARIANT, not CComVariant.
|
|
|
|
|
AlexO wrote:
1. It is not dangling pointer. It is a pointer to the memory allocated by ::SafeArrayCreate.
It should only be deallocated by matching SafeArrayDestroy.
2. This memory most probably allocated through HeapAlloc delete can not be applied here
3. even if #1 and #2 were not true (they are). the object that is allocated is of type VARIANT, not CComVariant.
Looks like you're right about 1+2, but not about 3.
See http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_atl_ccomvariant.asp[^]
Regards
Barry
|
|
|
|
|
hi,
Thanx a lot for ur replay. 
When use in ASP I got exception error,
in vb I got error :
Method '~' of object '~' failed
regards.
|
|
|
|
|
even in VB/ASP you need error handling
|
|
|
|
|
Hello everybody:
Does any body has used the .exe server type in .NET?
After doing so I add an ATL Control class and build.
The control works without problems when I show it in Explorer or in Test Container.
Now I insert it into a normal .exe MFC dialog based application and want to add an MFC Class From ActiveX Control for this control, but it is not part of the "available ActiveX control" list.
If I add it from the .exe file and the execute the application the following error appears.
CoCreateInstance of OLE control {7A55CBB2-5043-43F4-894F-CD656330617E} failed.
>>> Result code: 0x800401f9
>>> Is the control is properly registered?
Unhandled exception at 0x7c17f774 (mfc70d.dll) in CallerPrueba2.exe: User breakpoint.
The control is in the register and Test Container and IExplorer don´t complaint about this.
Any helping hint?
Thanks,Jesus.
|
|
|
|
|
Hello,
Here is the problem I have run into. I have an Atl Server Web App that is structured like the following:
\bin (dll's)
\include (common srf that get included)
\secure (srf pages that need to be under SSL, also needs access to inlcudes)
*.srf general srf pages that need access to the includes
Here is the problem, when one of the general srf files uses an include the path for the include internal handler is \bin\something.dll. The path used for the include is relative to the file that included it, not the include itself. Now when one of the secure pages includes the same file the handler path to the dll is wrong, it tries to load the library from ...secure\bin\something.dll. This causes an issue, if the handler paths were relative to the actual file being rendered all would be well. Has anybody run accross this before and have any suggestions? Seems like the alternative is assign SSL access on a file by file basis? Other than this issue ATL server seems like a slick framework!
Thanks for any suggestions!
|
|
|
|
|
Did someone already tried to use GDI+ in a ATL DLL ?
I tried to just initialize GDI+ in the InitInstance and deinitialize it in the ExitInstance but seems like registration of the dll fails ???
Jonathan de Halleux.
|
|
|
|
|
If the registration of the dll failed, your code probably crashed in some way. Can't really say what is wrong.. Did you check to see that your input parameters to the gdi+ initialization functions are correct?
--
Only in a world this sh*tty could you even try to say these were innocent people and keep a straight face.
|
|
|
|
|
In docs is stated that you should not call GdiplusStartup or GdiplusShutdown in DllMain or in any function that is called by DllMain ( for solutions look for "GdiplusStartup" in MSDN).
|
|
|
|
|
Thanks ! It's working now. I had putted GDI+ initialization in the CWinApp::InitInstance and, in fact, it was called by DllRegister...
Jonathan de Halleux.
|
|
|
|
|
I have created a couple interfaces that do not have a coclass. The coclass's for these interface exists in different dll's. When I build my project these interfaces do not included into my dll.. I've created a dummy class that implements these interfaces and that works. Is there any other way?
thanks in advance.
|
|
|
|
|
How about #import "your.dll"?
--
Only in a world this sh*tty could you even try to say these were innocent people and keep a straight face.
|
|
|
|
|
Dear folks,
Consider 2 components, COuter that implements IOuter and CInner that implements IInner. OTOH, CInner is *auto aggregated* within COuter. By auto aggregation I mean it's aggregated within the COuter class using COM_INTERFACE_ENTRY_AUTOAGGREGATE ATL's macro.
Moreover, I've got some regular member methods on CInner, say, SetId, SetOrigin, and the like. These method *are not* on my IInner interface, they are placed as member functions of the class (as mentioned above). The IInner contains "Get" accessors, say, GetId, GetOrigin and the like so that the user could *only* obtain some information using the IInner interface. She cannot set anything on the object, since there's no "Set" accessors on IInner.
Now, I'm going to use the objects mentioned above, so that I can call those Set accessors within the program and the user could successfully get these values using the Get methods on IInner. I tried the following:
IOuterPtr spOuter;
HRESULT hRes = COuter::_CreatorClass::CreateInstance(NULL, IID_IOuter, (void **)&spOuter);
if(FAILED(hRes))
return FALSE;
CComAggObject<cinner> *pInner;
hRes = CComAggObject<cinner>::CreateInstance(spOuter, &pInner);
if(FAILED(hRes))
return FALSE;
pInner->m_contained.SetId(24950);
IInnerPtr spInner;
hRes = pInner->QueryInterface(IID_IInner, (void **)&spInner);
if(FAILED(hRes))
return FALSE;
But this is basically wrong, since the Inner object is *auto aggregated* ! Do you have any idea how I can create such things? Something like ITCallInfoChangeEvent that gives the user some informaiton via it's Get accessors, (get_Call and get_Cause to name a few) and user cannot set anything on this object, since it's got no Set accessor.
Any help would be highly appreciated,
Cheers
Mehdi Mousavi
|
|
|
|
|
How about plain old approach of simple object with two interfaces?
|
|
|
|
|
Well, I finally ended up in having 2 different interface on my inner object, one for initialization and the other one for Get accessors.
Cheers,
Mehdi Mousavi
|
|
|
|
|
I'm at the edge right now. I've spent all afternoon trying to create a client for the simplest of COM components.
I started an ATL project library. I added a class Calculator with the interface ICalculator.
Now I just want to make a trivial client that calls the Add method. I can't get anything to work. I try to include "../Calculator.h" into the Client code but I get errors with DECLARE_PROTECT_FINAL_CONSTRUCT. Including _Utils.tlb isn't helping at all.
Can anyone point me to where I can find a simple tutorial for creating clients for ATL 7.0 com objects?
Jared
jparsons@jparsons.org
www.prism.gatech.edu/~gte477n
|
|
|
|
|
You're including the wrong file I'm afraid.
If your COM-dll projects is named XYZ, include the autogenerated XYZ.h. Also make sure you include XYZ_i.c somewhere, perhaps stdafx.cpp? It contains the GUIDs related to your interfaces and classes.
Either that or #import "XYZ.dll"
--
Only in a world this sh*tty could you even try to say these were innocent people and keep a straight face.
|
|
|
|
|
In a tabbed property page I found out MS uses a gradiant to fill the the client area when using the XP visual styles & new common control library. On one of my property pages I have a child dialog derived from CAxDialogImpl<myclass>. Since this child control is at the bottom of property page I get a big white rectangle where my child dialog is.... it just looks bad.
The only solution i can come up with is move the controls on the child dialog into the property page. Anybody have any ideas, thanks in advance.
|
|
|
|
|
Where do all the WTL programmers hang out, is it just the Yahoo WTL mailing list. I'm trying to improve my WTL skills and I'm looking for good code examples and components besides the ones here at CP.
A Google search tends just to point me at the mailing list or at CodeProject and a few foreign language pages. Any suggestions on where I need to be hanging out.
Michael
Fat bottomed girls
You make the rockin' world go round -- Queen
|
|
|
|
|
I do not think you need special codes besides the ones here. All the MFC codes (at least most) translate into WTL easily, so just pick the basis and you will be fine.
Start some project yourself and you will have enough to learn. I just started my WTL project and is it a good learning process.
Best regards,
Paul.
Jesus Christ is LOVE! Please tell somebody.
|
|
|
|
|
You may know this one, but just in case
Bjarke Viksoe Home Page, see the URL:
viksoe.dk
ATL/WTL section.
Bjarke has been very nice publishing his work. Although there is not a lot of documentation, I've learnt a lot from his sources.
Best Regards,
Ramon
|
|
|
|
|
What is it we are not good enough for you? 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
