|
Sk Mohiuddin wrote: After that i want to
create a text file in my application directory using '..\\' notation
Your notation depends on the current directory. How do you know where it points to at the moment?
There is sufficient light for those who desire to see, and there is sufficient darkness for those of a contrary disposition.
Blaise Pascal
|
|
|
|
|
Yes you can. But, as already pointed out by sashoalm, there must exist the folder MyApp\Temp inside the application current directory.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Thanks for the Suggestion
|
|
|
|
|
I am writing block which throws com exception and i have written code in following way.
GetDate() & SetDate(d) both throws exception.
Date d;
try
{
// Many statements can throws exception
d = GetDate();
SetDate(somedate);
// calculate some "value"
}
catch(_com_exception &)
{
// set value = 0;
}
try
{
SetDate(d); // reset date
}
catch(_com_exception &)
{
// set value = 0;
}
Even if both block throws same exception i cant put them in one try for the reason that in any case either it throws exception or not i want to reset date at the end.
Is this code looks good with consideration of good coding practices?
Thanks,
Perry
|
|
|
|
|
Well, in my opinion it depends on the goal of your app, since at least for me,it is good to make fully diference between every error code, and in your app. it seems that the situations are different, so for me this is good since personally, i hate long "if"/"try-catch" statements.
regards,
Hector.
|
|
|
|
|
I may be wrong, but Exceptions seem to me to be an unexpected error (out of bounds memory, couldn't allocate enough memory, divide by zero), while something like HRESULT return value schemes tend to look for and handle expected errors.
So to answer whether or not using try{}catch{} is good practice, you have to explain (to yourself or to us) why you're using them. Sorry for the generic answer, but coding is all about using the right tool for the job, just like anything else - otherwise you end up in this forum too often.[^]
|
|
|
|
|
I am creating one project in which my client is "MFC dialog based"( "exe" ) and dll is "MFC dll".
In MFC dll there is one dialog box that is access by Client application. This is done with the help of exported function but when in this exported function i use domodal than it crashes and an error message occur
"Unhandled exception".
I dont understand what is the issue ?? 
Is the problem occur because i am using resource of dll??
Thanks in advance.
Yes U Can ...If U Can ,Dream it , U can do it ...ICAN
|
|
|
|
|
|
Thanks for your reply Sandip but i am using AFX_MANAGE_STATE.
Yes U Can ...If U Can ,Dream it , U can do it ...ICAN
|
|
|
|
|
The debugger is your best friend.
Find the offending line and post the relevant code.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Thanks For your reply Pallini
After debugging the dll i knew that the crash occur when i domodal the dialog of dll.
Here is my code. ConfigurationCapture is exported function.
CConfigDlg is class having base class CDialog.
BOOL CCaptureScreen::ConfigureCapture(HWND hWndParent, CaptureData* lpData)
{
ASSERT(lpData);
if (!lpData)
return(FALSE);
lpData->bCaptureFullScreen = FALSE;
strcpy_s(lpData->szCaptureFilename,strlen(lpData->szCaptureFilename),"");
strcpy_s(lpData->szCapturePath,strlen(lpData->szCapturePath),"");
AFX_MANAGE_STATE(AfxGetStaticModuleState());
dlg = new CConfigDlg(lpData->bCaptureFullScreen, CA2T(lpData->szCapturePath));
BOOL bStat = FALSE;
if (dlg->DoModal() == IDOK) {--->Crash (UNHANDLED EXCEPTION)
bStat = TRUE;
lpData->bCaptureFullScreen = dlg->m_nFullScreen > 0;
strncpy_s(lpData->szCapturePath, MAX_PATH, CT2A(dlg->m_strPath), _TRUNCATE);
*lpData->szCaptureFilename = '\0';
}
return(bStat);
}
Yes U Can ...If U Can ,Dream it , U can do it ...ICAN
|
|
|
|
|
Shilpi Boosar wrote: if (dlg->DoModal() == IDOK) {--->Crash (UNHANDLED EXCEPTION)
Unless dlg is NULL, that's not where the exception occurs.
It's in the MFC code somewhere....where?
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.freetls.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
Didnt get your point??? 
Yes U Can ...If U Can ,Dream it , U can do it ...ICAN
|
|
|
|
|
I re-asked the question - where is the exception occurring?
It's not on the line you indicated unless your variable "dlg" is NULL.
You can step further in to find a more specific cause of the exception.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Yes the crash occur in when i domodal the dlg.
suppose i take this example
http://www.codeproject.com/KB/DLL/beginnerdll.aspx[^]
now i add one more class CDlg in it and add dialog box having id IDD_DLG.
dlg.h is like this
#pragma once
#include "afxwin.h"
#include "resource.h"
class CDlg :
public CDialog
{
public:
CDlg(void);
~CDlg(void);
enum { IDD = IDD_DLG };
};
and dlg.cpp is like this
#include "StdAfx.h"
#include "Dlg.h"
CDlg::CDlg(void)
{
}
CDlg::~CDlg(void)
{
}
IN myClass.h
i #include the dlg class and create object of m_dlg.
in function say hello i add line
m_dlg.DoModal();
Please check when i domodal the function than crash occur.
It anything wrong here.
Same problem is in my project also.
Yes U Can ...If U Can ,Dream it , U can do it ...ICAN
|
|
|
|
|
It's hard to tell without the exact exception message and the exact code
where the error occurs.
Can you put a breakpoint on the DoModal() call and step into
the MFC code with the F11 key? You should be able to step to where
the actual exception occurs. The DoModal() call is too high in the
call stack for anything meaningful
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Ok you mean to say that in standard MFC files.
The function where the crash occur is AfxCallWndProcFile name is wincore.cpp
// delegate to object's WindowProc
lResult = pWnd->WindowProc(nMsg, wParam, lParam);
And the crash occur here
Please now tell me where i am wrong
Yes U Can ...If U Can ,Dream it , U can do it ...ICAN
|
|
|
|
|
Did you use a parent window for the dialog created in the EXE?
If so, that won't work. You have to use an MFC extension DLL
to share MFC objects between an EXE and a DLL.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
I am creating dll using MFC extension dll but linking error occur
mfcs90ud.lib(dllmodul.obj) : error LNK2005: _DllMain@12 already defined in dllmain.obj
1> Creating library C:\Documents and Settings\shilpi.boosar\Desktop\WdCaptureScreen\Debug\WdCaptureScreen.lib and object C:\Documents and Settings\shilpi.boosar\Desktop\WdCaptureScreen\Debug\WdCaptureScreen.exp
1>C:\Documents and Settings\shilpi.boosar\Desktop\WdCaptureScreen\Debug\WdCaptureScreen.dll : fatal error LNK1169: one or more multiply defined symbols found
1>Build log was saved at "file://c:\Documents and Settings\shilpi.boosar\Desktop\WdCaptureScreen\Debug\BuildLog.htm"
1>WdCaptureScreen - 2 error(s), 0 warning(s)
Yes U Can ...If U Can ,Dream it , U can do it ...ICAN
|
|
|
|
|
You'll need to setup your DLL project correctly to use MFC.
You don't have to use an extension DLL, but you need to
understand the ramifications and choose the type of DLL you need.
What you need to know: Kinds of DLLs[^]
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
I generated a function use the wizard which is like:
VARIANT GetData(VARIANT id, VARIANT *name);
In the idl file, it is:
[id(3), helpstring("method GetData")] VARIANT GetData(VARIANT id, VARIANT *name);
And I also tried to modify it to:
[id(3), helpstring("method GetData")] VARIANT GetData(VARIANT id, [out] VARIANT *name);
But neither works when I tried to use it in VB code like this:
Dim name Ad Object;
MyCtrl.GetData(1, name);
Here is the error infomation:
Additional Information: An invalid VARIANT was detected during a conversion from an unmanaged VARIANT to a managed object. Passing invalid VARIANTs to the CLR can cause unexpected exceptions, corruption or data loss.
What's wrong?
|
|
|
|
|
followait wrote: And I also tried to modify it to:
[id(3), helpstring("method GetData")] VARIANT GetData(VARIANT id, [out] VARIANT *name);
Modify the attribute for the last parameter to
[id(3), helpstring("method GetData")] VARIANT GetData(VARIANT id, [out, retval] VARIANT *name);
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
can't compile then, it says:
invalid use of "retval" attribute :
In fact I have multiple return valus, not only name,
it'll like this
[id(3), helpstring("method GetData")] VARIANT GetData(VARIANT id, [out, retval] VARIANT *name1, [out, retval] VARIANT *name2);
|
|
|
|
|
followait wrote: In fact I have multiple return valus, not only name,
This is one of the reasons it won't compile.
It seems to me like you've misunderstood the meaning of "return value".
If you have a function declared as
bool MyFunc( int nTheInt, DWORD* pdwTheResult ); it will return a boolean value, but you can expect some kind of result of the operation in the DWORD-value. The return value in this case would be to inform the caller whether the operation was successful or not.
And I also noticed that you've already declared a VARIANT as return type in you IDL-file here:
[id(3)] VARIANT GetData(VARIANT id.......<small>the rest omitted for brevity</small>
This is allowed since the MFC framework will hide the actual HRESULT that is returned from all COM calls and return the VARIANT type in your case. If the returned HRESULT would happen to be an error code the client will throw an exception, or some equivalent depending on what language the client is implemented in.
Your IDL should probably look something like
[id(3)] BOOL GetData(VARIANT id, [out] VARIANT *name1, [out] VARIANT *name2); where the "return value" is a boolean that informs the caller whether the operation was successful or not. The result of the operation is given in the two arguments name1 and name2.
This means that in your VB code you would call the function similar to
Dim name1 As Object
Dim name2 As Object
Dim success As Boolean
success = MyCtrl.GetData( 1, name1, name2 )
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Thanks very much.
I'm clear now.
But there is a problem when running, when returning from GetData,
an error is encountered:
Additional Information:
An invalid VARIANT was detected during a conversion from an unmanaged VARIANT
to a managed object. Passing invalid VARIANTs to the CLR can cause unexpected exceptions,
corruption or data loss.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
