|
What happens if you comment this line? ->
m_COMOnlyButtonArray[nDex].SetFont(&m_font);
Do you need to set your custom font?
|
|
|
|
|
|
How can I hide the toolbar in some dialogs and display it in others?
Thanks!
Richard
|
|
|
|
|
Let's say I create an SDI app w/ Appwizard using a CRichEditView instead of a regular view. (could be mdi for all i care, also has compound document support since cricheditview demands it)
When I compile and run the sample, it should run right? It shouldn't actually do anything since I haven't implemented anything, but it should at the very least run and let me type text, right? I'm thinking this way because when I create a default project using CEditView (doesn't ask for or need compound document support), it works fine, sort of.
Anyway, this is what I get in the trace window, but I'm not sure how to proceed. Any ideas/pointers?
Detected memory leaks!
Dumping objects ->
strcore.cpp(118) : {101} normal block at 0x003014E0, 18 bytes long.
Data: < Read> 01 00 00 00 05 00 00 00 05 00 00 00 52 65 61 64
H:\Program Files\Microsoft Visual Studio\MyProjects\test4\test4Doc.cpp(19) : {98} client block at 0x00302760, subtype 0, 244 bytes long.
a CTest4Doc object at $00302760, 244 bytes long
array_p.cpp(110) : {97} normal block at 0x00302880, 20 bytes long.
Data: < d 0 > 00 00 00 00 64 16 30 00 00 00 00 00 CD CD CD CD
array_p.cpp(71) : {96} normal block at 0x003028C0, 4 bytes long.
Data: < > 00 00 00 00
winfrm2.cpp(66) : {95} client block at 0x003028F0, subtype 0, 168 bytes long.
a CDockBar object at $003028F0, 168 bytes long
array_p.cpp(71) : {94} normal block at 0x003029D0, 4 bytes long.
Data: < > 00 00 00 00
winfrm2.cpp(66) : {93} client block at 0x00302A00, subtype 0, 168 bytes long.
a CDockBar object at $00302A00, 168 bytes long
array_p.cpp(71) : {92} normal block at 0x00302D70, 4 bytes long.
Data: < > 00 00 00 00
winfrm2.cpp(66) : {91} client block at 0x00302AE0, subtype 0, 168 bytes long.
a CDockBar object at $00302AE0, 168 bytes long
winfrm2.cpp(66) : {89} client block at 0x00302BC0, subtype 0, 168 bytes long.
a CDockBar object at $00302BC0, 168 bytes long
bardock.cpp(735) : {88} normal block at 0x00302DA0, 176 bytes long.
Data: < K_ > 84 01 4B 5F CD CD CD CD CD CD CD CD CD CD CD CD
strcore.cpp(118) : {87} normal block at 0x00302CA0, 17 bytes long.
Data: < SCRL> 01 00 00 00 04 00 00 00 04 00 00 00 53 43 52 4C
strcore.cpp(118) : {86} normal block at 0x00302CE0, 16 bytes long.
Data: < NUM > 01 00 00 00 03 00 00 00 03 00 00 00 4E 55 4D 00
strcore.cpp(118) : {85} normal block at 0x00302D20, 16 bytes long.
Data: < CAP > 01 00 00 00 03 00 00 00 03 00 00 00 43 41 50 00
{81} normal block at 0x00302EF0, 80 bytes long.
Data: < > 00 00 00 00 00 01 00 00 00 01 00 08 00 00 00 00
plex.cpp(31) : {78} normal block at 0x00302F70, 124 bytes long.
Data: < /0 d 0 > 00 00 00 00 80 2F 30 00 00 00 00 00 64 16 30 00
strcore.cpp(118) : {66} normal block at 0x003014A0, 18 bytes long.
Data: < test> 01 00 00 00 05 00 00 00 05 00 00 00 74 65 73 74
H:\Program Files\Microsoft Visual Studio\MyProjects\test4\test4.cpp(93) : {64} client block at 0x00301520, subtype 0, 484 bytes long.
a CMainFrame object at $00301520, 484 bytes long
plex.cpp(31) : {63} normal block at 0x00301730, 124 bytes long.
Data: < 0 > 00 00 00 00 00 00 00 00 00 00 00 00 A0 18 30 00
{62} client block at 0x003017E0, subtype 0, 32 bytes long.
a CDocManager object at $003017E0, 32 bytes long
strcore.cpp(118) : {61} normal block at 0x00301830, 57 bytes long.
Data: < , , Tes> 01 00 00 00 2C 00 00 00 2C 00 00 00 0A 54 65 73
H:\Program Files\Microsoft Visual Studio\MyProjects\test4\test4.cpp(84) : {60} client block at 0x003018A0, subtype 0, 144 bytes long.
a CMultiDocTemplate object at $003018A0, 144 bytes long
strcore.cpp(118) : {58} normal block at 0x00301960, 19 bytes long.
Data: < File> 01 00 00 00 06 00 00 00 06 00 00 00 46 69 6C 65
strcore.cpp(118) : {57} normal block at 0x003019A0, 29 bytes long.
Data: < Rece> 01 00 00 00 10 00 00 00 10 00 00 00 52 65 63 65
{56} normal block at 0x003019F0, 20 bytes long.
Data: < L_ L_ L_> 04 00 00 00 14 CB 4C 5F 14 CB 4C 5F 14 CB 4C 5F
{55} normal block at 0x00301A30, 32 bytes long.
Data: << K_ 0 0 > 3C 8D 4B 5F 04 00 00 00 F4 19 30 00 AC 19 30 00
oleinit.cpp(86) : {52} client block at 0x00301AE0, subtype 0, 68 bytes long.
a CCmdTarget object at $00301AE0, 68 bytes long
Object dump complete.
The thread 0xE6 has exited with code 3 (0x3).
The program 'H:\Program Files\Microsoft Visual Studio\MyProjects\test4\Debug\test4.exe' has exited with code 3 (0x3).
--
Peace,
Amit Jain
|
|
|
|
|
I've just created empty MFC app with CRichEditView using AppWizard. Everything works fine, no such thing like memory leaks. The dump you've posted contains lots of stuff, looks like something is terminating your program prematurely.
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
See, it's strange that you can do that because I get the bad results on my work pooter (nt4 sp6) and at home (98se).
Even stranger is that I just found out the program will run just fine if I compile using the Release config instead of Debug.
On deja, I found a guy with almost the same problem who said he had to uninstall and completely reinstall everything. Since this is problematic at work, I'll try it when I get home...
Thanks for trying though
--
Peace,
Amit Jain
|
|
|
|
|
Try overriding ExitInstance in CYourApp and put a breakpoint there. Check if ExitInstance is called.
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
--start--
I had trouble w/ the richedit class for a while, and I believe if you
add Automation support to your app in step 3/6 during the application
creation process, it will cure you ills. (It's a checkbox option toward the
bottom of the dialog during creation)...hope that does the trick, if not let
me know and I can find out for sure. G'luck.
Frank Cronin
--end--
And that worked for me. If anyone has this problem, this is what you try. If anyone else can figure out WHY this is the case, I'd love to hear it...
--
Peace,
Amit Jain
|
|
|
|
|
I'm trying to link an HTML help document into my existing application. I have tried using Microsoft's method of ID_HELP_FINDER however have discovered its wanting a WinHelp document and not a HTML Help document. Does anyone know how I might be able to tweak my application so that I will accept the HTML Help file?
Also I'm noticing that apps created using VC++ with the context sensitive help on automatically run MakeHelp.bat. I'm wondering if having the .hm file in a folder called External Dependencies might trigger this event, however I'm having problems figuring out how this folder gets created by VC++. Does anyone know the sequence of events for this to happen?
Thanks!
Chris
|
|
|
|
|
How can I get the floppy/hard disk serial number?
Daniel
|
|
|
|
|
|
Hello everybody!
I´m writing a MDI app. Application Wizard generates two menus:
One (IDR_MAINFRAME), which is displayed when no document is open, the other (IDR_XXXTYPE) when there is at least one document opened.
This code below (from CMainFrame::OnCreate) modifies the first menu. I want to do the same modification to the other menu.
How to do that?
Thank you for any comments.
Jerzy
CMenu PopupMenu;
PopupMenu.CreateMenu();
for(int i=0;i<3;i++)
{
CString str;
str.Format("Item %d",i);
PopupMenu.AppendMenu(MF_STRING,IDM_ITEM+i,str) ;
}
CMenu *m=GetMenu();
m->AppendMenu(MF_POPUP¦MF_STRING,(UINT)PopupMenu.m_hMenu,"&Items");
PopupMenu.Detach();
|
|
|
|
|
Use GetSubMenu to get the proper menu and continue as you have been.
|
|
|
|
|
Hi,
I don't know what you mean to use GetSubMenu()?
This code is working, it ataches a new popup to the main menu.
The problem is that it ataches this submenu to the IDR_MAINFRAME menu (after main frame is created). I need to do the same for IDR_VIEWTYPE menu. I don't know in what moment that menu is created. If I use this code in that moment, the new popup would be attached to IDR_VIEWTYPE menu.
Jerzy
|
|
|
|
|
The handle of the IDR_XXXTYPE menu is accessible through public data member of the CMultiDocTemplate class, it's called m_hMenuShared.
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
Hi Tomek,
Thanks for the solution. It works - it ataches a new popup to IDR_XXXTYPE menu.
But the problem is that I don't know where this code should be placed. If I put it in OnCrete() of ChildFrm, then the new popup is atached as many times as ChildFrm frames were created.
MSDN says something that this menu is loaded during the construction of the document templates. Can I override this?
Thanks for any suggestions.
Jerzy
|
|
|
|
|
You should add popups after creating new CMultiDocTempltate, in CYourApp::InitInstance.
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
Hi Tomek,
Thank you very much for this tip. It works. I had to only call DrawMenuBar() to refresh the menu. Without this call the menu was updated only when the mouse was over the menu. (This is only when the application starts).
When all documents were closed and then I opened a new one the menu was shown correctly.
Dziekuje,
Jerzy
|
|
|
|
|
Netmeisters,
I have a problem with what appears to be a very simple operation. I'd like to use sockets in a simple client application. Initially, to create and connect a socket, I did this:
CCeSocket mySock;
mySock.Create();
mySock.Connect(_T("dp1.derm.mcw.edu"),23501);
However, I'd now like to move to secure sockets, so I thought I'd use the socket handle rather than the socket class. So I changed to this:
SOCKET s;
s=socket(AF_INET, SOCK_STREAM, 0);
SOCKADDR_IN tcpaddr;
tcpaddr.sin_family=AF_INET;
tcpaddr.sin_port=htons(23501);
tcpaddr.sin_addr.s_addr=inet_addr
("dp1.derm.mcw.edu");
int res=connect(s, (SOCKADDR *)&tcpaddr, sizeof
(tcpaddr));
if (res==SOCKET_ERROR) {
CString err;
err.Format(_T("Error
d\n"),WSAGetLastError());
MessageBox(err);
}
This fails with an error 10049, "The requested address is not valid in its context".
I suppose I could use CCeSocket to create the socket and then get the socket handle from the class, but I am annoyed that this doesn't work. Why?
Thanks very much,
Matthew Fleming
mgf@mcw.edu
|
|
|
|
|
Hi,
I've written an MFC MDI app, not using CDocument.
My View class is derived from CTreeView.
Whenever I close a view window, I get an error. When debugging the program and closing the view window, I get a dialog box "User breakpoint called from 0xXXXXXXX" where the 0xXXXXXX is some memory address. My program has no breakpoints, and the debugger stops in a dissasembly window with no relation to my code that i can see.
In the little information window at the bottom, the following line is present:
HEAP[j5manager.exe]: Invalid Address specified to RtlValidateHeap( 910000, 915314 )
My view class is pretty basic- it doesn't do much yet. Default constructor and destructor, they do nothing. The class has 4 member vars, Two CStrings, an HTREEITEM and a CPtrList, but I've not done anything with these so far.
I'm really stumped as to what is causing the problem. Does anyone have any ideas or reccommendations on how to proceed? I'd post some code but I don't know what part to post!
Your help much appreciated.
Thanks
Jon
|
|
|
|
|
Your heap gets corrupted. One of the reasons could be writing past the end of memory block allocated by new or malloc. Do you have any diagnostic tools, like BoundsChecker or Purify?
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
sadly, no I haven't.
Not sure _how_ the heap could be corrupted? like i said, the view class does pretty much nothing at the moment.
|
|
|
|
|
I have a situation where I need to serialize several parts of a document-derived class. Because the standard doc loading / saving mechanism is not quite what I need, I have to construct the CArchive manually. All the serialization is working fine in itself, but the one thing I can't seem to get to work now I need it is the schema business.
My doc-derived class uses IMPLEMENT_SERIAL() with the current schema number correctly. I create the archive correctly and then start serializing out (when saving, this is)... but for some reason it never saves the schema in the binary file. I tried SetObjectSchema() immediately after constructing the CArchive, which certainly sets the internal schema value... but that never gets written to file.
I looked at the code for CDocument where it calls our overriden Serialize() to see how it did it - from that I see it sets the archive's m_pDocument and another member. So I did this also... STILL doesn't save the schema in the file.
Since CDocument::Serialize() does not do anything, calling the base class has no effect.
Any clues as to what I'm missing? Otherwise I'll have to do the schema bit myself. But I'd rather use the built-in stuff as much as possible.
|
|
|
|
|
How are you serializing document members? Using m_foo.Serialize(ar) or ar << m_pFoo?
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
Everything is done using ar << m_pFoo (no objects other than CString are serilaized - most of what is saved is structures, and I do the members of each by hand).
You sound as if you're hinting that each object (class) has its own schema... which I can understand... but should there not be an overall schema for the document / doc-derived object? It does, after all, have IMPLEMENT_SERIAL()...
Basically, I'm not interested in the individual schemas of each thing I serialize - all serializing is done from one class (the doc-derived) (since there are no child objects being serialized, not even CXXXArrays). I want one overall schema that is used in all serializing operations so that I can check it on loading to avoid loading new data from old-schema files...
|
|
|
|
|