|
marwa_fci wrote: - what do you mean by Excell automation and how?
- CSpreadSheet creates an excel file, but i want to create a sheet or a table inside the window of my application, so it is not the solution.
Dont worry about that, sounds like you need a grid, see the post from Max http://www.codeproject.com/script/comments/forums.asp?msg=1691852&forumid=1647#xx1691852xx[^] the grid from Chris M has lots of features and will do just what you need.
I'd love to help, but unfortunatley I have prior commitments monitoring the length of my grass. :Andrew Bleakley:
|
|
|
|
|
You can reply to answers if they arent your answer
|
|
|
|
|
This is really starting to bug me.
I have created a VC8 MFC app that I am now trying to get to run on a W2K SP4 machine. This app runs with no problems on my XP SP2 machine that has VS2005 installed on it.
I have turned off all optimizations, added all the debug info, and generated .map and .pdb files for the app.
I use DrWatson (drwtsn32.exe v5.0.2195.6699) to generate a .log and .dmp file on the W2K machine when the crash occurs. I transfered those two files back to my dev machine.
I have narrowed the error down to this:
CMyApp::InitInstance()
{
<snip>
CMainFrame *pMainFrame = new CMainFrame;
if (!pMainFrame)
{
AfxMessageBox(_T("Mainframe c'tor failed"));
return FALSE;
}
if (!pMainFrame->LoadFrame(IDR_MAINFRAME))
{
AfxMessageBox(_T("LoadFrame failed"));
delete pMainFrame;
return FALSE;
}
I have absolutely no idea why the LoadFrame call fails, nor why deleting the pMainFrame pointer causes the app to crash. When I try to open the dump file in VS2005 I get an error "Debugging older format crashdumps is not supported."
Here is part of the DrWatson log file in case anybody sees something I may be missing:
State Dump for Thread Id 0x3b8
eax=00778f00 ebx=ffffffff ecx=00778f00 edx=00000000 esi=00433a68 edi=00433a68
eip=00423f8e esp=0012fe70 ebp=0012ff1c iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000206
function: <nosymbols>
00423f72 8b4df0 mov ecx,[ebp+0xf0] ss:00ba9e02=????????
00423f75 894d88 mov [ebp+0x88],ecx ss:00ba9e02=????????
00423f78 8b5588 mov edx,[ebp+0x88] ss:00ba9e02=????????
00423f7b 89558c mov [ebp+0x8c],edx ss:00ba9e02=????????
00423f7e 837d8c00 cmp dword ptr [ebp+0x8c],0x0 ss:00ba9e02=????????
00423f82 7417 jz 0042a99b
00423f84 6a01 push 0x1
00423f86 8b458c mov eax,[ebp+0x8c] ss:00ba9e02=????????
00423f89 8b10 mov edx,[eax] ds:00778f00=00000000
00423f8b 8b4d8c mov ecx,[ebp+0x8c] ss:00ba9e02=????????
FAULT ->00423f8e 8b4204 mov eax,[edx+0x4] ds:00a79ee6=????????
00423f91 ffd0 call eax
00423f93 898560ffffff mov [ebp+0xffffff60],eax ss:0012fe7c=00000040
00423f99 eb0a jmp 004306a5
00423f9b c78560ffffff00000000 ss:0012fe7c=00000040
mov dword ptr [ebp+0xffffff60],0x0
00423fa5 6a00 push 0x0
00423fa7 6a00 push 0x0
00423fa9 686caa4200 push 0x42aa6c
00423fae e84fcefeff call 00410e02
00423fb3 c7458400000000 mov dword ptr [ebp+0x84],0x0 ss:00ba9e02=????????
00423fba c745fcffffffff ss:00ba9e02=????????
mov dword ptr [ebp+0xfc],0xffffffff
00423fc1 8d4dbc lea ecx,[ebp+0xbc] ss:00ba9e02=????????
*----> Stack Back Trace <----*
FramePtr ReturnAd Param#1 Param#2 Param#3 Param#4 Function Name
0012FF1C 7831C3A7 00433BB4 00000001 00000000 00411561 !<nosymbols>
0012FFC0 7C4E87F5 006D0049 00670061 7FFDF000 C0000005 !<nosymbols>
0012FFF0 00000000 004116D1 00000000 000000C8 00000100 kernel32!DosDateTimeToFileTime
*----> Raw Stack Dump <----*
0012fe70 01 00 00 00 f5 ca 3c 8c - c8 fe 12 00 40 00 00 00 ......<.....@...
0012fe80 00 8f 77 00 80 8d 77 00 - 68 3a 43 00 76 00 00 00 ..w...w.h:C.v...
0012fe90 b0 ff 12 00 8e 13 2e 7c - a0 20 2d 7c ff ff ff ff .......|. -|....
0012fea0 d4 fe 12 00 00 8f 77 00 - 00 8f 77 00 c8 fe 12 00 ......w...w.....
0012feb0 00 8f 77 00 00 8f 77 00 - 08 ff 12 00 80 8d 77 00 ..w...w.......w.
0012fec0 80 8d 77 00 5c 6e 3c 78 - 76 00 78 00 e8 21 2f 78 ..w.\n<xv.x..!>
0012fed0 00 00 00 00 0c ff 12 00 - 18 27 2f 78 01 00 00 00 .........'/x....
0012fee0 00 00 00 00 00 00 00 00 - 00 00 00 00 e0 5c 3c 78 .............\<x>
0012fef0 e0 5c 3c 78 e0 5c 3c 78 - e0 5c 3c 78 00 00 00 00 .\<x.\><x.\><x....>
0012ff00 08 00 00 00 ff 00 00 00 - 80 8d 77 00 00 8f 77 00 ..........w...w.
0012ff10 b0 ff 12 00 a9 80 42 00 - 00 00 00 00 c0 ff 12 00 ......B.........
0012ff20 a7 c3 31 78 b4 3b 43 00 - 01 00 00 00 00 00 00 00 ..1x.;C.........
0012ff30 61 15 41 00 00 00 40 00 - 00 00 00 00 64 08 02 00 a.A...@.....d...
0012ff40 01 00 00 00 29 ca 3c 8c - 49 00 6d 00 61 00 67 00 ....).<.I.m.a.g.
0012ff50 00 f0 fd 7f 44 00 00 00 - 00 09 02 00 e0 08 02 00 ....D...........
0012ff60 68 08 02 00 00 00 00 00 - 00 00 00 00 00 00 00 00 h...............
0012ff70 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
0012ff80 01 04 00 00 01 00 00 00 - 00 00 00 00 00 00 00 00 ................
0012ff90 01 00 01 00 00 00 00 00 - 05 00 00 c0 64 08 02 00 ............d...
0012ffa0 00 00 00 00 00 00 00 00 - 44 ff 12 00 a4 fa 12 00 ........D.......
*----> Symbol Table <----*
</x....></x.\></x.\></x></xv.x..!></nosymbols></nosymbols></nosymbols>
You may be right
I may be crazy
-- Billy Joel --
Within you lies the power for good - Use it!
|
|
|
|
|
What's the value of IDR_MAINFRAME?
I don't think it's crashing where you think it is.... it doesn't look like delete.
<br />
00423f84 6a01 push 0x1<br />
00423f86 8b458c mov eax,[ebp+0x8c] ss:00ba9e02=????????<br />
00423f89 8b10 mov edx,[eax] ds:00778f00=00000000<br />
00423f8b 8b4d8c mov ecx,[ebp+0x8c] ss:00ba9e02=????????<br />
FAULT ->00423f8e 8b4204 mov eax,[edx+0x4] ds:00a79ee6=????????<br />
00423f91 ffd0 call eax<br />
00423f93 898560ffffff mov [ebp+0xffffff60],eax ss:0012fe7c=00000040<br />
00423f99 eb0a jmp 004306a5<br />
It's calling something out of a table. Loads eax with an address of a function (likely from a vtable) and then calls it. The only thing on the stack is a "1".
Just a guess, but the call to LoadFrame would be my guess.
But I am pretty sure it's not the delete statement.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br />
Peter Weyzen<br />
Staff Engineer<br />
<A HREF="http://www.soonr.com">SoonR Inc.</A>
|
|
|
|
|
This is the view from the disassembly window when running the app in VS2005 on my XP machine:
{
AfxMessageBox(_T("LoadFrame failed"));
00423F04 push 0
00423F06 push 0
00423F08 push 42A950h
00423F0D call AfxMessageBox (410E02h)
delete pMainFrame;
00423F12 mov ecx,dword ptr [ebp-10h]
00423F15 mov dword ptr [ebp-78h],ecx
00423F18 mov edx,dword ptr [ebp-78h]
00423F1B mov dword ptr [ebp-74h],edx
00423F1E cmp dword ptr [ebp-74h],0
00423F22 je CMyApp::InitInstance+2CBh (423F3Bh)
00423F24 push 1
00423F26 mov eax,dword ptr [ebp-74h]
00423F29 mov edx,dword ptr [eax]
00423F2B mov ecx,dword ptr [ebp-74h]
00423F2E mov eax,dword ptr [edx+4]
00423F31 call eax
00423F33 mov dword ptr [ebp-0A0h],eax
00423F39 jmp CMyApp::InitInstance+2D5h (423F45h)
00423F3B mov dword ptr [ebp-0A0h],0
return FALSE;
00423F45 mov dword ptr [ebp-7Ch],0
00423F4C mov dword ptr [ebp-4],0FFFFFFFFh
00423F53 lea ecx,[ebp-44h]
00423F56 call CCommandLineInfo::~CCommandLineInfo (410DD8h)
00423F5B mov eax,dword ptr [ebp-7Ch]
00423F5E jmp 0042409A
}
m_pMainWnd = pMainFrame;
00423F63 mov ecx,dword ptr [ebp-94h]
00423F69 mov edx,dword ptr [ebp-10h]
00423F6C mov dword ptr [ecx+20h],edx And this is the DrWatson log from the same exe file but run on W2K
State Dump for Thread Id 0x3b8
eax=00778f00 ebx=ffffffff ecx=00778f00 edx=00000000 esi=00433a68 edi=00433a68
eip=00423f8e esp=0012fe70 ebp=0012ff1c iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000206
function: <nosymbols>
00423f72 8b4df0 mov ecx,[ebp+0xf0] ss:00ba9e02=????????
00423f75 894d88 mov [ebp+0x88],ecx ss:00ba9e02=????????
00423f78 8b5588 mov edx,[ebp+0x88] ss:00ba9e02=????????
00423f7b 89558c mov [ebp+0x8c],edx ss:00ba9e02=????????
00423f7e 837d8c00 cmp dword ptr [ebp+0x8c],0x0 ss:00ba9e02=????????
00423f82 7417 jz 0042a99b
00423f84 6a01 push 0x1
00423f86 8b458c mov eax,[ebp+0x8c] ss:00ba9e02=????????
00423f89 8b10 mov edx,[eax] ds:00778f00=00000000
00423f8b 8b4d8c mov ecx,[ebp+0x8c] ss:00ba9e02=????????
FAULT ->00423f8e 8b4204 mov eax,[edx+0x4] ds:00a79ee6=????????
00423f91 ffd0 call eax
00423f93 898560ffffff mov [ebp+0xffffff60],eax ss:0012fe7c=00000040
00423f99 eb0a jmp 004306a5
00423f9b c78560ffffff00000000 ss:0012fe7c=00000040
mov dword ptr [ebp+0xffffff60],0x0
00423fa5 6a00 push 0x0
00423fa7 6a00 push 0x0
00423fa9 686caa4200 push 0x42aa6c
00423fae e84fcefeff call 00410e02
00423fb3 c7458400000000 mov dword ptr [ebp+0x84],0x0 ss:00ba9e02=????????
00423fba c745fcffffffff ss:00ba9e02=????????
mov dword ptr [ebp+0xfc],0xffffffff
00423fc1 8d4dbc lea ecx,[ebp+0xbc] ss:00ba9e02=????????
*----> Stack Back Trace <----*Now I do not know why the addresses are different (off by 0x60 bytes)
Why the instruction just before the push 1 is different - VS debugger has it as jz, DrWatson has it as je
Why the pointers are different? mov ecx,dword ptr [ebp-10h] as opposed to mov ecx,[ebp+0xf0]
Is the copy of DrWatson on the W2K machine all screwed up?
If I look for the instruction addresses reported by DrWatson in VS I can not find them.
I assumed that the app was crashing in delete because it crashed immediately after I got the message box and DrWatson reported the fault to be in the code that matches up (almost) with the code the VS shows for the delete function.
Why would the app run flawlessly on XP but crash so badly on W2K? I think what I really need is some clear instructions on how to setup VS2005 to do remote debugging. Anything I have tried from reading MSDN on the subject has failed with VS giving me cryptic error messages.
|
|
|
|
|
JE and JZ are synonymous - both jump if the zero flag is set. cmp eax, 15 checks if eax==15. But what it really does is subtract 15 from eax and set the flags appropriately. Thus if they are equal, the zero-flag will be set.
As for the different pointers - the instructions in question have a sign-extended MOD/RM operand. Dr.Watson is for some reason treating the offset as an unsigned char rather than the signed char it really is.
I still don't know why the load addresses are different. You're not doing anything funky with EXE alignment, are you?
It looks to me like memory corruption. It is failing while trying to load the address of the virtual destructor of the pMainFrame object. Somehow the vtbl pointer has been zeroed out. Are you by any chance doing a memset to clear a bunch of class variables? I've seen that many times.
But as to why this fails on only W2K, I have no idea at the moment. What kind of stuff does the app use? (i.e. any os components that could be different on 2k/xp?)
That doesn't really help much, now, does it But it's about all I can think of now.
Mike
|
|
|
|
|
Mike_V wrote: What kind of stuff does the app use? (i.e. any os components that could be different on 2k/xp?)
BINGO !!!!
I was using the CS_DROPSHADOW style on a floating tool window. Removed that style and everything worked.
Thanks much for the hint. You get my 5 for that
|
|
|
|
|
Cool! 
I guess I've been reading Raymond Chen's blog enough that some of his "psychic powers" have rubbed off on me! 
But seriously - glad to be of help. Though I still don't get why that caused the problem we were seeing. But at this point it's probably better not to ask.
Mike
|
|
|
|
|
Mike_V wrote: Though I still don't get why that caused the problem we were seeing. But at this point it's probably better not to ask.
This code was called from CMainFrame::OnCreate()
BOOL CToolWnd::Create(CWnd *pParent)
{
return CreateEx(WS_EX_TOOLWINDOW | WS_EX_TOPMOST,
AfxRegisterClass(CS_DROPSHADOW | CS_SAVEBITS,
NULL, NULL, NULL),
...);
}I would have thought that the the create function would simply fail to create a window, not crash the entire app. It certainly would have been easier to debug . I have now added code to check the OS and remove the CS_DROPSHADOW style if running on W2K.
Maybe a guy should not ask why, but I would really like to know if anybody has any idea
|
|
|
|
|
Looks like CS_DROPSHADOW, flag isnt defined in W2k, SystemParametersInfo[^]
MSDN wrote: SPI_SETDROPSHADOW Enables or disables the drop shadow effect. Set pvParam to TRUE to enable the drop shadow effect or FALSE to disable it. You must also have CS_DROPSHADOW in the window class style.
Windows 2000: This value is not supported until Windows XP.
PJ Arends wrote: not crash the entire app. It certainly would have been easier to debug
It's more fun when seemingly simple stuff crashes everything.  Would you have looked at a memory dump other wise?
I of coarse just like you would have expected it to just fail at the undefined feature.
I'd love to help, but unfortunatley I have prior commitments monitoring the length of my grass. :Andrew Bleakley:
|
|
|
|
|
Peter Weyzen wrote: What's the value of IDR_MAINFRAME?
128, the standard MFC value.
Sorry I forgot to add that earlier.
|
|
|
|
|
I have a series of pages in a wizard; when I press the "next" button to go to the next page, I can validate the current page values in the OnWizardNext and return -1 to stay on the same page if there are some bad values on the page.
but, when I'm at the last page, there's the "Finish" button, and will generate an OnWizardFinish but if there are invalide values on the last page, there is no way (*) of preventing the wizard to finish ( stay on the current page )
(*) I'm certain that there is a way to do it, that's why I'm asking, I think I could disable the "Finish" button and enable it if all my values are valid.
Thanks.
Max.
|
|
|
|
|
What happens if you return FALSE from OnWizardFinish()? The docs say it prevents the property sheet from being destroyed, but is that the same as leaving the page open and usable?
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
I am using VS.NET 2003. I have placed a DateTimePicker and am using time. When I click on the HH field, I can not click (using mouse)on the SS field. I have to exit the dialog then come back in. I realize I can use the keyboard left and right arrows but can I use the mouse to click on the fields after the first is selection.
|
|
|
|
|
how to get column count of CListCtrl?
or by any win32 function?
thx
|
|
|
|
|
See
<br />
CHeaderCtrl* m_Header=(CHeaderCtrl*)m_List1.GetDlgItem(0); <br />
int nCount = m_Header->GetItemCount(); <br />
|
|
|
|
|
WhiteSky wrote: CHeaderCtrl* m_Header=(CHeaderCtrl*)m_List1.GetDlgItem(0);
int nCount = m_Header->GetItemCount();
Or a slightly more readable way:
CHeaderCtrl* pHeader = m_List.GetHeaderCtrl();
int Count = pHeader->GetItemCount();
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
yes,
|
|
|
|
|
Sir,
I want to make the setup of my application in vc++6.0.please help.
Thanks
|
|
|
|
|
|
The Professional version of VC6 came with an optional package for creating InstallShield installation exe's. It will integrate with the IDE and is fairly simple to use for most applications.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
|
When running my programs in debug mode (not in the debugger) is it possible to ouput strings to the debug window still? Or any other similar function? OutputDebugString() only seems to work when stepping through the code.
|
|
|
|
|
You have to use F5, not Ctrl+F5, to see output from OutputDebugString().
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
I already know that, as stated in my origional question. I am looking for a similar feature which will do the same job without stepping through the code (Ctrl+F5).
I'm thinking a quick way to do this would be to create a new console window and send the strings to that as opposed to the debugger.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
