|
Remove the registration build-step from the project and do it manually?
Alternatively, change the RGS file to register the classes in HKCU/Software/Classes explicitly, rather than through HKCR. HKCR is just an amalgam of HKCU/Software/Classes and HKLM/Software/Classes, so that should work OK.
These days, self-registering COM objects are passe - it's generally seen as more acceptable to have an installer (i.e. an MSI file install them).
PS - I agree with you about admin access. I develop as a limited user. It means I have no more privs than a user, so won't put operations requiring admin access into my apps. Big win!
|
|
|
|
|
PS - should have known, there's a CodeProject article addressing just this issue - see this[^] - just replace RegSvr32 in the registration build step with the RegSvrEx that this article talks about.
|
|
|
|
|
Stuart,
Thanks a lot for the links. I searched CodeProject before posting but apparently I suck at that too 
BTW about having the same admin privileges as your users, I tend to agree with you on the grounds that it makes for better software -- because the developers feel the pain that the users do. It's similar to the issue that developers tend to have high-end liquid-cooled hotrod systems that are 10x as fast as their customers'. Then we wonder why customers say the product is slow. Not gonna give up my machine though 
|
|
|
|
|
Ah, finally got it set up the way I wanted. I had already hunted in the project for regsvr32, or any sort of post-build step, but the registration was happening intrinsically. I finally found an option "Register Output" in the link options. Set that to false and got halfway there.
On the occasions where I need to register it, I could log in as admin, but instead I just run a batch file that contains this:
runas /noprofile /user:admin_user "\windows\system32\regsvr32.exe full_path_to_control.dll"
where admin_user is the name of the admin user. I'm prompted for the password.
So now I'm happy. Thanks for the links, that was enough to get me thinking along the right lines.
|
|
|
|
|
Hey, guys.
I'm instantiating ActiveX controls in an ATL toolbar for IE and having a problem with Invoke. If I put my class that wraps the control & container in an exe and run it, then when the test ActiveX object I create fires a mouse clicked event, I get it in Invoke without a problem. The test object also shows continual x,y position in its display window, so I can see it's getting mouse events.
However, when I use this same class in the dll which loads as the IE toolbar (IDeskBand stuff, if you're interested), creating the same ActiveX test object, Invoke isn't called when I click. The control behaves properly otherwise (I don't believe it's IE security stuff or the control wouldn't load and run). Still see the x,y updates from mousemove in the object's display area, and objects I create are responding and taking the appropriate internal action when I click the mouse, but no events get fired to Invoke. Curiously, however, I can explicitly call Invoke on that object from within the code and it works just fine, passing the parameters, etc.
So, I'm doing the standard QueryInterface for the connection point container, calling FindConnectionPoint, and then making a call to Advise(). Invoke gets called for the click event when compiled in an exe, but not in an IE toolbar dll. Anyone have an idea on the particular brand of weirdness I'm experiencing here?
Thanks!
|
|
|
|
|
It's a long shot (and probably teaching grandmother to suck eggs...)...but is your callback interface dual or a dispinterface? You want it to be a dispinterface.
|
|
|
|
|
Hey, I'll take any kind of shot I can get at this point.
I haven't been nose deep in ActiveX controls since the late 90s (and I've slept since then). Any notion as to why the difference in interface types could give me trouble?
And thanks for the help, man!
Chris
|
|
|
|
|
Christopher Duncan wrote: Any notion as to why the difference in interface types could give me trouble?
Yeah, a dual interface implements methods/properties as 'normal' COM methods (i.e. C++ virtual methods) as well as through IDispatch. This means that the callback interface you're implementing could be called through that rather than through Invoke.
A dispinterface only implements methods through IDispatch, so Invoke is the only entry point for callbacks.
|
|
|
|
|
I understand the difference between the types of interfaces, but what puzzles me is why it would work in an exe and not in a dll.
|
|
|
|
|
Different connection point container implementations? Only thing I can think of off the top of my head.
Another thing you could try (if you haven't already) is ATL's QI debugging (using _ATL_DEBUG_QI) - you can see what interfaces are being used. You can use DbgView[^] to trace the QI's when running outside Visual Studio.
|
|
|
|
|
Really appreciate you taking the time to help with this. Apologies for being a bit dense, but I want to make sure I understand...
I'm using the same code (it's a C++ class) and compiling that code in two different scenarios. In the test app exe, Invoke is called. In the toobar dll, it's not. Since it's the same code in both cases, does "different connection point implementations" refer to the connection point implementation of the control host?
That would seem a sensible neighborhood for the culprit since the control code is the same in both scenarios. So, if this is what you mean, would you have any suggestions on how I could debug the connection point implementations in these two scenarios?
Thanks again, man.
|
|
|
|
|
Christopher Duncan wrote: does "different connection point implementations" refer to the connection point implementation of the control host?
Yep
Christopher Duncan wrote: So, if this is what you mean, would you have any suggestions on how I could debug the connection point implementations in these two scenarios?
I guess the QueryInterface debugging would be a reasonable start. Also, if your interface is dual, make it a dispinterface - that should (he said!!) fix the problem.
|
|
|
|
|
Okay! First, I'll make it dispinterface, and if that doesn't do it I'll find some chickens to sacrifice. 
Thanks!
|
|
|
|
|
Hi
I have created an ATL application exe type (jjjj) where I am using to create ATL component
it gives following error
QLView.obj : error LNK2005: _CLSID_MyAWrapper already defined in jjjj.obj
SQLView.obj : error LNK2005: _LIBID_Project1Lib already defined in jjjj.obj
SQLView.obj : error LNK2005: _IID_IMyAWrapper already defined in jjjj.obj
Debug/jjjj.exe : fatal error LNK1169: one or more multiply defined symbols found
what to do here.. please suggest ..
thanks
Lee
Leya
|
|
|
|
|
I think you'll find this is caused because you're #including initguid.h in more than one .cpp file.
Make sure that it's only included in *one* cpp file explicitly. If it's in stdafx.h, take it out of there and put it in a .cpp file instead.
|
|
|
|
|
Hi,
I want to build a ATL wrapper on c++ class and would like to use that component in VB.
I insert an ATL class MyAWrapper
I add one property HRESULT String([out, retval] BSTR *pVal)
one method HRESULT ClearString() to IMyAWrapper.
IDL file shows it then in MyAWrapper.h
i put following c++ code
class foo
{
std::string m_str;
public:
foo(std::string bar, bool baz) : m_str(bar)
{
if (baz) throw std::exception();
}
std::string get_string(void) { return m_str; }
void clear_string(void) { m_str = ""; }
};
in ATL class.. class MyAWrapper I addfollowing code.
STDMETHOD(FinalConstruct)(void)
{
try {
m_pfoo = new foo("test", false);
}
catch (...) {
return E_FAIL;
}
return S_OK;
}
in MyAWrapper.cpp, I put
STDMETHODIMP MyAWrapper::get_String(BSTR *pVal)
{
// TODO: Add your implementation code here
if (pVal == NULL)
return E_POINTER;
std::string sTemp = m_pfoo->get_string();
*pVal = ::SysAllocStringLen(sTemp.c_str(), sTemp.length());
return *pVal ? S_OK : E_OUTOFMEMORY;
}
STDMETHODIMP MyAWrapper::ClearString()
{
// TODO: Add your implementation code here
m_pfoo->clear_string();
}
Please tell me Are these stpes OK??
or
where to put c++ code?
I can not compile the project.. I get around 34 errors one of which is
'std' : is not a class or namespace name
Pleasew tell me how to have this perfectly function.
Thanks
Lee
Leya
|
|
|
|
|
yang__lee wrote: std' : is not a class or namespace name
Probably, you forgot to include header, string in this case.
Prasad
MS MVP - VC++
|
|
|
|
|
Hi,
I am using CListBox on the Dialog using WTL, but i am unable to remove its flickering, when it get resized with Dialog. I am using CDialogResize for resizable layout for this app.
I have tried using WM_ERASEBACKGRND too but it wont help.
How is this flicker removed.
Regards,
R.T.
It is necessary once in one's life to put every thing in doubt, so far as possible, in order to reach the truth. DesCartes
|
|
|
|
|
Try using WS_CLIPCHILDREN with your dialog?
|
|
|
|
|
Already tried that :S. but of no use. Also i have already tried Other common methods concerning with windows properties. But i seriously think i have to override WM_PAINT, WM_DRAWITEM etc, but how is the main question.
Regards,
R.T.
It is necessary once in one's life to put every thing in doubt, so far as possible, in order to reach the truth. DesCartes
|
|
|
|
|
Respected, all i am trying a web page which needs to display clients computer name and local time in clients computer....when viewing a page stored in another server computer........plz help me
pokhrel rohit
|
|
|
|
|
Hi,
I have created a COM exe server using ATL8.0, where I have a connection point container interface that fires events for its clients (implementing sink). I am able to receive events at client side, but if I try passing an interface pointer(other than IUnknown) as an [in] parameter it becomes invalid at client side, that is, any method call on this pointer generates exception.
The same peice of code works perfectly fine with DLL server.
Can any one tell me the reason for this behaviour?
Is this problem due to different Address Space?
what is the solution to this problem?
Please Help.
Thanks in Advance.
Kavita seth
|
|
|
|
|
Hi, Kavita.
If your exe is operating as an out of proc server (i.e., your client code is not in the exe), then that would probably explain the different results. In a DLL / in proc scenario your client and server are operating within the same address space, and of course with an out of proc exe they're not. When you pass in a normal pointer (of any kind) from one program to another, it's going to be in foreign address space.
In general, I don't think that's your best way to go. Instead, consider doing a slight tweak to your code so that instead of passing back an interface pointer to the client, you instead just pass a param value back that tells the client, "now query for this interface on me and call it." Either way, the client calls the appropriate function, but this approach is more in keeping with the COM / QueryInterface way of doing things.
Hope this helps,
Chris
|
|
|
|
|
Hi Chris,
Sorry for such a late reply.
Thanks for your suggestion.
But I can not modify the IDL file as it is following some standards, hence my event has to pass the interface pointer.
One more update is there.
My client if written in VB6.0, is able to use that pointer.
But not my VC++ client.
So this appears not to be the problem of address space as VB client is able to call any of the methods of Server with the same interface pointer received along with the event.
Can you suggest any thing
Kavita seth
|
|
|
|
|
Hello Kavita,
Is the interface (passed in via the [in] parameter of the event method) a custom interface ? i.e. is it derived directly from IUnknown as opposed to being derived from IDispatch.
If so, one possible reason is that the Proxy/Stub DLL for the custom interface is not available. You need to build and register such a Proxy/Stub DLL.
For instruction on building and registering Proxy/Stub DLLs, please refer to my blog entry :
http://www.codeproject.com/script/profile/whos_who.asp?msg=1413206&id=24366#xx1413206xx[^]
Best Regards,
Bio.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
