Re: Getting ASSERT on one machine but NOT the other

Tech-Archive recommends: Fix windows errors by optimizing your registry

Since there isn't a lot of information about what failed, where, and for what reason, it
is hard to guess. The only information you gave was a single assert line, with no
accompanying useful information. You did not give the ACTUAL value of the variables
involved, so there's no way to tell what happened. You gave no backtrace, nor any
information about what classes might have been involved. The original bug report is only
an infinitesimal improvement over the "My program failed, what did I do wrong?" question.
joe
On Wed, 17 Dec 2008 14:00:04 -0800, Jimbo_Jimbob_Jiminator
<JimboJimbobJiminator@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

Hi Joe,
In this case, I never really run Create on any of the dll's. or make any
calls to them. There are 4 member variables of type CChartViewer (Chart
Director class) on property page 2 (of 0-3) but I never use them. I just
assumed that the when the property page is destroyed these will be handled
intrinsically, like other class and variable types.

Should those classes need special handling when PrimaryDlg::OnClose() occurs?

Jim

"Joseph M. Newcomer" wrote:

The presence of a major control like Chart Directory is a pretty high probability for the
source of the problem.

Make sure that your code checks for the existence of this. A typical scenario goes
something like

OnInitDialog:
thing.Create();

where in fact there is no guarantee that thing.Create ever worked, but that doesn't stop
later code from expecting that thing is a valid window.

So make sure your code both checks the return results and does not attempt to use objects
that might not exist, for example, places that expect to use thing might say
if(thing.GetSafeHwnd() != NULL)
joe

On Wed, 17 Dec 2008 11:08:02 -0800, Jimbo_Jimbob_Jiminator
<JimboJimbobJiminator@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

I realize that something is leading to different results on the machine. I am
not sure how to go about debugging this one particularly.

My first thought was to present it just as I did to see if there was some
common problem or configuration that more experienced people knew about.

Similar to saying, my fuel injected car doesn't come off high idle after it
warms up. Without delving into a lot of other stuff I can tell you that one
thing to check the idle air control valve. This is common problem and a
possibility regardless of make, number of cylinders, transmission type, etc.
If it's not that common problem then we are in for some digging and debugging.

As was mentioned, the possibility that a dll is not registered as a
possibility.

The program is a small program structured as follows:
Dialog bases app.
App creates primary dialog (done by VS2005)
Primary dialog creates Property ***
Property *** creates 4 property pages

The primary dialog uses a dll to communicate with an embedded device over
10bT. Property page 2 (of 0 - 3) creates 4 charts using Chart Director via
dll. This same property page creates a pdf file using LitePDF via dll.

I don't really know much about dll's. I just follow the instructions and
they worked.

I don't believe Chart Director is registered. I just unzipped it to a
directory. Here are the instructions from the help file:
The CChartViewer MFC Control

All ChartDirector MFC sample programs uses the CChartViewer control to display
charts and handle mouse interactions. The CChartViewer is a derived class of
the
MFC CStatic control. It is released in source code format in the MFC sample
programs.

To use CChartViewer in your own project:
For VC++ 6.0, the steps to do this are: Select "Project/Settings" from the
menu
bar, click on the "C/C++" tab, in the "Category" list box, select
"Preprocessor", then in the "Additional include directories" field, add the
path
for the "ChartDirector\include" subdirectory.

For Visual Studio.NET, the steps to do this are: Select "Project/Properties"
from the menu bar, go to "C/C++" -> "General", in the "Additional Include
Directories" field, add the path for the "ChartDirector\include" subdirectory.

For VC++ 6.0, the steps to do this are: Select "Project/Settings" from the
menu
bar, click on the "Link" tab, in the "Object/library modules" field, add the
path for the file "chartdir41.lib".

For Visual Studio.NET, the steps to do this are: Select "Project/Properties"
from the menu bar, go to "Linker" -> "Input", in the "Additional Dependencies"
field, add the path for the file "chartdir41.lib".

- Include "ChartViewer.h" and "ChartViewer.cpp" in your project.

- Use the VC++ Dialog Editor to put a CStatic (Picture) control for displaying
bitmaps in your Form or Dialog. Set a valid resource ID for the control.

- Add a member variable for the control (eg. right click on the control and
select
"Add variable" or "ClassWizard", depending on your version of VC++)

- Edit the header file of the Form or Dialog to change the member variable
type
from CStatic to CChartViewer, and to add the following line:

- #include "ChartViewer.h"


- To display a chart using the CChartViewer, only one line of code is needed:
//ChartViewer1 is a CChartViewer control, c is a BaseChart pointer
ChartViewer1->setChart(c);

The comm SDK came with an installation. I don't really know if registered
the dll or how to verify that. I did have to include the Comm.h file and .lib
file to the linker dependencies.

The LitePDF dll had me add this statement to the bottom of stdafx.h:
//import the LitePDF type library
#import "progid:LitePDF.PDFDocument" no_namespace

I set a breakpoint at OnClose in the primary dialog class and started
stepping in. When I get to:
LRESULT CWnd::DefWindowProc(UINT nMsg, WPARAM wParam, LPARAM lParam)
{
if (m_pfnSuper != NULL)
return ::CallWindowProc(m_pfnSuper, m_hWnd, nMsg, wParam, lParam);

it makes that Windows error sound via the speaker (like a bonk). It never
really shows an ASSERT message though. If I run in real time, it "bonks" and
I get the ASSERT. Actually, the first time I run it in the debugger at real
time, it "bonks" but doesn't show the ASSERT message. Subsequent runs will do
both.

This occurs even if I comment out the comm calls. I am not sure if this
means the dll doesn't load or not. Also, while the calls for the charts and
pdf creation still exist, the ASSERT occurs even if they are never called. I
have those connected to an OnOK button event. I just don't click that button.

I hope this makes the scenario clearer.

Jim




"Jonathan Wood" wrote:

"Jimbo_Jimbob_Jiminator" <JimboJimbobJiminator@xxxxxxxxxxxxxxxxxxxxxxxxx>
wrote in message news:6E728970-796A-4937-B0AB-055814769C3A@xxxxxxxxxxxxxxxx

I have VS2k5 (MFC, C++) installed on two computers. I have a project
checked
into version control (StarTeam). I checked it out and compiled it in
"debug
build" on two PC's. On one PC it exits just fine when I click the 'X' on
the
banner bar.

However, on the other PC, I am getting an ASSERT in:
BOOL PASCAL CWnd::WalkPreTranslateTree(HWND hWndStop, MSG* pMsg)

at:
ASSERT(hWndStop == NULL || ::IsWindow(hWndStop));

Any idea why it behaves differently on two machines?

Yes, because something is leading to different results on one of the
machines.

Of course, no one can tell you what that is based on the information you've
provided.

Might I suggest you use the debugger?

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com


Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

Quantcast