|
I'm such an idiot!!! It would help if FindClose cam before RemoveDirectory!!!!!
|
|
|
|
|
The calls to SetCurrentDirectory() are unnecessary. If the usage of this function is low, it probably makes no difference, but if it is an oft-used function, changing directories so many times is not efficient.
"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen
|
|
|
|
|
Hi,
I m developing an application that displays Bitmaps on Window....
he problem is that the bitmap dispayed using 256 color scheme, but i want show my bitmaps with high-resolution.
Thanks in advance.
|
|
|
|
|
|
Hi,
I m developing application that displays Window with Lines, Bitmaps, but I haven't used any Document-View Architecture.
I have developed Dialog-based application and then instead of displaying Dialog , I m displaying Window usig CFrameWnd class on InitInstance of Application.
When any other Window overlapes over my Application Window,it erases the Graphics.....
I tried to use OnPaint(ON_WM_PAINT) event to solve the problem , but the event has been called continuously...
I grately Thankful to have the solution as soon as possible.
Or is there any other ways to solve the problem.
Thanks in advance.
|
|
|
|
|
I would immediately scrap the project and create a new one using MFC instead of trying to violate it. CFrameWnd is the frame of a view. You are expected to have a view to draw the application data to. Using a CFrameWnd in a dialog-based application is very much trying to combine the worst from two worlds, just don't do it. If you have started out with a dialog-based application, and have now decided to go the full route with a proper SDI- or MDI-based application, the advice is the same: scrap the old application and create a new project with the wizard if you don't know how it should be built by hand.
Second, that you have a window not redrawing after being covered and then uncovered implies that you draw outside of OnDraw in the view. Ooops! You have no view - well well, outside the application main window WM_PAINT-handler then.
Calling OnPaint yourself is completely inappropriate - you are supposed to invalidate the view, which sooner or later triggers a WM_PAINT, which makes MFC call your OnPaint, which probably is not drawing anyway - implied from your error description. If you want to trigger an immediate redraw, call RedrawWindow.
So, one step back, get the hang of the structure of SDI/MDI-apps, not least as regards visual updating. Otherwise you'll get into lots of frustrating situations in the future.
|
|
|
|
|
hi:everyone:
tell you i have some model ,but some of them is written using ODBC,but others is written using ADO,now i want to integrate them into a big project,i want to know whether it is ok?
thank you
|
|
|
|
|
>> can ADO and ODBC be mixed
I don't know... did you try it? Did it work? 
"No matter where you go, there your are." - Buckaroo Banzai
-pete
|
|
|
|
|
You will need multiple connections to the database, one for ADO and one for ODBC. If this is acceptable I can't see why it would not work.
Ant.
I'm hard, yet soft.
I'm coloured, yet clear.
I'm fuity and sweet.
I'm jelly, what am I? Muse on it further, I shall return! - David Williams (Little Britain)
|
|
|
|
|
Hi there,
I have a group of three checkboxes. When I click on CheckBox2, a dialog box appears asking for user input. What it's suppose to do is when a user cancels a selection it should default to the first checkbox by making a call to CheckRadioButton. It does default but once the user clicks away from the application, the dialog box reappears as if the function to open up the dialog box is called once again. I isolated the problem and found that its the CheckRadioButton() that causes it. I don't know how or why but its the main source of the problem. How can I correct this?
Please see my code below. Thanks.
void CCheckBox::OnCheckBox2
{
CMyDialog dlg;
int nRet = -1;
nRet = dlg.DoModal();
// Handle the return value from DoModal
switch ( nRet )
{
case -1:
AfxMessageBox("Dialog box could not be created!");
break;
case IDOK:
{
..code...
break;
}
case IDABORT:
{
OnCheckBox1();
break;
}
case IDCANCEL:
{
OnCheckBox1();
break;
}
default:
break;
};
}
void CCheckBox::OnCheckBox1()
{
CheckRadioButton(IDC_RADIO1, IDC_RADIO3, IDC_RADIO1);
}
|
|
|
|
|
Sounds like recursive calls.
Kuphryn
|
|
|
|
|
But how is it recursive on the dialog box when all I am doing is checking the first check box? I can see it being recursive in that everytime I call CheckRadioButton() to check the first button it calls OnCheckBox1() again. I still don't understand why it would recursively call the dialog box as well. Help please. Thanks!
|
|
|
|
|
Are you calling UpdateData in the right place\correctly?
Sounds like the associated member variable is not being kept up-to date as you are expecting.
You may already know this, but its a possiblilty all the same!! 
|
|
|
|
|
I inserted UpdateData() at the beginning of both OnCheckBox1() and OnCheckBox2() and UpdateData(FALSE) at the end of each but it still doesn't work. It just doesn't like CheckRadioButton(button1, button2, button3) in OnCheckBox1(). That's what causes it to be recursive. Any ideas? Thanks.
|
|
|
|
|
Hi,
I want to minimize all windows before I start my dialog. Is there any command I can use or I should run the ShowDesktop.scf file? I know the file contains Windows Explorer Command as the following:
[Shell]
Command=2
IconFile=explorer.exe,3
[Taskbar]
Command=ToggleDesktop
Thank you in advance,
5iveboy
|
|
|
|
|
|
Dear all,
I want to execute a separate program from my dialog using a button. I have used WinExec, ShellExecute and CreateProcess and get the same problem. The button works fine as long as I build and run my program from Visual C++. But when I run the program independently by double-clicking its exec file from its folder and try the button, it does not work and the other application does not start. This happens on any operating system I tried. Here is the code:
HINSTANCE HINSCursorsd = ShellExecute (NULL,"open","../TestExeNew.exe",NULL,NULL,SW_SHOWNORMAL);
Your help is most greatly appreciated.
Thanks,
|
|
|
|
|
HINSTANCE HINSCursorsd = ShellExecute (NULL,"open","../TestExeNew.exe",NULL,NULL,SW_SHOWNORMAL);
The path is probably not the same
"No matter where you go, there your are." - Buckaroo Banzai
-pete
|
|
|
|
|
Original message:
I have read the codeproject article about Finding crash information using the MAP file, which was helpful, but I'm stuck.
I have a very complex program full of dialog boxes that are derived from a class that is derived from CDialog. Inside these dialogs are a bunch of edit boxes of type CTableFieldEdit, which is derived from CEdit.
The program works beautifully in debug mode, but crashes in release mode some time between when I create the dialog item and when I call DoModal()
From what I've been able to determine, the crash happens in MFC42.dll, but it crashes in two different places, depending on which dialog I'm calling. Some of the dialogs crash at the address for GetStyle and some of them crash after the address for ScrollWindowEx, according to the map file.
I have already turned off all optimizations.
I'm stuck. What might I be doing wrong?
I can post some or all of the code if it will help.
I can even post the entire project if you like, but you won't be able to run the program as it connects to a database.
Thanks!
Update:
The problem seems to be related to how I handle message maps in my derived dialog classes, but I don't know how to fix it or why it works correctly in Debug mode, but not Release mode.
Here's what's happening:
My Dialog boxes are derived from CFormHelperDlg, which is a class I made to reduce code redundancy.
CFormHelperDlg is derived from CDialog.
There are certain messages I want to handle in CFormHelperDlg rather than in the class for each given dialog (since all the code is redundant), so I set up my message maps as such:
In CJailDialog (which is derived from CFormHelperDlg):
BEGIN_MESSAGE_MAP(CJailDialog, CFormHelperDlg)
//{{AFX_MSG_MAP(CJailDialog)
//}}AFX_MSG_MAP
END_MESSAGE_MAP()
In CFormHelperDlg (which is derived from CDialog):
BEGIN_MESSAGE_MAP(CFormHelperDlg, CDialog)
//{{AFX_MSG_MAP(CFormHelperDlg)
ON_BN_CLICKED(IDC_BUTTON_JAN, OnButtonJan)
ON_BN_CLICKED(IDC_BUTTON_FEB, OnButtonFeb)
ON_BN_CLICKED(IDC_BUTTON_MAR, OnButtonMar)
ON_BN_CLICKED(IDC_BUTTON_APR, OnButtonApr)
ON_BN_CLICKED(IDC_BUTTON_MAY, OnButtonMay)
ON_BN_CLICKED(IDC_BUTTON_JUN, OnButtonJun)
ON_BN_CLICKED(IDC_BUTTON_JUL, OnButtonJul)
ON_BN_CLICKED(IDC_BUTTON_AUG, OnButtonAug)
ON_BN_CLICKED(IDC_BUTTON_SEP, OnButtonSep)
ON_BN_CLICKED(IDC_BUTTON_OCT, OnButtonOct)
ON_BN_CLICKED(IDC_BUTTON_NOV, OnButtonNov)
ON_BN_CLICKED(IDC_BUTTON_DEC, OnButtonDec)
ON_BN_CLICKED(IDC_MANAGER_SIGNOFF, OnManagerSignoff)
ON_MESSAGE(WM_INITDIALOG, OnInitDialog)
ON_WM_CLOSE()
//}}AFX_MSG_MAP
END_MESSAGE_MAP()
...each of those buttons exists on all the dialog boxes derived from CFormHelperDlg, so I'd rather just keep the message map there.
I've been using this all along because it worked fine in Debug mode.
I discovered the error was the message map by changing CJailDialog's message map to:
BEGIN_MESSAGE_MAP(CJailDialog, CDialog)
//{{AFX_MSG_MAP(CJailDialog)
//}}AFX_MSG_MAP
END_MESSAGE_MAP()
And suddenly there was no crashing.
Of course, it also didn't respond to the buttons anymore 
What do I need to do in order to make this work in release mode the way it works in debug mode?
|
|
|
|
|
Can you not add debug info to your appplication in release mode? This will allow you do run the software and get a call stack of where the crash occurs. From there you can backtrack to your most recent code that ran and hopefully find the problem.
If you vote me down, my score will only get lower
|
|
|
|
|
Call stack looks like this:
CWnd::GetStyle(const CWnd * const 0x0012f758 {CJailDialog hWnd=0x002d0b20}) line 195 + 1 byte
_AfxHandleActivate(CWnd * 0x0012f758 {CJailDialog hWnd=0x002d0b20}, unsigned int 1, CWnd * 0x00323fc0 {CMainFrame hWnd=0x003f011c}) line 145 + 11 bytes
MFC42! 5f401be9()
CWnd::WindowProc(CWnd * const 0x0012f758 {CJailDialog hWnd=0x002d0b20}, unsigned int 6, unsigned int 1, long 4129052) line 1596 + 27 bytes
AfxCallWndProc(CWnd * 0x0012f758 {CJailDialog hWnd=0x002d0b20}, HWND__ * 0x00000000, unsigned int 6, unsigned int 1, long 4129052) line 218
AfxWndProc(HWND__ * 0x002d0b20, unsigned int 6, unsigned int 1, long 4129052) line 377 + 16 bytes
AfxWndProcBase(HWND__ * 0x002d0b20, unsigned int 6, unsigned int 1, long 4129052) line 220 + 21 bytes
USER32! 77d43a50()
USER32! 77d43b1f()
USER32! 77d444f5()
USER32! 77d44525()
NTDLL! 77f75da3()
58000080()
I don't know about you, but that doesn't seem very helpful to me...
|
|
|
|
|
|
Alas, I had already read this article, to no avail.
|
|
|
|
|
what is function signature of your OnInitDialog member, if it is anything other than
LRESULT OnInitDialog(WPARAM wParam, LPARAM lParam)
the application is bound to crash in release mode.
Remember, OnInitDialog function is provided as a virtual function in CDialog already, and if you want to handle the WM_INITDIALOG message yourself, you need to at least name it differently, the way you are doing it, you are probably declaing it as
virtual BOOL OnInitDialog();
/yawar
I have no signature
|
|
|
|
|
I think I need to provide a little explanation of my response too, look at the expansion of ON_MESSAGE macro in AFXMSG_.H file
#define ON_MESSAGE(message, memberFxn) \<br />
{ message, 0, 0, 0, AfxSig_lwl, \<br />
(AFX_PMSG)(AFX_PMSGW)(LRESULT (AFX_MSG_CALL CWnd::*)(WPARAM, LPARAM))&memberFxn },
Anything you put in ON_MESSAGE macro has to have this declaration, the compiler generates the code and assumes that your function will have a return type of LRESULT and will take two parameters, WPARAM and LPARAM. If you declare return type different or make parameters different, you will end up corrupting the stack and hence the crash in release mode.
answer to question that why this won't crash in debug mode is simple, the debug executable has a lot of guard bytes before and after function calls, those bytes get corrupted but stack does not. Probably if the target function signature would be too big (20+ parameters) it will crash in debug too.
Let me know if this was the reason. I have gone in too much detail without even knowing if your bug really was because of bad function signature.
Ciao,
/yawar
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
