|
Have you searched eBay, Amazon, and other Goggle-able sites?
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Another option is to find an old copy of MSDN. I don't remember when they stopped including it, but I think it was still there in the 2002 time frame.
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
I may have a that version --- I think it's the 16-bit version? But I'm not at home to check and see if I still have it. If you'll send me an email at "jepark@yahoo.com" to remind me, I'll check to see if I still have my CD and let you know.
John P.
|
|
|
|
|
The obvious question no one seems to have asked is: why do you want such an old version?
Steve
|
|
|
|
|
I didn't think twice about him using that version. Compilers are governed by a lot of factors, not the least of which is the target OS. The last company I worked for used that version exclusively, and then jumped straight to Web enablement, skipping past any 32-bit development.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
I need that version to interface with an old Cobol program that only works with a 16 bit object. I managed to find it at a sit that specializes in "abandoned software".
|
|
|
|
|
I am searching for a method to disable certain topics in the standard MSOffice menues, especially the "Save as" feature in the file menue of MSword or MSExcel, when starting these programs from a C++ program.
peter
|
|
|
|
|
Hi....I seem to have run into an issue with property pages under release mode (works fine in debug) and not really sure what is going on. Any pointers would be greatly apperciated
Debug Assertion Failed in 'dlgprop.cpp' the call stack seems to be pointing to the 'ASSERT' line in AddPage function
void CPropertySheet::AddPage(CPropertyPage* pPage)
{
..
..
..
ASSERT_KINDOF(CPropertyPage, pPage);
..
..
..
}
<br />
<br />
<br />
CPage1* m_Page1;<br />
CPage2* m_Page2;<br />
CPage3* m_Page3;<br />
<br />
<br />
<br />
m_Page1 = new CPage1(this);<br />
m_Page2 = new CPage2(this);<br />
m_Page3 = new CPage3(this);<br />
<br />
AddPage(m_Page1); <<- SEEMS TO FAIL HERE----<br />
AddPage(m_Page2);<br />
AddPage(m_Page3);<br />
<br />
SetWizardMode();<br />
|
|
|
|
|
If you are running a release build of an executable and are getting Debug Assertion Fail messages, it sounds like you have a mismatch of binaries somewhere (like a Release EXE using a Debug Lib or DLL).
Generally not a good idea unless you really know what you are doing.
Peace!
-=- James Please rate this message - let me know if I helped or not!<HR>If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles
|
|
|
|
|
arunkk1 wrote:
Debug Assertion Failed in 'dlgprop.cpp' the call stack seems to be pointing to the 'ASSERT' line in AddPage function
There are four assertions. Which one?
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
I'm really not sure what you mean by 'four assertions' but it was pointing to this line 'in AddPage() ASSERT_KINDOF(CPropertyPage, pPage);'
As far as having a 'Debug Assertion Failure' in release mode, I have debugging info turned on in project properties...
Thanks
|
|
|
|
|
arunkk1 wrote: As far as having a 'Debug Assertion Failure' in release mode, I have debugging info turned on in project properties...
I do not believe that will turn on the ASSERT/ASSERTE macros (they require the _DEBUG preprocessor def to be #defined), which are what you are seeing getting triggered.
Peace!
-=- James Please rate this message - let me know if I helped or not!<HR>If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles
|
|
|
|
|
arunkk1 wrote: I'm really not sure what you mean by 'four assertions'...
The first four statements in the CPropertyPage::AddPage() method are assertions. The one in question is telling you that your property page is not derived from CPropertyPage.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
I moved to UNIX/Java world mostly few years ago. Used to know Windows.
Remember there was a Windows function to limit desktop area size, so one may a dock his dialog app on a side and may it visible permanent.
Anybody may kick me in right direction?
Thanks.
Life is difficult, but luckily is short.
|
|
|
|
|
|
Thanks.
|
|
|
|
|
I am attempting to patch my software for the upcoming Daylight Saving Time (DST) changes, where for example the Spring DST transition is now on March 11, 2007 instead of April 1. I was running some test code using mktime() under Visual Studio 6.0 and Visual Studio 2005 and it looks like mktime() was still treating April 1, 2007 as the DST transition day.
I am running Windows XP sp2, with all the latest critical fixes installed. VS6 has the latest service packs on it and a fairly late Core SDK installed. VS2005 is the original install without service pack 1 installed.
Does anyone know if/when/where the updates for Win32 APIs such as mktime() are going to be available, or if I am missing something here?
Thanks for any help you can give! I am installing sp1 for VS2005 soon and will report back with my findings. Here is the sample code that I use in VS6 or VS2005, and in both cases I get "diff days: 0, (total seconds: 82800)", where I would expect "1" and "86400" if April 1, 2007 was just any other day:
<br />
struct tm a, b;<br />
time_t ta, tb;<br />
CTimeSpan diff;<br />
CString csTemp;<br />
<br />
memset(&a, 0, sizeof(a));<br />
memset(&b, 0, sizeof(b));<br />
<br />
a.tm_mon = 3;<br />
a.tm_mday = 1;<br />
a.tm_year = 2007 - 1900;<br />
a.tm_isdst = -1;<br />
<br />
b.tm_mon = 3;<br />
b.tm_mday = 2;<br />
b.tm_year = 2007 - 1900;<br />
b.tm_isdst = -1;<br />
<br />
ta = mktime(&a);<br />
tb = mktime(&b);<br />
<br />
diff = CTimeSpan(tb) - CTimeSpan(ta);<br />
<br />
csTemp.Format("diff days: %d, (total seconds: %d)", diff.GetDays(), diff.GetTotalSeconds());<br />
MessageBox((LPCTSTR)csTemp);<br />
|
|
|
|
|
See here.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Thanks so much for your reply. Installing the KB928388 update did in fact fix this problem. I had "assumed" that this important DST update was already in the MS Windows critical fixes which I had already installed, further reading the notes says that it is optional for now, and will hit critical status once they work out some bugs with Outlook 2003 and the DST changes.
Thanks again!
|
|
|
|
|
Hi,
first, I don't think I'm capable of providing the necessary information up front for the answer to my question so I'll really only be asking for links to enable me to educate myself a little further.
how can I trace back a problem associated with an assertion failure in wincore.cpp (line 1143). (Windows CE, BTW.)
Basically, I'm calling a dialog from a menu item and when the dialog is closed (either IDOK or IDCANCEL) the assertion is thrown. I've checked certain variables but their values appear OK.
One debugging message I'm getting is:
Assertion Failed: {Appname}: File wincore.cpp. line 1143
Warning: calling DestroyWindow in CWnd::~CWnd; OnDestroy or PostNcDestroy in derived class will not be called.
{rinse/repeat 5 more times.
|
|
|
|
|
Is this with a modeless dialog? Are you calling EndDialog() at any point? Have you overridden either OnOK() or OnCancel()?
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
OK, here's what happening in the view class:
<br />
void CCEGUIView::OnOptionsSettings() <br />
{<br />
CRecSetupDlg dlg;<br />
dlg.m_bMinutes = m_bMinutes;
<br />
int iResult = dlg.DoModal();<br />
if(iResult == IDOK)<br />
{<br />
m_bMinutes = dlg.m_bMinutes;<br />
}<br />
}<br />
EndDialog() is not being called in the CCEGUIView::OnOptionsSettings() function.
EndDialog() *is* being called in the CRecSetupDlg::OnOK() function.
In the CRecSetupDlg class, OnOK() is over-ridden and EndDialog(IDOK) is called as the last statement in the OnOK() function.
OnCancel() is not over-ridden - in fact, it's not displayed in the code - the default is being used. Pressing 'CANCEL' or 'OK' causes the assertion fault.
|
|
|
|
|
When the assertion fires, look at the stack window to see where the assertion came from (before wincore.cpp).
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
I walked the entire stack for this problem by setting a breakpoint inside my CRecSetupDlg::OnOK() function.
Here's the entire stack before the assertion, I'm going to walk it again looking for the ASSERT() macro:
<br />
CRecSetupDlg::OnOK(CString {"?Æ?"}) line 193<br />
<br />
_AfxDispatchCmdMsg(CCmdTarget * 0x2a07eec0 {CCmdTarget}, unsigned int 1, int 0, void (void)* 0x00bc1354 [thunk]:`vcall'{196,{flat}}' , void * 0x00000000, unsigned int 12, AFX_CMDHANDLERINFO * 0x00000000) line 88<br />
<br />
CCmdTarget::OnCmdMsg(unsigned int 1, int 0, void * 0x00000000, AFX_CMDHANDLERINFO * 0x00000000, unsigned int 273) line 302 + 52 bytes<br />
<br />
CDialog::OnCmdMsg(unsigned int 1, int 0, void * 0x00000000, AFX_CMDHANDLERINFO * 0x00000000, CWnd * 0x00c566ac CThreadLocal<class _AFX_THREAD_STATE>::CreateObject(void)) line 101 + 28 bytes<br />
<br />
CWnd::OnCommand(unsigned int 1, long 1231936, HWND__ * 0x0012cc40) line 2273<br />
<br />
CWnd::OnWndMsg(unsigned int 273, unsigned int 1, long 1231936, long * 0x2a07e970, long 0) line 1774 + 32 bytes<br />
<br />
CWnd::WindowProc(unsigned int 273, unsigned int 1, long 1231936, long 0) line 1762 + 44 bytes<br />
<br />
AfxCallWndProc(CWnd * 0x2a07eec0 {CWnd hWnd=0x0012ca20}, HWND__ * 0x0012ca20, unsigned int 273, unsigned int 1, long 1231936) line 233 + 36 bytes<br />
<br />
AfxWndProc(HWND__ * 0x0012ca20, unsigned int 273, unsigned int 1, long 1231936) line 398 + 28 bytes<br />
<br />
AfxWndProcBase(HWND__ * 0x0012ca20, unsigned int 273, unsigned int 1, long 1231936) line 236 + 20 bytes<br />
<br />
800453b0()<br />
Earlier, I walked it all the way back to AfxWndProcBase(...) and that's where the assertion failure happened - well, was reported anyway. Then, after entering that function, the IDE crashed and my link was broken.
{{sidebar: What's the last function: '800453b0()'? Is that the address of calling function/class? }}
|
|
|
|
|
But you need to examine the call stack after the assertion fires, not before.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
