|
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
|
|
|
|
|
elementary dear Watson 
|
|
|
|
|
The resource file is used to reference unique IDs for form data, right? Therefore, there should be exactly _zero_ ID reference #'s that repeat, correct?
Here's my resource.h file - note that repeating numbers are the only ones displayed here; sequential numbered items are removed for brevity's sake.
<br />
#define IDR_RECORDING_TOOLBAR 130<br />
#define IDD_DATALIST 130<br />
#define IDD_MULT_MODBIN_LIST 160<br />
#define IDD_MOD_SELECT_DLG 160<br />
#define IDD_DIALOG3 165<br />
#define IDD_DATA_ITERATOR_DLG 165<br />
#define IDC_MIL 1001<br />
#define IDC_LIST_AVAILABLE 1001<br />
#define IDC_COMBO1 1016<br />
#define IDC_SPECIFIC_CODE_COMBO 1016<br />
#define IDC_TRIGGER_COMBO 1016<br />
#define IDC_COMBO_CATEGORY 1016<br />
#define IDC_CMBO_APPLICATION 1016<br />
#define IDC_COMBO3 1017<br />
#define IDC_COMBO_DOWN 1017<br />
#define IDC_MIN_COMBO 1017<br />
#define IDC_COMBO2 1018<br />
#define IDC_COMBO_APPLICATION 1018<br />
#define IDC_CMBO_CATEGORY 1018<br />
#define IDC_BUTTON1 1022<br />
#define IDC_GET_DTC 1022<br />
#define IDC_BTN_ADD 1022<br />
#define IDC_BTN_ITEMCHECK 1022<br />
#define IDC_BUTTON2 1023<br />
#define IDC_BTN_REMOVE 1023<br />
#define IDC_BUTTON3 1024<br />
#define IDC_BTN_REMOVEALL 1024<br />
#define IDC_CUSTOMDL 1029<br />
#define IDC_BUTTON4 1029<br />
#define IDC_CDL_ALL 1030<br />
#define IDC_BUTTON5 1030<br />
#define IDC_CDL_ADDED 1032<br />
#define IDC_BUTTON7 1032<br />
#define IDC_ADD 1034<br />
#define IDC_BUTTON9 1034<br />
#define IDC_REMOVE 1035<br />
#define IDC_BUTTON10 1035<br />
#define IDC_MONITOR_LIST 1047<br />
#define IDC_SAVE_CDL2 1047<br />
#define IDC_OK_CDL 1047<br />
#define IDC_TIMER 1048<br />
#define IDC_ADD_ALL 1048<br />
#define IDC_REMOVE_ALL2 1049<br />
#define IDC_RESTORE_DEFAULT 1049<br />
#define IDC_TREE1 1100<br />
#define IDC_TREE_DIR 1100<br />
#define ID_BUTTON32782 32782<br />
#define ID_PAUSE 32782<br />
<br />
#ifdef APSTUDIO_INVOKED<br />
#ifndef APSTUDIO_READONLY_SYMBOLS<br />
#define _APS_NEXT_RESOURCE_VALUE 175<br />
#define _APS_NEXT_COMMAND_VALUE 32797<br />
#define _APS_NEXT_CONTROL_VALUE 1102<br />
#define _APS_NEXT_SYMED_VALUE 101<br />
#endif<br />
#endif<br />
<br />
Could this cause me assertion problems? If so, how? I think I know; I just want to hear someone else say it. 
{Sidebar: Note that 'IDC_TREE1' & 'IDC_TREE_DIR' were deleted over two weeks ago.}
|
|
|
|
|
I don't know about causing assertions, but one thing that could easily happen is for the code to reference IDC_BTN_REMOVE and the dialog template to contain IDC_BUTTON3. Since both IDs exist, the compiler is happy. This would likely result in an assertion in the window's DoDataExchange() method, not at closing.
In any case, it might be worth the effort to clean up your project's resource.h file by removing unused IDs and maing the remaing ones sequential.
"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
