C / C++ / MFC

Le centriste23-Jan-02 8:58

Le centriste

23-Jan-02 8:58

Can you pinpoint the line on which the crash occurs? If not, do you get an assertion dialog box when running your program in the Debug build?

User 665823-Jan-02 9:38

23-Jan-02 9:38

I don't get a debug assertion window.

I both debug and release build the typical "crash-windows" appears, when an app crashes.
But there's one more thing that's definately not normal:

BOOL CScriptEditorApp::InitInstance()
{
	// Standardinitialisierung
	// Wenn Sie diese Funktionen nicht nutzen und die Größe Ihrer fertigen 
	//  ausführbaren Datei reduzieren wollen, sollten Sie die nachfolgenden
	//  spezifischen Initialisierungsroutinen, die Sie nicht benötigen, entfernen.

#ifdef _AFXDLL
	Enable3dControls();			// Diese Funktion bei Verwendung von MFC in gemeinsam genutzten DLLs aufrufen
#else
	Enable3dControlsStatic();	// Diese Funktion bei statischen MFC-Anbindungen aufrufen
#endif

	CScriptEditorDlg dlg;
	m_pMainWnd = &dlg;
	int nResponse = dlg.DoModal();
	if (nResponse == IDOK)
	{
		// ZU ERLEDIGEN: Fügen Sie hier Code ein, um ein Schließen des
		//  Dialogfelds über OK zu steuern
	}
	else if (nResponse == IDCANCEL)
	{
		// ZU ERLEDIGEN: Fügen Sie hier Code ein, um ein Schließen des
		//  Dialogfelds über "Abbrechen" zu steuern
	}

	// Da das Dialogfeld geschlossen wurde, FALSE zurückliefern, so dass wir die
	//  Anwendung verlassen, anstatt das Nachrichtensystem der Anwendung zu starten.
	return FALSE;
}

I ran this in debug mode with a breakpoint in line "CScriptEditorDlg dlg;"
Then I went on with program execution.
The strange thing is, that the cursor jumps from line

int nResponse = dlg.DoModal();

directly to

return FALSE;

and thus the dialog box never appears Confused | :confused:

modified 12-Sep-18 21:01pm.

Joaquín M López Muñoz23-Jan-02 10:04

Joaquín M López Muñoz

23-Jan-02 10:04

Try deleting the Debug and Release directories as well as the .pch (precompiled header) files, then try rebuilding all. Sometimes this makes wonders.

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo

User 665823-Jan-02 10:11

23-Jan-02 10:11

Joaquín M López Muñoz wrote:
Sometimes this makes wonders

Not im my case Cry | :((

This drives me crazy Cry | :((

modified 12-Sep-18 21:01pm.

Ravi Bhavnani23-Jan-02 10:16

Ravi Bhavnani

23-Jan-02 10:16

Put a breakpoint in your dialog's OnInitDialog. You may be referencing a bad CWnd. In any case, the stepping thru OnInitDialog() should reveal the problem. Do a clean rebuild before you do this. This will fix any resource id errors that may have crept in.

/ravi

"There is always one more bug..."
ravib@ravib.com
http://www.ravib.com

User 665823-Jan-02 10:41

23-Jan-02 10:41

OnInitDialog doesn't get called..the app crashes earlier on startup, I just checked it once more Frown | :(

modified 12-Sep-18 21:01pm.

Le centriste23-Jan-02 10:57

Le centriste

23-Jan-02 10:57

Make sure you don't try to intialize any control within the Dlg class constructor. Maybe that is your problem.

User 665823-Jan-02 11:00

23-Jan-02 11:00

Is this what you mean?

CScriptEditorDlg::CScriptEditorDlg(CWnd* pParent /*=NULL*/)
	: CDialog(CScriptEditorDlg::IDD, pParent)
{
	//{{AFX_DATA_INIT(CScriptEditorDlg)
	m_pToolTip = NULL;
	//}}AFX_DATA_INIT
	// Beachten Sie, dass LoadIcon unter Win32 keinen nachfolgenden DestroyIcon-Aufruf benötigt
	m_hIcon = AfxGetApp()->LoadIcon(IDR_MAINFRAME);
}

modified 12-Sep-18 21:01pm.

PROBLEM SOLVED!!!

User 665823-Jan-02 11:06

Problem with WM_NOTIFY from a ClistViewCtrl

23-Jan-02 11:06

OK,

I finally found the (very studpid) reason for the crash:

A menu was assinged to the dialog template, but for some reason I deleted the menu resource by accident

Kinda good feeling that my app runs correct now Smile | :)

modified 12-Sep-18 21:01pm.

uo200023-Jan-02 7:29

uo2000

23-Jan-02 7:29

I have an application that handles the LVN_GETDISPINFO notification from a view ClistViewCtrl. The listview contents is in an array so I just call m_view.SetItemCountEx( m_Count, 0 ); to tell the listview how many rows I have and then handle all the icons and text when the listview sends a LVN_GETDISPINFO notification.

I wanted to go further and also store the state information in my array as well so the LVN_SETDISPINFO would be a great help there.
When I add the LVN_SETDISPINFO and LVN_ODSTATECHANGED notifications they never come up in the message map of the mainfram window. Is there anyone that knows why this is or have any tips on how to get information on how it should be done to make it work?
All input will be very appreciated.

I put some trace code in the message map but there is nothing about either the ANSI or UNICODE notification showing up. No message comes up in Spy++ either. There is probably something missing but I can not figure out what. I have not seen a working example of the LVN_SETDISPINFO so I have no reference.

When I try m_view.SetCallbackMask( LVIS_FOCUSED ); It seams to understand this because the focus has disappeared from the list, and if I also add the LVIS_SELECTED the selections also disappears unless I set the state my self in LVN_GETDISPINFO.

I have followed this group, searched the internet and been to MSDN and read in the help for CListViewCtrl, the only thing I found was about WM_NOTIFYFORMAT that I also put in.

Below is excerpts from the source.

Thanks in advance
Ulf

In the _tWinMain:
iccx.dwSize = sizeof(iccx);
iccx.dwICC = ICC_WIN95_CLASSES;
//iccx.dwICC = ICC_COOL_CLASSES | ICC_BAR_CLASSES | ICC_LISTVIEW_CLASSES;
BOOL bRet = ::InitCommonControlsEx(&iccx);

The definition of the ClistViewCtrl as follows:
typedef CWinTraits<ws_child |="" ws_visible="" ws_clipsiblings="" ws_clipchildren="" |ws_vscroll="" lvs_report="" lvs_showselalways="" lvs_singlesel="" lvs_shareimagelists="" |lvs_ownerdata,="" ws_ex_clientedge=""> LexinUpdateTraits;

class CLexinUpdateView : public CWindowImpl<clexinupdateview, clistviewctrl,="" lexinupdatetraits="">, public CCustomDraw<clexinupdateview>
{
public:
DECLARE_WND_SUPERCLASS(NULL, ListViewCtrl::GetWndClassName())
typedef CWindowImpl<clexinupdateview, clistviewctrl=""> winbaseClass;

BEGIN_MSG_MAP(CLexinUpdateView)
MESSAGE_HANDLER(WM_CREATE, OnCreate)
NOTIFY_CODE_HANDLER(HDN_ITEMCLICKA, OnHeaderClicked)
NOTIFY_CODE_HANDLER(HDN_ITEMCLICKW, OnHeaderClicked)
//CHAIN_MSG_MAP(winbaseClass)
END_MSG_MAP()

BOOL PreTranslateMessage(MSG* pMsg)
{
pMsg;
return FALSE;
}

The definition of the mainframe is as follows:
class CMainFrame : public CFrameWindowImpl<cmainframe>,public CUpdateUI<cmainframe>, public CMessageFilter, public CIdleHandler
{
public:
DECLARE_FRAME_WND_CLASS(NULL, IDR_MAINFRAME)

typedef CFrameWindowImpl<cmainframe> winbaseClass;

virtual BOOL PreTranslateMessage(MSG* pMsg)
{
if(CFrameWindowImpl<cmainframe>::PreTranslateMessage(pMsg))
return TRUE;

return m_view.PreTranslateMessage(pMsg);

}

public:
BEGIN_MSG_MAP(CMainFrame)
MESSAGE_HANDLER(WM_CREATE, OnCreate)
MESSAGE_HANDLER(WM_CLOSE, OnClose)
MESSAGE_HANDLER(WM_NOTIFYFORMAT, OnNotifyFormat)

NOTIFY_HANDLER(IDC_LISTVIEW,LVN_SETDISPINFO,OnSetdispinfoLexinview)
NOTIFY_HANDLER(IDC_LISTVIEW,LVN_GETDISPINFO,OnGetdispinfoLexinview)
NOTIFY_HANDLER(IDC_LISTVIEW,LVN_ODSTATECHANGED,OnODStateChangedLexinview)

CHAIN_MSG_MAP(CUpdateUI<cmainframe>)
CHAIN_MSG_MAP(winbaseClass)
END_MSG_MAP()

// Message handlers
LRESULT OnCreate( UINT, WPARAM, LPARAM, BOOL& );
LRESULT OnClose( UINT, WPARAM, LPARAM, BOOL& );
LRESULT OnNotifyFormat( UINT, WPARAM, LPARAM, BOOL& );

LRESULT OnSetdispinfoLexinview(int idCtrl, LPNMHDR pnmh, BOOL& bHandled);
LRESULT OnGetdispinfoLexinview(int idCtrl, LPNMHDR pnmh, BOOL& bHandled);
LRESULT OnODStateChangedLexinview(int idCtrl, LPNMHDR pnmh, BOOL& bHandled);

The list view is initialised as follows in the mainframe OnCreate():
m_hWndClient = m_view.Create(m_hWnd, rcDefault, NULL, 0, 0, IDC_LISTVIEW);
ATLASSERT(::IsWindow(m_hWndClient));

// Style must be set for edit labels and ownerdraw
m_view.SetExtendedListViewStyle( LVS_EX_FULLROWSELECT|LVS_EX_HEADERDRAGDROP|LVS_EX_INFOTIP );

m_view.InitImageList( IDB_LIST_STATES );
//m_view.SetCallbackMask( LVIS_FOCUSED|LVIS_SELECTED );
m_view.SetCallbackMask( LVIS_FOCUSED );

whatif (ptr = malloc ( nSize ) ) == NULL

Mike Doner23-Jan-02 6:25

Mike Doner

23-Jan-02 6:25

Hey Folks,

When doing a "malloc" what causes it to return NULL?

I have a customer who is using our product and the application fails because it is unable to create a buffer. This application ( a propritary db server ), uses quite a bit of memory (maybe 20-30 meg at a time)...

As a test, I wrote a simple while loop to see what it would take for "malloc" to fail.... I made near 800 calls to malloc ( 1meg ) before I got a NULL ptr.

What are some of the limits of memory an application can use considering virutal memory/paging etc..

Is there a function call I can use to see EXACTLY how much memory a process is using? (would implement this in the code to see if MAYBE we have a leak).

Any thoughts?
Mike
doner@obtain.com

Re: whatif (ptr = malloc ( nSize ) ) == NULL

Joaquín M López Muñoz23-Jan-02 10:24

Joaquín M López Muñoz

23-Jan-02 10:24

When doing a "malloc" what causes it to return NULL?

The reason for malloc to return NULL is of course that the memory request could not be fulfilled. That can be caused by:

Having consumed so much memory that too little remains available,
requesting an exceedingly large amount of memory (nSize being too large),
the memory being too fragmented to allocate a contiguous chukn of memory the size requested, which could happen if your program does massive allocations/deallocations of chunks of various sizes and runs for a sufficiently long time.

What are some of the limits of memory an application can use considering virutal memory/paging etc..
The maximum amount of addressable virtual memory is 2GB (subtract some memory consumed by C run-time library and so). That means the maximum memory a process can ever expect to be able to allocate. When it comes to reality, the total amount available depends on the size of the swap file --your 800MB limit seems reasonable.

Is there a function call I can use to see EXACTLY how much memory a process is using? (would implement this in the code to see if MAYBE we have a leak).

GlobalMemoryStatus. Regards,

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo

Double Buffering vs. Private DC's

Mark Lenz23-Jan-02 4:56

23-Jan-02 4:56

To accomplish smooth, fast graphics that don't flicker which is better, double buffering or private DC's?

Mark Lenz

Mark Lenz23-Jan-02 7:58

23-Jan-02 7:58

I'm having a problem where it looks like I'm running out of device contexts. I have a control which looks kinda like a fuel guage. The value that the needle represents is updated about every second, so the needle must be redrawn about every second. I have about 4 or 5 of these controls in my view. When I have been displaying the view for about 3 minutes, things start to get weird. All of my fonts revert to a standard font and it starts to draw white where there was supposed to another color. This starts to affect the title bar, making it white. Sometimes it even starts to affect other applications.

Does anyone know what's happening and maybe what I could do to stop this?

I have looked everywhere, Google, MSDN, MSJ and mailing list archives, but I don't really know what's going on so I don't really know what to look for.

Thanks.

Mark Lenz

Michael Dunn23-Jan-02 8:15

Michael Dunn

23-Jan-02 8:15

I bet you're on 9x, right? That usually means you've exhausted your process's GDI resources or filled the GDI heap (which is limited to 64K on 9x, due to 16-bit limitations). Are you making new GDI objects (pens, brushes, etc.) every time you paint your control? And if so, are you deleting those objects?

--Mike--
"COM didn't solve the old version of DLL hell - it just provided us with a new and improved version of hell."
-- John Simmons, 1/22/2002
My really out-of-date homepage
Sonork - 100.10414 AcidHelm
Big fan of Alyson Hannigan.

Mark Lenz23-Jan-02 10:16

23-Jan-02 10:16

You're right, I am on Windows 98.

I have been using SaveDC() and RestoreDC(). I also declare all of my GDI objects that I will need in my OnPaint method at the beginning, so that they are all on the same scope. So, everytime the OnPaint() method is called I SaveDC() and create new GDI objects, use them, and when I'm done call RestoreDC() and the objects should be deleted when they go out of scope.

Am I doing this wrong?

Thanks.

Mark Lenz

Shog⁹23-Jan-02 15:28

Shog⁹

23-Jan-02 15:28

As Mr. Dunn mentioned above, Windows 98 is very sensitive to resource leaks. However, you can usually detect when this is happening on Windows 2000 by using the task manager. Display the processes page, use the View->Select Columns menu to display the GDI Objects column, and watch the number for your application. If there is a constant increase while it is running, then you've detected the resource leak (this is safer than running the app in Win95/Win98, since resource leaks can cause those OSs to become unstable).

Once you can quickly identify the resource leak, modify your code by commenting out lines that create and use GDI resources, one at a time. In this way you should be able to identify which resources are not being released.

The method you're describing sounds like it should be working; however, because you're relying on automatic deletion of the objects there is no easy way to verify that it is successful. Inserting temporary DeleteObject() calls before the objects go out of scope might also be a good way to narrow down the search:
VERIFY(gdiObj.DeleteObject());
If this line ASSERT()s, then you've found a problem.

And if you can reduce your problem to a few lines of code (i.e.

<br />
CPen pen(PS_SOLID, 1, RGB(0,255,0));<br />
int nSave = dc.SaveDC();<br />
dc.SelectObject(&pen);<br />
VERIFY(dc.RestoreDC(nSave));<br />
VERIFY(pen.DeleteObject());<br />

) then post it here, & someone will prolly figure it out.

farewell goodnight last one out turn out the lights

Smashing Pumpkins, Tales of a Scorched Earth

Michael Dunn23-Jan-02 19:24

Michael Dunn

23-Jan-02 19:24

So, you're still making a lot of GDI objects, since you repaint the controls often. First thing I'd suggest is to move the GDI objects so they're memeber variables of the control classes, so that you only create the objects once.
And btw, the problem doesn't appear on 2000 because NT doesn't have the 16-bit limitations that 9x does.

--Mike--
"COM didn't solve the old version of DLL hell - it just provided us with a new and improved version of hell."
-- John Simmons, 1/22/2002
My really out-of-date homepage
Sonork - 100.10414 AcidHelm
Big fan of Alyson Hannigan.

Mark Lenz23-Jan-02 11:22