|
Thanks for your replies, Bob.
It actually doesn't crash when nCode is 0xFFFFFFFF or 0x00000000 (which is what it's set at when it does crash), so the nCode isn't at least obviously what's wrong. I tried putting the breakpoints back in but it kept interrupting my menu clicks by breaking, so I inserted this code first thing in CMainFrame::OnCmdMsg:
CString message;<br />
FILE * outfp;<br />
outfp = fopen("debuginfo.txt", "a");<br />
if (nID == ID_APP_EXIT) { <br />
message.Format("message: nID=0x%X, nCode=0x%X, this=0x%X\n", nID, nCode, this);<br />
fputs(message, outfp);<br />
}<br />
fclose(outfp);
That will append to the a debug file and only output when the message it's handling is ID_APP_EXIT. I opened the text file and found this:
message: nID=0xE141, nCode=0xFFFFFFFF, this=0x334AA8
message: nID=0xE141, nCode=0x0, this=0x334AA8
message: nID=0xE141, nCode=0xFFFFFFFF, this=0x334AA8
message: nID=0xE141, nCode=0x0, this=0x334AA8
So this stays valid the entire time. The only thing I have in OnAppExit() is "exit(0);".
About the stack, I fixed some bugs that I could fix earlier using the stack and it helped me figure out where things went wrong. I might pass by value here but expecting an address there, giving me access violation errors. This one just puzzles me.
|
|
|
|
|
Did you write your own OnAppExit, adding the "exit(0)" or was that in the base class? When you use AppWizard to build the program, you don't have to worry about overriding methods like OnAppExit, unless you really really need to. The base class implementation will do just fine. You don't need to add an explicit exit() call, since this will be taken care of automatically.
As far as looking at the this pointer, I was suggesting looking at the pointer in the Watch window. Once you've hit your breakpoint in the code, you can open the Watch window by selecting View->Debug Windows->Watch from the main menu. Add this to the list of watched variables, and it'll show up like a tree where you can expand and look at the member variables.
It's entirely possible that "this" or something within "this" has been destroyed while the pointer itself remains "valid." Within your block of code that dumps command info to the debug file, you may consider breaking there and just examining what's inside "this." If you see anything that looks "off kilter," that may suggest the problem.
You can always add some assertions within your debug block as well. Check things like ASSERT(GetSafeHwnd()) and do the same for the Frame's main View. At some point, the window handles may have been released without your knowledge.
Bob Ciora
|
|
|
|
|
I think I just took the template project I built onto it, but I think I put "exit(0)" there. I tried removing it and the menu didn't exit the app. I also run a function to terminate serial communications in the deconstructor and I tried remarking that out but that didn't help.
I have been looking at this because it is important. The problem is the crash occurs in uxtheme.dll under 8 layers of dll calls that I don't have the source for so I can't identify what individual variable is causing the crash so I can't trace it's path back. The last place on the stack that VS can retrieve sources for is in mfc70d.dll and I can see this and some items are null and some aren't and I don't know what to look for. The app is in the process of being deconstructed so even some items being null should be normal.
In an effort to fix the situation, I dumped the information I thought most relevant into a webpage if you want to look at what I'm looking at. Sorry if the middle column is too wide. It would have taken an immense amount of time to shift the columns over to get a better approximation of the tree structure of this, so I improvised. You have the minus and plus signs to help out, plus I applied different text styles to the page. this is bold and italic and is at the highest level. The bold items are directly under this. The italic items are directly under the bold item it follows. Again, I don't know what to look for and I have no recourse, except to strike the Exit menu item and force users to use the close box if this won't work.
|
|
|
|
|
Have you tried a full recompile of everything? I've sometimes found that this cures these problems. Sometimes, the incremental compilation/linking fails to produce correct code.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
yeah, I cleaned the project then rebuilt it, no change, both Release and Debug versions too.
|
|
|
|
|
i m working with MFC application and i have two listbox contaning float values. now i want to plot a graph as one listbox data considers as x axis and other as y axis so how to plot listbox data on graph and also how to make such as it limits changes accordingly as the values in listbox changes.
|
|
|
|
|
well, first you need to create a window to display the graph on. I'm assuming you know how to create a window already. Inside the window's OnPaint method, use the CDC object's MoveTo and LineTo functions.
-- Rocky Dean Pulley
|
|
|
|
|
There are some great free controls on codeproject for this, much simpler than doing your own.
NTGraph 2D
NTGraph 3D
|
|
|
|
|
This is not a question about some error that I may have. I am asking for your advice since this is the first (somewhat big) application for me.
Where would you save the options of a program ( like directories, and many other stuff),...in the registry...or using an options files.
And what is the best practice of those during, first the testing period (I have to give samples to my friends), and second after everything is done.
Thanks
|
|
|
|
|
Using options files is generally easier. Easier to code, and easier for users to modify directly if they need to. The other advantage to using files is that the application will be easier to port to another operating system. Outside of those advantages, the registry is a fine place to store stuff, but don't store too much junk there. If your options file ends up being a few hundred kilobytes, you may want to stick with a file and not clutter up the registry.
-- Rocky Dean Pulley
|
|
|
|
|
I would strongly recommend using one or more files. Your users (and testers) will bless you when they move your app between machines. The registry is evil. No, really.
/ravi
My new year's resolution: 2048 x 1536
Home | Articles | Freeware | Music
ravib@ravib.com
|
|
|
|
|
Two votes for files...
Thanks for your suggestions
M Tarik
|
|
|
|
|
I usually Prefer Registry,as at some secure system you don't have write access in your C:\ (generally wher your program is installed).
so to play safe bet i prefer saving my option in Registry (at least even in some part of HKEY_CURRENT_USER ,even Guest account has Write Priviledge).
"I Think this Will Help"
[Vote One Here,.....]
<h5
alok gupta="" <br=""> visit me at http://www.thisisalok.tk
|
|
|
|
|
Could someone lead me to a source for writing to and reading from COM1 in pure binary mode as simple as possible. Looking to send and receive single bytes in range of 0x00-0xff. The final code needs to work on WinXP platform. Thanks.
|
|
|
|
|
|
these are my codes for image processing...im not sure why im getting this " INTERNAL COMPILER ERROR". pls help me...and pls do tell me whether if i continue with this codes, will i be able to perform thinning and edge detection..i have problems in developing the codes..pls do help me and i sincerely appreciate all the helps..thank you...
#include "stdafx.h"
#include "fvas.h"
#include "fvasDlg.h"
#include <math.h>
#ifdef _DEBUG
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif
/////////////////////////////////////////////////////////////////////////////
// CAboutDlg dialog used for App About
class CAboutDlg : public CDialog
{
public:
CAboutDlg();
// Dialog Data
//{{AFX_DATA(CAboutDlg)
enum { IDD = IDD_ABOUTBOX };
//}}AFX_DATA
// ClassWizard generated virtual function overrides
//{{AFX_VIRTUAL(CAboutDlg)
protected:
virtual void DoDataExchange(CDataExchange* pDX); // DDX/DDV support
//}}AFX_VIRTUAL
// Implementation
protected:
//{{AFX_MSG(CAboutDlg)
//}}AFX_MSG
DECLARE_MESSAGE_MAP()
};
CAboutDlg::CAboutDlg() : CDialog(CAboutDlg::IDD)
{
//{{AFX_DATA_INIT(CAboutDlg)
//}}AFX_DATA_INIT
}
void CAboutDlg::DoDataExchange(CDataExchange* pDX)
{
CDialog::DoDataExchange(pDX);
//{{AFX_DATA_MAP(CAboutDlg)
//}}AFX_DATA_MAP
}
BEGIN_MESSAGE_MAP(CAboutDlg, CDialog)
//{{AFX_MSG_MAP(CAboutDlg)
// No message handlers
//}}AFX_MSG_MAP
END_MESSAGE_MAP()
/////////////////////////////////////////////////////////////////////////////
// CFvasDlg dialog
CFvasDlg::CFvasDlg(CWnd* pParent /*=NULL*/)
: CDialog(CFvasDlg::IDD, pParent)
{
//{{AFX_DATA_INIT(CFvasDlg)
// NOTE: the ClassWizard will add member initialization here
//}}AFX_DATA_INIT
// Note that LoadIcon does not require a subsequent DestroyIcon in Win32
m_hIcon = AfxGetApp()->LoadIcon(IDR_MAINFRAME);
}
void CFvasDlg::DoDataExchange(CDataExchange* pDX)
{
CDialog::DoDataExchange(pDX);
//{{AFX_DATA_MAP(CFvasDlg)
// NOTE: the ClassWizard will add DDX and DDV calls here
//}}AFX_DATA_MAP
}
BEGIN_MESSAGE_MAP(CFvasDlg, CDialog)
//{{AFX_MSG_MAP(CFvasDlg)
ON_WM_SYSCOMMAND()
ON_WM_PAINT()
ON_WM_QUERYDRAGICON()
ON_BN_CLICKED(IDC_BUTTON1_DISPLAY, OnDisplay)
ON_BN_CLICKED(IDC_STATIC_BITMAP, OnStaticBitmap)
//}}AFX_MSG_MAP
END_MESSAGE_MAP()
/////////////////////////////////////////////////////////////////////////////
// CFvasDlg message handlers
BOOL CFvasDlg::OnInitDialog()
{
CDialog::OnInitDialog();
// Add "About..." menu item to system menu.
// IDM_ABOUTBOX must be in the system command range.
ASSERT((IDM_ABOUTBOX & 0xFFF0) == IDM_ABOUTBOX);
ASSERT(IDM_ABOUTBOX < 0xF000);
CMenu* pSysMenu = GetSystemMenu(FALSE);
if (pSysMenu != NULL)
{
CString strAboutMenu;
strAboutMenu.LoadString(IDS_ABOUTBOX);
if (!strAboutMenu.IsEmpty())
{
pSysMenu->AppendMenu(MF_SEPARATOR);
pSysMenu->AppendMenu(MF_STRING, IDM_ABOUTBOX, strAboutMenu);
}
}
// Set the icon for this dialog. The framework does this automatically
// when the application's main window is not a dialog
SetIcon(m_hIcon, TRUE); // Set big icon
SetIcon(m_hIcon, FALSE); // Set small icon
// TODO: Add extra initialization here
return TRUE; // return TRUE unless you set the focus to a control
}
void CFvasDlg::OnSysCommand(UINT nID, LPARAM lParam)
{
if ((nID & 0xFFF0) == IDM_ABOUTBOX)
{
CAboutDlg dlgAbout;
dlgAbout.DoModal();
}
else
{
CDialog::OnSysCommand(nID, lParam);
}
}
// If you add a minimize button to your dialog, you will need the code below
// to draw the icon. For MFC applications using the document/view model,
// this is automatically done for you by the framework.
void CFvasDlg::OnPaint()
{
if (IsIconic())
{
CPaintDC dc(this); // device context for painting
SendMessage(WM_ICONERASEBKGND, (WPARAM) dc.GetSafeHdc(), 0);
// Center icon in client rectangle
int cxIcon = GetSystemMetrics(SM_CXICON);
int cyIcon = GetSystemMetrics(SM_CYICON);
CRect rect;
GetClientRect(&rect);
int x = (rect.Width() - cxIcon + 1) / 2;
int y = (rect.Height() - cyIcon + 1) / 2;
// Draw the icon
dc.DrawIcon(x, y, m_hIcon);
}
else
{
CDialog::OnPaint();
}
}
// The system calls this to obtain the cursor to display while the user drags
// the minimized window.
HCURSOR CFvasDlg::OnQueryDragIcon()
{
return (HCURSOR) m_hIcon;
}
void CFvasDlg::OnDisplay()
{
// TODO: Add your control notification handler code here
static char BASED_CODE szFilter[] = "Bitmap Files (*.bmp) |*.bmp||";
CString m_sBitmap;
CFileDialog m_ldFile(TRUE, ".bmp", m_sBitmap, OFN_HIDEREADONLY | OFN_OVERWRITEPROMPT, szFilter);
if (m_ldFile.DoModal() == IDOK)
{
m_sBitmap = m_ldFile.GetPathName();
HBITMAP hBitmap = (HBITMAP) ::LoadImage(AfxGetInstanceHandle(), m_sBitmap, IMAGE_BITMAP, 100,140, LR_LOADFROMFILE | LR_CREATEDIBSECTION);
HBITMAP hGrayBitmap = (HBITMAP) ::LoadImage(AfxGetInstanceHandle(), m_sBitmap, IMAGE_BITMAP, 100,140, LR_LOADFROMFILE | LR_CREATEDIBSECTION);
HBITMAP hGrayBitmap1 = (HBITMAP) ::LoadImage(AfxGetInstanceHandle(), m_sBitmap, IMAGE_BITMAP, 100,140, LR_LOADFROMFILE | LR_CREATEDIBSECTION);
BITMAP bm;
BITMAP bm1;
GetObject(hGrayBitmap, sizeof(BITMAP), (LPSTR)&bm);
typedef struct tagBITMAP
{
LONG bmType;
LONG bmWidth;
LONG bmHeight;
LONG bmWidthBytes;
WORD bmPlanes;
WORD bmBitsPixel;
LPVOID bmBits;
}
BITMAP, *PBITMAP;
if (hGrayBitmap)
{
CStatic *pImgPicture = (CStatic*)GetDlgItem(IDC_STATIC_BITMAP);
BYTE * pImgByte = (BYTE *) bm.bmBits;
if(pImgPicture==NULL)
{
AfxMessageBox("Fail to get Picture Control");
}
else
{
INT iWidthBytes = bm.bmWidth * 3;
for ( int y = 0; y < bm.bmHeight; y++)
{
for ( int x = 0; x < bm.bmWidth*3; x++)
{
unsigned char R = pImgByte[y*iWidthBytes+x+2];
unsigned char G = pImgByte[y*iWidthBytes+x+1];
unsigned char B = pImgByte[y*iWidthBytes+x];;
INT gray = ceil(0.3*R + 0.59*G + 0.11*B);
pImgByte[y*iWidthBytes+x+2] = gray;
pImgByte[y*iWidthBytes+x+1] = gray;
pImgByte[y*iWidthBytes+x] = gray;
}
}
void threshold (struct Image *bm, struct Image *bm1, int THRES)
{
int X, Y, GO, GB;
GO= 225;
GB= 0;
for (Y=0; Y<=bm.bmHeight; Y++)
{
for (X=0; X<=bm.bmWidth*3; X++)
{
if (*(bm.bmBitsPixel + X + (long) Y * bm.bmWidth*3) > THRES)
*(bm1.bmBitsPixel + X + (long) Y * bm.bmWidth*3) = GO;
else
*(bm1.bmBitsPixel + X + (long) Y * bm.bmWidth*3) = GB;
}
}
}
pImgPicture->SetBitmap(hGrayBitmap);
}
}
}
}
|
|
|
|
|
It would help, and you'd get a lot more responses, if you'd trim your code down to just the pieces necessary to reproduce the problem.
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
|
|
|
|
|
/agree
I didn't feel like figuring it all out, but a suggestion would be to block comment out every method in the file except one. Then compile. If you get no errors, uncomment another function and recompile. Continue until you can at least figure out which particular function is causing the problem. Then try repeating the process with individual lines within the offending function.
Bob Ciora
|
|
|
|
|
This is definitely puzzling:
BITMAP bm;
BITMAP bm1;
GetObject(hGrayBitmap, sizeof(BITMAP), (LPSTR)&bm);
typedef struct tagBITMAP
{
LONG bmType;
LONG bmWidth;
LONG bmHeight;
LONG bmWidthBytes;
WORD bmPlanes;
WORD bmBitsPixel;
LPVOID bmBits;
}
BITMAP, *PBITMAP;
Defining variables of your type BITMAP before you've actually defined the structure?
Bob Ciora
|
|
|
|
|
bm and bm1 are instances of BITMAP that is defined in wingdi.h .
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
|
|
|
|
|
Point taken But I'm still curious why this declaration is here.
Bob Ciora
|
|
|
|
|
Bob Ciora wrote:
But I'm still curious why this declaration is here.
Agreed. It serves no logical purpose.
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
|
|
|
|
|
Somebody correct me if I'm wrong, but AFAIK, you can't define a structure within a method. Take out the BITMAP structure definition and it should get rid of the compilation error.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
I need to check if a folder exists. I have a specific path and will perform a certain action only if that path exists. How can I check to see if a specific folder (ie. "c:\Program Files\Debug") exists.
I have already tried using the WIN32 API call GetFileAttributes. I was checking to see if there was an error or not to see if the folder exists. The call returns an error regardless. The path is a BSTR, casted to char*, casted to LPCTSTR, if this is a problem.
|
|
|
|
|
ChemmieBro wrote:
I need to check if a folder exists.
See here and here.
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
|
|
|
|
|