|
Build a BITMAP from CDC::GetCurrentBitmap, use that to create a new CBitmap, put it into a CDC and BitBlt. I think if you grab GetCurrentBitmap, you'll have troubles as the DC owns it.
Christian
The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
|
|
|
|
|
If you create a simple microsoft Win32 DLL function, it creates an entry point file plus the stdafx files which contain the windows.h include file.
However, if you start adding header and cpp files which make reference to stuff like CRecordSet and have references to stuff like afxdb, then Windows.h and afxdb.h get in one another's way.
Then, if you comment out the windows.h and use afxdb.h, you get an error as following:
Linking...
nafxcwd.lib(dllmodul.obj) : error LNK2005: _DllMain@12 already defined in test2.obj
Debug/test2.dll : fatal error LNK1169: one or more multiply defined symbols found
Error executing link.exe.
And if you comment out the DLLMain at this point, everything compiles well.
Why does this happen? Can I not have a DLL with a DLLMain which also uses afxdb.h? How do I go about fixing this problem?
thanks
|
|
|
|
|
First, remove the windows.h include, and change it to afxwin.h.
Second, regular MFC DLLs are made completely differently from plain Win32 DLLs. You need a global CWinApp object, and MFC provides the DllMain().
--Mike--
Fetchez la vache!
My really out-of-date homepage
Sonork - 100.10414 AcidHelm
Big fan of Alyson Hannigan and Jamie Salé.
|
|
|
|
|
Hmmm.
Look at this code snippet :-
STDMETHODIMP CNishFirst::GetArray(BSTR **pbstrArray)
{
// TODO: Add your implementation code here
USES_CONVERSION;
BSTR *tmpArray[25];
for(int i=0;i<25;i++)
*tmpArray[i]=SysAllocString(A2W("Nish Test"));
*pbstrArray=*tmpArray;
return S_OK;
}
You'd think it was fine [ignoring that amazing warning I got which I had reported in the previous thread]
But when I tried to test the function using VB I got an error saying that I was attempting to use an OLE Automation feature not supported by VB! 
Nish
My most recent CP article :-
A newbie's elementary guide to spawning processes
www.busterboy.org
|
|
|
|
|
Aaah, you're going to love this, Nish.
To pass arrays in Automation, you're going to have to use the dreaded... SAFEARRAY. The old C-style array is not supported. Have fun with SAFEARRAY (I know I do!)
------------------------
Derek Waters
derek@lj-oz.com
|
|
|
|
|
Derek Waters wrote:
Aaah, you're going to love this, Nish.
I hope so too
Derek Waters wrote:
To pass arrays in Automation, you're going to have to use the dreaded... SAFEARRAY. The old C-style array is not supported. Have fun with SAFEARRAY (I know I do!)
Hmmm. Safe Arrays!!!
Nish
p.s. This ATL stuff is deeper than I imagined even though I had imagined it to be pretty deep, so you can guess how deep it really is.
My most recent CP article :-
A newbie's elementary guide to spawning processes
www.busterboy.org
|
|
|
|
|
interface INishFirst : IDispatch
{
[id(1), helpstring("method GetString")] HRESULT GetString([in] BSTR* pbstrInString, [out,retval] BSTR* pbstrOutString);
[id(2), helpstring("method GetArray")] HRESULT GetArray([out,retval] BSTR** pbstrArray);
};
It's showing an error :-
warning MIDL2039 : interface does not conform to [oleautomation] attribute : [ Parameter 'pbstrArray' of Procedure 'GetArray' ( Interface 'INishFirst' ) ]
Am I not allowed to have BSTR **s????
My most recent CP article :-
A newbie's elementary guide to spawning processes
www.busterboy.org
|
|
|
|
|
BSTR is already a pointer. So BSTR** is a "triple pointer" (omg!  ), which of course is not supported by automation.
From MSDN:
typedef OLECHAR FAR* BSTR;
|
|
|
|
|
You can have BSTR **, so long as you don't want your COM object to be Automation-compatible (ie usable in ASP). The Automation type standard is quite strict on this sort of thing.
------------------------
Derek Waters
derek@lj-oz.com
|
|
|
|
|
I might want to add:
- use BSTR for your [in] param
- use BSTR* for your [out] param
Edit: fixed the little bug in my 2nd statement 
|
|
|
|
|
|
Derek Waters wrote:
You can have BSTR **, so long as you don't want your COM object to be Automation-compatible (ie usable in ASP). The Automation type standard is quite strict on this sort of thing.
Thanks again Derek. I jus found that out 
Nish
My most recent CP article :-
A newbie's elementary guide to spawning processes
www.busterboy.org
|
|
|
|
|
Nish [BusterBoy] wrote:
I was just advised to use BSTR* as my out parameters
I meant to say that actually, must be smoking crack...
Sorry for the confusion
|
|
|
|
|
Just some more information...
The OLE Automation restriction is there for a reason. The idea is that if an interface supports OLE automation no external proxy code is required to marshal the calls.
I leave it to the reader to translated what I just said into English. I know for the longest time I had NO CLUE what any of that ment. (Heh, and I hope I got the statement right.)
Tim Smith
I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
|
|
|
|
|
|
Nish,It's also nice to use _bstr_t,it encapsulate the BSTR
data type.It manages resource allocation and deallocation through internall calls
to SysAllocString() and SysFreeeStrnig so you don't have to add
these function to your code.It provides a number of operators that enable you to use a
_bstr_t object as easily as you would use a CString.But one thing
that isn't provide,is the & "address of" operator,so can't pass the address of
a _bstr_t to a function that expects a BSTR *.
Hope that helps.
Mazy
"So,so you think you can tell,
Heaven from Hell,
Blue skies from pain,...
How I wish,how I wish you were here."
Wish You Were Here-Pink Floyd-1975
|
|
|
|
|
I am writing codes to put a view in a dialog.
Here are the code to initialize the view in a dialog:
BOOL CMyDialog::OnInitDialog()
{
CDialog::OnInitDialog();
CCreateContext pContext;
CWnd* pFrameWnd = this;
pContext.m_pCurrentDoc = new CMyDoc();
pContext.m_pNewViewClass = RUNTIME_CLASS(CMyView);
CMyView *pView = (CMyView *) ((CFrameWnd*)pFrameWnd)->CreateView(&pContext);
ASSERT(pView);
pView->ShowWindow(SW_NORMAL);
CRect rectWindow;
GetWindowRect(rectWindow);
ScreenToClient(rectWindow);
rectWindow.right += 15;
rectWindow.top -= 10;
pView->MoveWindow(rectWindow);
return TRUE;
}
I got two problems:
(1) If the CMyView is kind of CHtmlView and if the dialog is displayed within an MFC MDI application, when I clicked the view right after the view is displayed, I got an ASSERT in CView::OnMouseActivate(..). But if the dialog is the main window of a dialog-based MFC app, it works fine. Why?
(2) I use the following code to detect if there is memory leak:
void CMyDlgView::OnViewViewInDialog()
{
#ifdef _DEBUG
CMemoryState oldMemState, newMemState, diffMemState;
oldMemState.Checkpoint();
#endif
ShowDialog();
#ifdef _DEBUG
newMemState.Checkpoint();
if( diffMemState.Difference( oldMemState, newMemState ) )
{
TRACE( "Memory leaked!\n" );
}
#endif
}
void CMyDlgView::ShowDialog()
{
CMyDialog dlg;
dlg.DoModal();
}
if it is a CHtmlView derived view, there is memork leak; however if it is a generic CView derived view, no memory leak. Why?
|
|
|
|
|
It is this that got me thinking:
((CFrameWnd*)pFrameWnd)->CreateView(...) If I'm understading your code, pFrameWnd is a CDialog and not a CFrameWnd. My guess it that this works (when it does) due to pure chance, and it's no wonder weird things happen afterward. Maybe you can take a look at the source code of CFrameWnd::CreateView to try to determine what's going wrong.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
I have tried other method to create a view using something like:
CView *pView = pRuntimeClass->CreateObject();
pView->Create(...);
It got the same assert. However if I add (Overide) a message handler of OnMouseActive(..)of CMyView and just call CWnd::OnMouseActivate(..) within that handler, the ASSERT goes away. Odd!
|
|
|
|
|
One of the problems I've come across when using the CMemoryState items is that they tend to take an exact snapshot of memory. Good for some things, bad for others. It showed a memory leak in my code that was really just the fact that I took the snapshot before initializing an array and then comparing it to the array after it was freed and set to empty at the end of the function. The 'leak' went away if I took the snapshot after I did a memset to initialize the array instead of before. My guess is that the class initializes some structures and the difference is shown as a leak. If you use a trial version of one of the other memory checkers (BoundsChecker, Insure, etc...) then it might help determine if it's a real leak.
Good luck with the project.
|
|
|
|
|
Anonymous wrote:
My guess is that the class initializes some structures and the difference is shown as a leak. If you use a trial version of one of the other memory checkers (BoundsChecker, Insure, etc...) then it might help determine if it's a real leak.
Thanks a lot. Your argument is what I have been suspecting. I would try other memory check programs for this example. Hope you are right.
|
|
|
|
|
|
Have you included <tchar.h>?
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
|
My guess is I can't do this stuff on Win 98!!!
You can write Unicode stuff in Win98, altough you might not be able to run it (I've written Unicode things in Win95). The problem must lie elsewhere. Is TEXT also undefined?
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
