|
Actually, it isn't a template. It is straight plain C/C++. All I really did was fix the hash width and then store the hash information in the actual objects being hashed. Thus you get rid of any extra allocated memory devoted just to the hash map.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
Can anyone tell me how to permanently disable the STL compile warnings that I get each time I compile my code in debug.
The specific warning is C4786.
I am using Visual C++ 6.0 with SP5 and I am using the MS provided version of STL. Will moving to STLPort fix this?
|
|
|
|
|
What has always worked for me was to #pragma-down the warning level, and disable that specific warning.
This is what I use in a current project:
<br />
#pragma warning( push, 1 )<br />
#pragma warning( disable:4786 )<br />
#include <vector><br />
#include <iterator><br />
#include <string><br />
#include <map><br />
#include <stack><br />
#include <vector><br />
#include <xtree><br />
#pragma warning( pop )<br />
Peace!
-=- James (Sonork:100.21837)
"There is nothing worse than being oblivious to the fact that you do not know what you are doing."
[Get Check Favorites 1.5 Now!]
|
|
|
|
|
Thanks for the quick reply. I will try it out ASAP.
|
|
|
|
|
James R. Twine wrote:
#pragma warning( push, 1 )
what does this do?
modified 29-Aug-18 21:01pm.
|
|
|
|
|
> > #pragma warning( push, 1 )
>
> what does this do?
That pushes the current warning level/state onto an internal stack and changes the warning level to 1. The corresponding pop restores (pops) the previous warning level back.
Note that when you pop, any warnings that were specifically disabled/modified after push will return to their previous state.
Peace!
-=- James (Sonork:100.21837)
"There is nothing worse than being oblivious to the fact that you do not know what you are doing."
[Get Check Favorites 1.5 Now!]
|
|
|
|
|
I am somewhat new to proxy stubs. I have been playing around with building a proxy stub. So, I used VC6's to create ATL COM exe.
I have added a method to the interface and everything compiles and links and all that.
Now, I am trying to use CoCreateInstanceEx to instantiate this interface in my client application with the CLSID of my interface and using the CLSCTX_SERVER parameter. Everything compiles and links on the client as well, but when it gets to the CreateInstance part, I get an HR that indicates the Interface is not supported.
I am not sure if this is an open-ended question or not, but is there an easy fix to this? Have I missed a step or something?
thanks
|
|
|
|
|
IIRC, a proxy/stub is required when crossing apartments or remoting (DCOM). Have you built the ATL COM object with merged proxy/stub code?
Peace!
-=- James (Sonork:100.21837)
"There is nothing worse than being oblivious to the fact that you do not know what you are doing."
[Get Check Favorites 1.5 Now!]
|
|
|
|
|
I'm working on a new shell extension (I've written them before, just not this kind...) implementing IShellExtInit and IContextMenu. IShellExtInit::Initialize works correctly - but is called a random number of times (seems to depend on how long it takes me to step throuh the code) for a single action in Explorer. After about 1 to 3 times, the debugger breaks to this colling block of code:
<br />
template <class T, const IID* piid = &__uuidof(T), const GUID* plibid = &CAtlModule::m_libid, WORD wMajor = 1,<br />
WORD wMinor = 0, class tihclass = CComTypeInfoHolder><br />
class ATL_NO_VTABLE IDispatchImpl : public T<br />
{<br />
public:<br />
typedef tihclass _tihclass;<br />
STDMETHOD(GetTypeInfoCount)(UINT* pctinfo)<br />
{<br />
*pctinfo = 1; <br />
return S_OK;<br />
}<br />
The interface and typelib GUID for the template are mine (and other COM automation servers in the library work). What could be causing this problem?
I've tried approaching it from many different angles, but have yet to figure out 1) why IShellExtInit::Initialize is getting called multiple times before IContextMenu is even QI'd, and 2) why it'd break here (I'm sure it's related to #1).
TIA
"Well, I wouldn't say I've been missing it, Bob." - Peter Gibbons
|
|
|
|
|
Shell extensions aren't automation servers, they don't need to implement IDispatch. It's odd that the shell is QI'ing for IDispatch in the first place, actually. My first suggestion is to remove IDispatch from the extension coclass.
--Mike--
"I'd rather you just give me a fish today, because even if you teach me how to fish, I won't do it. I'm lazy." -- Nish
Just released - 1ClickPicGrabber - Grab & organize pictures from your favorite web pages, with 1 click!
My really out-of-date homepage
Sonork-100.19012 Acid_Helm
|
|
|
|
|
Right, I realize that they're not automation servers (I mean that automation servers exists in my library) but every example - including yours - leaves the default ATL stuff there (which extents IDispatchImpl). ATL put it there in the first place and it's never caused problems with the many other shell extensions I've written (what can I say, I'm never content). I agree that it's not needed, though.
I'll try removing that, however, and see what happens. Thanks for the tip.
"Well, I wouldn't say I've been missing it, Bob." - Peter Gibbons
|
|
|
|
|
Even after removing everything related to IDispatch, the problem persists: IShellExtInit::Initialize is called many times, with different addresses for the parameters, until the runtime finally throws an exception, such as the ol' access violation for reading memory at NULL.
The IShellExtInit::Initialize implementation is exactly as yours is.
"Well, I wouldn't say I've been missing it, Bob." - Peter Gibbons
|
|
|
|
|
i made an ATL/Com project and it works just fine in debug mode but when im trying to build Win32 Release MinDependency, i get this error:
LIBCMT.lib(crt0.obj) : error LNK2001: unresolved external symbol _main
ReleaseMinDependency/Tokenizer.dll : fatal error LNK1120: 1 unresolved externals
Error executing link.exe.
any suggestion?
|
|
|
|
|
MSDN Q291952 should solve this;
You could try the MinSize version to verify it builds first.
Steve S
[This signature space available for rent]
|
|
|
|
|
|
This is answered in the VC forum FAQ.
--Mike--
"I'd rather you just give me a fish today, because even if you teach me how to fish, I won't do it. I'm lazy." -- Nish
Just released - 1ClickPicGrabber - Grab & organize pictures from your favorite web pages, with 1 click!
My really out-of-date homepage
Sonork-100.19012 Acid_Helm
|
|
|
|
|
thanks a lot, that solved the problem.
|
|
|
|
|
I'm trying to get a file name. Sound easy enough.
CString strFileName;<br />
static TCHAR szFilter[] = "Comma Delimited (*.csv)\0*.csv\0All Files(*.*)\0*.*\0\0";<br />
<br />
GetDlgItemText(IDC_EDIT_LOOKUP, strFileName);<br />
<br />
CFileDialog dlg(TRUE, NULL, strFileName, OFN_HIDEREADONLY | OFN_OVERWRITEPROMPT | OFN_FILEMUSTEXIST , szFilter, NULL);<br />
<br />
if(dlg.DoModal() == IDOK)<br />
{<br />
TCHAR szFileName[MAX_PATH + 64];<br />
dlg.GetFilePath(szFileName, MAX_PATH + 64);<br />
<br />
SetDlgItemText(IDC_EDIT_LOOKUP, szFileName);<br />
}
The problem is when I call GetFilePath, I get an ATLASSERT, because the window handle is 0. I thought this should be straight forward. Everything else is populated okay, but clicking OK seems to kill the window handle before I get the file name. Or should I be calling a different function.
|
|
|
|
|
Try this in place of dlg.GetFilePath:
lstrcpy(szFileName, dlg.m_szFileName);
|
|
|
|
|
Ed Gadziemski wrote:
Try this in place of dlg.GetFilePath:
lstrcpy(szFileName, dlg.m_szFileName);
I did not bother trying that as its a protected member. But it works. 
|
|
|
|
|
m_szFileName is a public member, defined as follows:
TCHAR m_szFileName[_MAX_PATH]; // contains full path name after return
The reason GetFilePath asserted is that you referenced it after the dialog function returned. It no longer has a valid handle at that point.
|
|
|
|
|
Ed Gadziemski wrote:
m_szFileName is a public member, defined as follows:
Yep, I see what I did wrong now. When I browsed to the member, I ended up on the MFC Version, rather than the ATL version. In MFC its protected. I'll know next time to check which one I'm looking at.
Thanks for all your help.
|
|
|
|
|
GetFilePath() is only for use when writing a hook (notice how the method sends a window message). To get the selected file after the dialog is closed, look at the m_szFileName memeber of CFileDialog.
--Mike--
"I'd rather you just give me a fish today, because even if you teach me how to fish, I won't do it. I'm lazy." -- Nish
Just released - 1ClickPicGrabber - Grab & organize pictures from your favorite web pages, with 1 click!
My really out-of-date homepage
Sonork-100.19012 Acid_Helm
|
|
|
|
|
Thanks. I've since found examples of how its typically used when sub classing, which I suppose what templates are all about.
I'm new to WTL, and am still working out the differences with MFC. Getting there though.
|
|
|
|
|
I am using ATL/COM in visual C++. I want to ask that what is the difference between ReleaseMinSize build and ReleaseMinDependency build. I want to distribute my DLL such that no other DLL should be required. I am also using MFC support for that component.
The difference I noticed between two was that ReleaseMinSize generate DLL larger in size than MinDependency. From this I think that MinSize require no other DLL to be distributed and RealaseMinDependency require DLLS to be given with my DLL.
Any IDeas
Ahsan
Ahsan
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
