|
You need to give more information.
What is the error message and when this happens.
Try to debug the application.
|
|
|
|
|
I m gettin type redefinition error,
Problem while using excel.h and excel.cpp file.
MoreOver These two files are not generated automatically, i used in VC6 and get that files and copied these files to my current project in vs2005.
The file supports in dialog based projects but not in SDI
Regards
Gany
|
|
|
|
|
Hi,
I am using the following code for years without any complaints. It is used by me in many apps, and included in libs, too many to count.
Always worked a dream.
It concerns an MFC Type CProgressDlg Base Class. A User would derrive his own class thereof, Set a Workerthread function, and the thing takes off as expected.
Here is the Header
<br />
#if !defined(AFX_PROGRESSDLG_H__07E71F2A_E348_47C9_B150_F02855B96859__INCLUDED_)<br />
#define AFX_PROGRESSDLG_H__07E71F2A_E348_47C9_B150_F02855B96859__INCLUDED_<br />
<br />
#if _MSC_VER >= 1000<br />
#pragma once<br />
#endif // _MSC_VER >= 1000<br />
<br />
enum{ <br />
WM_ENDDIALOG=WM_USER+1,<br />
WM_UPDATE_DATA,<br />
WM_SHOULD_TERMINATE,<br />
};<br />
<br />
<br />
class CProgressDlg;<br />
typedef DWORD (CProgressDlg::*PFN_PROGRESS_DLG_THREADPROC)(void);<br />
<br />
<br />
static int (ProgressDlgThread)(void*);<br />
<br />
<br />
class CProgressDlg : public CDialog<br />
{<br />
friend ProgressDlgThread(void*);<br />
<br />
DECLARE_DYNAMIC( CProgressDlg )<br />
<br />
public:<br />
DWORD GetThreadResult();<br />
PFN_PROGRESS_DLG_THREADPROC SetWorkerThreadProcedure(PFN_PROGRESS_DLG_THREADPROC pFn);<br />
void EndDialog(int ExitCode);<br />
BOOL ShouldTerminate(DWORD* pdwReason=NULL);<br />
CProgressDlg(UINT nIDTemplate,CWnd* pParent =NULL); <br />
<br />
protected:<br />
CRITICAL_SECTION m_cs;<br />
virtual void DoDataExchange(CDataExchange* pDX); <br />
virtual BOOL UpdateData(BOOL bSaveAndValidate = TRUE);<br />
virtual void OnOK();<br />
virtual void OnCancel();<br />
virtual BOOL OnInitDialog();<br />
<br />
DECLARE_MESSAGE_MAP()<br />
private:<br />
<br />
void _OnEndDialog(int ExitCode);<br />
void _OnUpdateData(BOOL bSaveAndValidate,BOOL*pbRes);<br />
PFN_PROGRESS_DLG_THREADPROC m_pFnThreadProc;<br />
BOOL m_bShouldTerminate;<br />
int m_nDlgStatus;<br />
DWORD m_dwDlgResult;<br />
DWORD m_dwThreadResult;<br />
CWinThread* m_pWinThread;<br />
<br />
<br />
<br />
};<br />
<br />
<br />
#endif // !defined(AFX_PROGRESSDLG_H__07E71F2A_E348_47C9_B150_F02855B96859__INCLUDED_)<br />
and Implementation.
<br />
<br />
#include "stdafx.h"<br />
#include "ProgressDlg.h"<br />
<br />
#ifdef _DEBUG<br />
#define new DEBUG_NEW<br />
#undef THIS_FILE<br />
static char THIS_FILE[] = __FILE__;<br />
#endif<br />
<br />
<br />
enum{<br />
THREADSTATE_NOT_STARTED=0,<br />
THREADSTATE_RUNNING,<br />
THREADSTATE_COMPLETED,<br />
}; <br />
<br />
IMPLEMENT_DYNAMIC( CProgressDlg, CDialog )<br />
<br />
CProgressDlg::CProgressDlg(UINT nIDTemplate,CWnd* pParent )<br />
: CDialog(nIDTemplate, pParent)<br />
{<br />
<br />
InitializeCriticalSection(&m_cs);<br />
<br />
m_pFnThreadProc=NULL;<br />
m_nDlgStatus=THREADSTATE_NOT_STARTED;<br />
m_dwDlgResult=IDOK;<br />
m_dwThreadResult=0;<br />
m_bShouldTerminate=0;<br />
m_pWinThread=NULL;<br />
<br />
}<br />
<br />
<br />
void CProgressDlg::DoDataExchange(CDataExchange* pDX)<br />
{<br />
EnterCriticalSection(&m_cs);<br />
CDialog::DoDataExchange(pDX);<br />
LeaveCriticalSection(&m_cs);<br />
<br />
}<br />
<br />
<br />
BEGIN_MESSAGE_MAP(CProgressDlg, CDialog)<br />
ON_MESSAGE(WM_ENDDIALOG,_OnEndDialog)<br />
ON_MESSAGE(WM_UPDATE_DATA,_OnUpdateData)<br />
END_MESSAGE_MAP()<br />
<br />
<br />
<br />
static int ProgressDlgThread(void* P){<br />
<br />
ASSERT(P);<br />
CProgressDlg* pDlg=(CProgressDlg*)P;<br />
ASSERT(pDlg->IsKindOf(RUNTIME_CLASS(CProgressDlg)));<br />
<br />
ASSERT(pDlg->m_pFnThreadProc);<br />
pDlg->m_nDlgStatus=THREADSTATE_RUNNING;<br />
<br />
pDlg->m_dwThreadResult=(pDlg->*pDlg->m_pFnThreadProc)();<br />
<br />
pDlg->m_nDlgStatus=THREADSTATE_COMPLETED;<br />
pDlg->EndDialog(pDlg->m_dwDlgResult);<br />
return 0;<br />
<br />
<br />
}<br />
<br />
BOOL CProgressDlg::OnInitDialog() <br />
{<br />
CDialog::OnInitDialog();<br />
<br />
ASSERT(m_pFnThreadProc);<br />
m_dwDlgResult=IDOK;<br />
<br />
m_pWinThread=AfxBeginThread((AFX_THREADPROC)ProgressDlgThread,this);<br />
<br />
return TRUE;
}<br />
<br />
BOOL CProgressDlg::ShouldTerminate(DWORD* pdwReason)<br />
{<br />
BOOL bShouldTerminate;<br />
<br />
EnterCriticalSection(&m_cs);<br />
if(pdwReason)*pdwReason=m_dwDlgResult;<br />
bShouldTerminate=m_bShouldTerminate;<br />
LeaveCriticalSection(&m_cs);<br />
<br />
return bShouldTerminate;<br />
}<br />
<br />
<br />
void CProgressDlg::OnCancel()<br />
{<br />
EndDialog(IDCANCEL);<br />
}<br />
<br />
void CProgressDlg::OnOK()<br />
{<br />
UpdateData();<br />
EndDialog(IDOK);<br />
}<br />
BOOL CProgressDlg::UpdateData(BOOL bSaveAndValidate)<br />
{<br />
ASSERT(m_hWnd);<br />
BOOL bRes=TRUE;<br />
::SendMessage(m_hWnd,WM_UPDATE_DATA,bSaveAndValidate,(DWORD)&bRes);<br />
return bRes;<br />
}<br />
<br />
void CProgressDlg::_OnUpdateData(BOOL bSaveAndValidate,BOOL* pbRes)<br />
{<br />
BOOL bRes=CDialog::UpdateData(bSaveAndValidate);<br />
if(pbRes)*pbRes=bRes;<br />
}<br />
<br />
PFN_PROGRESS_DLG_THREADPROC CProgressDlg::SetWorkerThreadProcedure(PFN_PROGRESS_DLG_THREADPROC pFn)<br />
{<br />
ASSERT(m_nDlgStatus==THREADSTATE_NOT_STARTED);<br />
<br />
PFN_PROGRESS_DLG_THREADPROC pfnOld=m_pFnThreadProc;<br />
m_pFnThreadProc=pFn;<br />
return pfnOld;<br />
}<br />
<br />
<br />
void CProgressDlg::EndDialog(int ExitCode)<br />
{<br />
ASSERT(m_hWnd);<br />
<br />
EnterCriticalSection(&m_cs);<br />
if(m_nDlgStatus==THREADSTATE_RUNNING){<br />
<br />
m_dwDlgResult=ExitCode;<br />
m_bShouldTerminate=TRUE;<br />
LeaveCriticalSection(&m_cs);<br />
<br />
return; <br />
}<br />
LeaveCriticalSection(&m_cs);<br />
<br />
ASSERT(m_dwDlgResult==ExitCode);<br />
<br />
try{<br />
::SendMessage(m_hWnd,WM_ENDDIALOG,m_dwDlgResult,0);<br />
}<br />
catch(...){<br />
return;<br />
}<br />
<br />
}<br />
void CProgressDlg::_OnEndDialog(int ExitCode)<br />
{<br />
try{<br />
m_pWinThread;<br />
m_dwDlgResult=ExitCode;<br />
ASSERT(::IsWindow(m_hWnd));<br />
<br />
if (m_nFlags & (WF_MODALLOOP|WF_CONTINUEMODAL))<br />
EndModalLoop(ExitCode);<br />
<br />
::EndDialog(m_hWnd, ExitCode);<br />
}<br />
catch(...){<br />
return;<br />
}<br />
<br />
}<br />
<br />
DWORD CProgressDlg::GetThreadResult()<br />
{<br />
return m_dwThreadResult;<br />
}<br />
<br />
Now, all works well in my latest App, until I want to End the Dialog.
All goes well,
CProgressDlg::EndDialog(int ExitCode)
is called, SendMessage calls OnEndDialog(...), which terminates successfully, and then the App terminates with an Exception.
In case you ask, why not trace and debug, the App behaves as expected in Debug Mode, I get this behaviuor only in the Retail version.
I got this far by setting 'StillAlive' traps in the retail version, and do not know how to get further.
Regards,
Bram van Kampen
|
|
|
|
|
Debug the retail version. Build it with debug information and proceed as normal. Debug don't really care if it's a release or debug build.
Steve
|
|
|
|
|
Did that.
It bombs somewhere in the bowels of USER32.DLL (for which I have NO code) as soon as I link with the MFC Retail Libs. It does this in One App only. I rebuilt another 5 Apps using Identical Code and Calling sequence, and it works fine.
Regards,
Bram van Kampen
|
|
|
|
|
Using SendMessage api thrown from same thread to same thread is problem in itself because SendMessage api is blocking call, better use PostMessage.
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
Never mind - my own stupidity is the source of every "problem" - Mixture
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
I'm not sure what you mean exactly, but using SendMessage to send a message to the same thread as the sender is fine (in fact it's the most common case).
Steve
|
|
|
|
|
ThatsAlok Using SendMessage api thrown from same thread to same thread is problem in itself because SendMessage api is blocking call
No!
The Doccumentation states clearly that SendMessage calls the WinProc immediately when called from the same thread.
This is what Windows itself does the whole time in a Single Threaded App.
Bram van Kampen
|
|
|
|
|
Bram van Kampen wrote: void CProgressDlg::_OnEndDialog(int ExitCode)
I doubt about this line. You will probably need to handle both the params from SendMessage. i.e. WPARAM, LPARAM.
Also
Bram van Kampen wrote: WM_ENDDIALOG=WM_USER+1,
Not recommended as these values are already used by windows for some other messages. But I don't think it will cause the problem you are facing.
Regards,
Sandip.
|
|
|
|
|
SandipG wrote: Bram van Kampen wrote:
void CProgressDlg::_OnEndDialog(int ExitCode)
I doubt about this line. You will probably need to handle both the params from SendMessage. i.e. WPARAM, LPARAM.
No, The use of the Params is optional. At Any rate, SendMessage lands safely at the handler. It trashes when SendMessage returns.
SandipG wrote: Bram van Kampen wrote:
WM_ENDDIALOG=WM_USER+1,
Not recommended as these values are already used by windows for some other messages. But I don't think it will cause the problem you are facing.
Well, what would you reccommend instead. It could not be the problem, because SendMessage lands at the correct Handler.
Thanks
Bram van Kampen
|
|
|
|
|
Bram van Kampen wrote: No, The use of the Params is optional. At Any rate, SendMessage lands safely at the handler. It trashes when SendMessage returns.
Yes, that is why i feel its the parameter issue. You can read more about it here[^] in the parameter counts section.
Bram van Kampen wrote: Well, what would you reccommend instead. It could not be the problem, because SendMessage lands at the correct Handler.
Also i said it is not the problem just not recommended. About this you can read here[^]
I hope it helps.
Regards,
Sandip.
|
|
|
|
|
SandipG wrote: Yes, that is why i feel its the parameter issue. You can read more about it here[^] in the parameter counts section.
Joe's essays saved my butt many times.
Kelly Herald
Software Developer
|
|
|
|
|
Humble Pie is being eaten here.
It was a Parameter issue. Entered a dummy int, and problem is gone.
It baffles me however that this does not seem to affect the Debug Mode.
Thanks to everybody for their invaluable help and Comments.
Regards,
Bram van Kampen
|
|
|
|
|
Bram van Kampen wrote: the App terminates with an Exception.
Stupid question, but does the exception give any further clues? It's some time since I used MFC but I recall that some windows need to be disposed in a different way in the desstructors.
It's time for a new signature.
|
|
|
|
|
Well, it fails on an Access error. Why was not clear, but See above.
Regards,
Bram van Kampen
|
|
|
|
|
Hello all,
i know it's a newbie question but i couldn't find a replic or a sample code for such stuf.
I have a CFormView Class and a CTest Class Derived CEdit Class.
on both of them i have the OnKeyDown function, but what i want to do is to call the OnKeyDown fucnt of the deriver CEdit Class from the first one..
I declared a var with CTest var on the CFormView class and in the ONKeyDown (of the CFormView i did like this
void CMy01View::OnKeyDown(UINT nChar, UINT nRepCnt, UINT nFlags)
{
this->cd2.OnKeyDown(nChar, nRepCnt, nFlags);
}
and here the one of the CTest Class
void CTest::OnKeyDown(UINT nChar, UINT nRepCnt, UINT nFlags)
{
MessageBox("Blood 2");
CEdit::OnKeyDown(nChar, nRepCnt, nFlags);
}
All go right but when i run it nothing will happen ?? how could i fix it ?? Thnk you
"The Ultimate Limit Is Only Your Imagination."
|
|
|
|
|
Did you add ON_WM_KEYDOWN to your CEdit derived classes message map?
Did you use DDX_Control to bind the edit control in the dialogue template to the instance of CTest in your Form View? I've just realised I didn't mention this when I suggested you implement a derived class of CEdit.
Cheers,
Ash
PS: I know this is complicated, hang in there!
|
|
|
|
|
Please dont remove/delete your messages once you think they have been answered - leaving them posted means someone else can read them to see if they have the same or similar problem as yours
(I noticed you deleted an earlier one)
'g'
|
|
|
|
|
@ Garth: Sorry for deleting the message, i thought it was like in other forums when it's solved we may delete it to avoid the dump.
@ Aescleal: I found a wasty manner to solve my prob (OnKeyDown related) which is
void CSdiView::OnKeyDown(UINT nChar, UINT nRepCnt, UINT nFlags)
{
if((nChar<=0x30)&& (nChar>= 0x39))
AfxMessageBox("Number");
CFormView::OnKeyDown(nChar, nRepCnt, nFlags);
}
BOOL CSdiView::PreTranslateMessage(MSG* pMsg)
{
BOOL bHandleNow = false;
switch (pMsg->message)
{
case WM_KEYDOWN:
switch (pMsg->wParam)
{
case 0x39:
case 0x38:
case 0x37:
case 0x36:
case 0x35:
case 0x34:
case 0x33:
case 0x32:
case 0x31:
case 0x30:
bHandleNow = TRUE;
break;
}
if (bHandleNow)
OnKeyDown(pMsg->wParam, LOWORD(pMsg->lParam), HIWORD(pMsg->lParam));
break;
}
return bHandleNow;
}
but i m only able to detected Numbers and Upper Cases Letters like A-Z and no a-z (another problem but at least i was able to detetect numbers an capital letters 
"The Ultimate Limit Is Only Your Imagination."
|
|
|
|
|
Hi
I have been searching the forum for a while now, but haven't found an answer for my question.
When I write code in C++, I seperate methods and such with blank lines. Thus dividing them into logical groups.
Well I do this in every language I write code in, but C++ is giving me a hard time with this. When I collapse the methods, it will also include my blank lines. I know I can use regions to do this, but since C# and VB do not have this behavior, I was wondering. Is this a certain setting in Visual studio or is het just a crappy way of making the layout? I'm using the express by the way.
Thanks in advance
Steven
|
|
|
|
|
Steven Solberg wrote: When I write code in C++, I seperate methods and such with blank lines. Thus dividing them into logical groups.
Same here, except I use a commented row of '=' characters.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
I use (have used) express editions of VC++ 2005, 2008 and now 2010 and none of them exhibit the behaviour you describe (if I understand correctly). If I have a method followed by a blank line, when I collapse the method the blank line is still visible.
It's time for a new signature.
|
|
|
|
|
|
This does not make a difference to the compiler, but it is easier to understand code when you look at it later on.
Like I said; I use blank lines to make the code look more logically grouped. I do use regions as well, but I don't like the hassle of having a bunch of regions nested in each other. Typically, when my screen gets too small to view all the code that belongs together I start inserting regions.
Example:
//Methods in a menu
private void btn1_onclick...
{
}
private void btn2_onclick...
{
}
private void btn3_onclick...
{
}
//Other methods or functions
private void someMethod1...
{}
private void someMethod2...
{}
edit: Oops... I'm still thinking C# lately, just act like this is correct C++ code :p
|
|
|
|
|
Bram van Kampen wrote: Who cares how I separate them!
I certainly don't; I was responding to someone else's question.
It's time for a new signature.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
Why does this make a difference.