|
Under VS7 (but not VS6), I consistently get an exception error during the mfc70.dll cleanup process:
AFX_MODULE_STATE::~AFX_MODULE_STATE()
{
#ifndef _AFX_NO_DAO_SUPPORT
delete m_pDaoState;
#endif
...
on the delete statement. I'm properly closing my DAO database, etc. No asserts are happening. Does anyone have any idea? This looks like an MFC70.DLL bug to me.
Marc
|
|
|
|
|
WHen i try to compile a program including commdlg.h i get 102 compiling errors. almost everyone of them are because of undeclared identifiers like APIENTRY, UINT and DWORD. i don't understand why it gives me so many errors and why it can't recognize DWORD and UINT. what's wrong?
|
|
|
|
|
are you including "windows.h" before including commdlg.h ?
-c
To explain Donald Knuth's relevance to computing is like explaining Paul's relevance to the Catholic Church. He isn't God, he isn't the Son of God, but he was sent by God to explain God to the masses.
/. #3848917
|
|
|
|
|
This is probably really simple but my poor brain hurts.
I have some code that checks if it can make sense of the data loaded during serialisation in my CDocument derived class.
void CPERDoc::Serialize(CArchive& ar)<br />
{<br />
AfxMessageBox("Data not recognisable");<br />
}
When AfxMessageBox is called, The dialog box appears and I then get 'Debug Assertion Failed at line 628 of wincore.cpp'
the relevant bit of code in wincore.cpp is this..
void AFXAPI AfxHookWindowCreate(CWnd* pWnd)<br />
{<br />
_AFX_THREAD_STATE* pThreadState = _afxThreadState.GetData();<br />
if (pThreadState->m_pWndInit == pWnd)<br />
return;<br />
<br />
if (pThreadState->m_hHookOldCbtFilter == NULL)<br />
{<br />
pThreadState->m_hHookOldCbtFilter = ::SetWindowsHookEx(WH_CBT,<br />
_AfxCbtFilterHook, NULL, ::GetCurrentThreadId());<br />
if (pThreadState->m_hHookOldCbtFilter == NULL)<br />
AfxThrowMemoryException();<br />
}<br />
ASSERT(pThreadState->m_hHookOldCbtFilter != NULL);<br />
ASSERT(pWnd != NULL);<br />
### ASSERT(pWnd->m_hWnd == NULL);
<br />
ASSERT(pThreadState->m_pWndInit == NULL);
pThreadState->m_pWndInit = pWnd;<br />
}
During debug, the little yellow arrow stops by the three hashes.
I can work my way around it but can anybody tell me why this does not work?
It happens if I call AfxMessageBox() from anywhere in CDocument. Funnily enough GetMainWnd()->MessageBox() causes the same error if put in the CDocument Class.
Would appreciate some help! Many Thanks!! 
Adam.
"I spent a lot of my money on booze, birds and fast cars. The rest I just squandered"
George Best.
|
|
|
|
|
Okay... I am totally totally barking up the wrong tree. Sorry about that. The problem was an entirely different bug.
I was trying to create a modeless dialog that had not been prev. destroyed with DestroyWindow()
thicko or what! 
"I spent a lot of my money on booze, birds and fast cars. The rest I just squandered"
George Best.
|
|
|
|
|
The following code adds to the "Menu Commands" for a Document. In the Debug
version, everything works fine. In the Release version, the routine
FindMenuTitle fails. After a little research in to the problem, in
the routine "FindMenuTitle" the call to "::IsMenu" fails.
I have included the code for "FindMenuTitle" and the overridden routine
"GetDefaultMenu". If you have any insight, it would be greatly appreciated.
int<br />
CTachmateDoc::FindMenuTitle(CMenu& menu, LPCTSTR searchfor)<br />
{<br />
UINT i;<br />
CString title;<br />
CString msg;<br />
<br />
ASSERT(menu);<br />
ASSERT(::IsMenu(menu.GetSafeHmenu()));<br />
<br />
if (::IsMenu(menu.GetSafeHmenu())) {<br />
for (i = 0; i < menu.GetMenuItemCount(); i++) {<br />
menu.GetMenuString(i, title, MF_BYPOSITION);<br />
<br />
if (title == searchfor) return(i);<br />
}<br />
}<br />
<br />
return(-1);<br />
}<br />
<br />
HMENU CTachmateDoc::GetDefaultMenu()<br />
{<br />
BOOL menu_changed = FALSE, map_found = FALSE, histo_found = FALSE;<br />
int menu_pos;<br />
CString edit_menu, graph_menu, map_menu, histo_menu;<br />
CString msg;int results;<br />
CMenu menu;<br />
POSITION pos;<br />
CView *pView;<br />
<br />
graph_menu.LoadString(IDS_GRAPH_MENU_STRING);<br />
edit_menu.LoadString(IDS_EDIT_MENU_STRING);<br />
map_menu.LoadString(IDS_MAP_MENU_STRING);<br />
histo_menu.LoadString(IDS_HISTO_MENU_STRING);<br />
<br />
pos = GetFirstViewPosition();<br />
while (pos != NULL) {<br />
pView = GetNextView(pos);<br />
if (pView->IsKindOf(RUNTIME_CLASS(CTrackView))) {<br />
map_found = TRUE;<br />
menu_pos = FindMenuTitle(m_DefaultMenu, map_menu);<br />
<br />
if ((pView->IsWindowEnabled() || pView->IsWindowVisible()) && (menu_pos == -1)) {<br />
menu_changed = TRUE;<br />
<br />
menu_pos = FindMenuTitle(m_DefaultMenu, graph_menu);<br />
ASSERT(menu_pos != -1);<br />
menu_pos++;
<br />
ASSERT(menu.LoadMenu(IDR_TRACKMAP_ADD));<br />
results = m_DefaultMenu.InsertMenu(menu_pos, MF_BYPOSITION | MF_STRING | MF_POPUP,<br />
(UINT)menu.Detach(), map_menu);<br />
}<br />
else if (!pView->IsWindowVisible() && (menu_pos != -1)) {<br />
menu_changed = TRUE;<br />
<br />
m_DefaultMenu.RemoveMenu(menu_pos, MF_BYPOSITION);<br />
}<br />
}<br />
else if (pView->IsKindOf(RUNTIME_CLASS(CHistogramView))) {<br />
histo_found = TRUE;<br />
menu_pos = FindMenuTitle(m_DefaultMenu, histo_menu);<br />
<br />
if ((pView->IsWindowEnabled() || pView->IsWindowVisible()) && (menu_pos == -1)) {<br />
menu_changed = TRUE;<br />
<br />
menu_pos = FindMenuTitle(m_DefaultMenu, edit_menu);<br />
<br />
ASSERT(menu.LoadMenu(IDR_HISTOGRAM_ADD));<br />
m_DefaultMenu.InsertMenu(menu_pos, MF_BYPOSITION | MF_STRING | MF_POPUP,<br />
(UINT)menu.Detach(), histo_menu);<br />
}<br />
else if (!pView->IsWindowVisible() && (menu_pos != -1)) {<br />
menu_changed = TRUE;<br />
<br />
m_DefaultMenu.RemoveMenu(menu_pos, MF_BYPOSITION);<br />
}<br />
}<br />
}<br />
<br />
if (!map_found) {<br />
menu_pos = FindMenuTitle(m_DefaultMenu, map_menu);<br />
if (menu_pos != -1) {<br />
menu_changed = TRUE;<br />
<br />
m_DefaultMenu.RemoveMenu(menu_pos, MF_BYPOSITION);<br />
}<br />
}<br />
<br />
if (!histo_found) {<br />
menu_pos = FindMenuTitle(m_DefaultMenu, histo_menu);<br />
if (menu_pos != -1) {<br />
menu_changed = TRUE;<br />
<br />
m_DefaultMenu.RemoveMenu(menu_pos, MF_BYPOSITION);<br />
}<br />
}<br />
<br />
return(m_DefaultMenu.m_hMenu);<br />
}
Eldon Zacek
Czech-Mate Enterprises, LLC
|
|
|
|
|
Eldon Zacek wrote:
ASSERT(menu.LoadMenu(IDR_HISTOGRAM_ADD));
in release mode, ASSERTs go away, compeletely, along with anything inside them. use VERIFY if you want the code to execute in release mode (in addition to asserting on 0 in debug mode).
-c
To explain Donald Knuth's relevance to computing is like explaining Paul's relevance to the Catholic Church. He isn't God, he isn't the Son of God, but he was sent by God to explain God to the masses.
/. #3848917
|
|
|
|
|
The problem is NOT with the ASSERTS not being present during the Release version. The problem is that ::IsMenu returns TRUE during execution in
in the Debug version but fails in the Release mode. In "FindMenuTitle",
there is an "If" clause to test the validity of ::IsMenu. In the release
mode this test fails, and thus changes are made to the menu.
Thanks for the response and I hope this clarifies the problem a little
better.
Eldon Zacek
Czech-Mate Enterprises, LLC
|
|
|
|
|
Chris,
You pointed out a problem with the code that I missunderstood. What you
found was an eventual problem but not what was wrong with what I
was seeing. After digging through the code, I found that "m_DefaultMenu"
was being loaded with an "ASSERT" macro. Thus the reason "FindMenuTitle"
was failing.
Thanks for the answer!
Eldon Zacek
Czech-Mate Enterprises, LLC
|
|
|
|
|
hey guys.. got three seperate questions.. there pretty quick tho..
1)In Win95/98(1st edition) my CTreeCtrl will not show its checkboxes. Is there any way around this, or am I screwed? (i have no idea how to takle this without using checkboxes, and the data needs to be in a tree to understand it)
2)I have read alot on this oleaut.dll and .Net and win95 issue, and everyone apparently is upset about this, but they say you can get rid of the problem by delay loading the oleaut.dll. i get this message when i compile:
LINK : warning LNK4199: /DELAYLOAD:oleacc.dll ignored; no imports found from oleacc.dll
and i get this message when i try to run it on win95:
A required .DLL file, OLEACC.DLL was not found.
it says it cant delay load it cause its not used, but i cant run my program without it.. i dont get it? i can install the active accessability, but its 1.46 megs which is too big for a floppy.. which is really cruddy since my whole install and help fits on one diskette.. any other suggestsions?
3)What is up with msdn.microsoft.com? it seems like they reformated their site.. now if i search for 'CListCtrl' i get NO responces?! whats up with msdn? anyone else tried it since tuesday?
-dz
|
|
|
|
|
welp i found my answer to number 1 (now that msdn will let me search again)..
just add the following in your OnInitDialog() for your dialog:
..
..
CDialog::OnInitDialog();
m_tcMyTree.ModifyStyle(TVS_CHECKBOXES, 0);
m_tcMyTree.ModifyStyle(0, TVS_CHECKBOXES);
.. Somehow that makes the checkboxes showup.. its strange cause they showed up on 98 second edition, and higher without these commands.. but whatever works eh?
-dz
|
|
|
|
|
One of the CWnd::OnActiveApp() message parameters is HTASK. I dug all over the MSDN (On/Offline) and written some blur thingy about "the handle identifies the task that owns the CWnd being de/activated". Is it process ID? process handle?
HINSTANCE? In another way: WTF@#$%! is HTASK in this context???
Plz respond, over.
--BlackSmith--
"With the help of all mighty", 2001, Me.
|
|
|
|
|
In the docs that come with VS.NET, CWnd::OnActivatateApp is documented as follows:
afx_msg void OnActivateApp(
BOOL bActive,
DWORD dwThreadID
);
Also, if you look up the docs for the underlying Windows message (WM_ACTIVATEAPP), it shows this (and this is from the VC++ 6 documentation):
LRESULT CALLBACK WindowProc(
HWND hwnd,
UINT uMsg,
WPARAM wParam,
LPARAM lParam
); That backs up that when they say 'HTASK', they really mean DWORD threadId.
Hope that helps...
Stuart Dootson
'Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p'
|
|
|
|
|
Hi,
anybody know, how can I add my own dialog box to system informations (right click on file in explorer) about file? Can anybody tell me how or where are the informations about this??
thanks
defox
|
|
|
|
|
I;m trying to add functionality to my app that will allow users to draw a box around a group of items in the view to select. This would function much like in power point and the like where you can select a group of items. It would even function like the dialog creation/editing part of VC++. Anyway, I'm trying to use DrawDragRect but am getting some unwanted results what with the default brush and all.
Does anyone have any ideas on how to make this work? The code that I'm using in my OnMouseMove is:
aDC.SetROP2(R2_NOT);
CRect lpRect = CRect(m_FirstPoint, point);
aDC.DrawDragRect(lpRect, CSize(1, 1), m_RedrawRectLast, CSize(1, 1), NULL, NULL);
m_RedrawRectLast = lpRect;
|
|
|
|
|
Please bear with me, this is a lot to explain...
I have a C++ dll that I wrote to call Crystal Reports API functions. It basically just modifies query statements and exports to different formats or prints to a printer. When compiled with debug settings, using MFC statically linked, it works fine on Win2k Server. When compiled as a final release, using MFC as a shared library, it works fine, with one exception: when the report needs to create multiple html pages during the export process, I get a very general Crystal Reports error (Operation not yet implemented). Sounds like a Crystal Reports problem, I know. But there's more---
After much testing, I realized that if the correct number of files (or more) already exist, this error does not occur using the MFC shared dll. It seems to just overwrite the existing files, but it will not create them. The statically linked dll, however, will create the files. Sounds more like an MFC problem, now.
I'm compiling on a WinXP Pro PC, using VC++ 6.0 SP5. I've also tried compiling release version with MFC statically linked, but of course the linker ignores references to kernel32.dll, so it's not the same and the error still occurs. Incidentally, my PC at home, running software identical to the Win2k server except for the OS (it's XP), runs this dll just fine compiled either way. So I had a co-worker compile it on Win98, thinking maybe it had something to do with XP, and the exact same behavior occurred. I guess I'll try Win2k next...
Anyway, any insight into this problem would be greatly appreciated, as this is driving me nuts. I'm fairly experienced with C++, but I don't know much about MFC. It would be nice to have this dll around the 36K size that it should be, though, rather than the 1.33MB that it is right now.
~DW
|
|
|
|
|
I *always* statically link MFC - because you can't be sure what version of MFC42.DLL the user has on their system, so you may have to install a new one. And I hate having to install over system DLL's.
But I have read that there is a macro, called AFX_MANAGE_STATE, that you need to call for any expoted function. It goes something like this:
AFX_MANAGE_STATE(AfxGetStaticModuleState());
According to this MFC book (Inside Visual C++), this macro exists because there are some global variables that need to be synchronised correctly in these scenarios.
Even if you win the rat race, you're still a rat.
|
|
|
|
|
>>Even if you win the rat race, you're still a rat.
And whats your point? 
Thats a good one......
|
|
|
|
|
SO far whenevr I created a member variable associated with an editBox I've made it of type CEdit (control not CString), but the Class wizard also offers the choice of CString. I didnt think much about it. But in a sample I am following, I see that a CString variable m_editString has been created for an IDC_EDIT1, and by magic the text put into m_EditString, populates the editbox! I was expecting to see the usual member of type CEdit and stuff like:
myCedit.SetWindowText(someCString).
I've hunted high and low in the sparse sample code and dont see anyplace where the string is being assigned to the editbox. SO is this something internal that happens if you create a CString variable instead of a CEdit variable and associate it with a CEdit?
Basically I wasnt curious about what the option - Control or Value was present for. Please clarify if my deductions are correct? I am probably totally off the mark, but I really do not see anyplace where a string is being setwindowtexted. Hope my question is clear.
Thanks,
ns
|
|
|
|
|
It is handled in your dialog's DoDataExchange function. You will find a wizard generated call to DDX_Text() that assigns the string to the editbox. Alternatively, if you specify a max string length when you are in Class wizard, you will find a DDV_MaxChars() call associated with the same edit control
HTH
CPUA 0x5041
Sonork 100.11743 Chicken Little
"So it can now be written in stone as a testament to humanities achievments "PJ did Pi at CP"." Colin Davies
Within you lies the power for good - Use it!
|
|
|
|
|
I prefer to manually get/set CStrings from edit controls because it allows me full control over validating the user's input. I set controls in the dialog's OnInitDialog() handler, and get the controls' values in OnOK().
/ravi
Let's put "civil" back into "civilization"
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
well, personally, I prefer CString, if you just want to deal with its text display and retrieving. As the above post mentioned, this is done by MFC via data exchange and data validation.
use UpdateData(TRUE) to get user input for this CString variable, while UpdateData(TRUE) in place for SetWindowText.
|
|
|
|
|
Definitely something new I learned today! I'd never even pondered why there were two choices - Value or Control when setting a variable for CEdit!!
Appreciate the responses,
ns;P
|
|
|
|
|
Hi All,
I've got an existing app (MFC MDI app) that does some neat calculations. I have been running this app manually, but now I need to be able to "talk" to the app from another application. I'm thinking COM interface, but not sure exactly how this works. The other app needs to be able to control the MDI app, change data structures, stuff like that. I tried to make a new MFC project with "Automation" checked, and got another MFC app whose document sported a disp interface, but wasn't too sure what to do with that.
So, here's my question. Assuming I've imlpemented an MFC app with automation support, and added some methods I would like to call, how can I A) Fire off this app from an existing ATL COM object (In proc) B) Invoke methods on the document and C) prevent the user from interacting with the app.
Thanks in advance,
Aaron
|
|
|
|
|
No, this is not a question about cars
I would like to add functionality to my MFC dialog so that the user can click a button to make the window "rollup". Similar to the middle top-right button in Winamp.
Anyone have any ideas on this?
I'd prefer it if I could make the design similar to Winamp in that a "new" dialog is shown as the "rolled up" window, but if this is not possible, then just showing the title bar is acceptable (I suppose). I assume doing it this second way would just be resizing dialog to something slightly bigger than the titlebar, now that I think about it. 
TIA.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
