|
Well, I gave just the filename in my example because it resulted in less typing. 
I don't know how big a .clw (class wizard) file can get, but the one I'm working on is only 2k at the moment.
I know that the file is being read correctly because I check the "General Iffo" section to find out how many classes are in the clw file and what their names are. The next step is to find out what the associated cpp/h file names are, and this is where reading the .clw file is falling flat on it's face.
I guess I *could* just read all the section names and parse them that way, but what a royal pain in the ass...
|
|
|
|
|
I found the problem - I had the 3rd/4th parameters in the call to GetPrivateprofileString swapped around in my code.
Duh....
|
|
|
|
|
I have recently subclassed an edit box,and capture the WM_CHAR events. I want the dialog that houses the edit box to know a user defined message when I detect certain string in the edit box.
How can I send a message back to dialog? I have tried SendMessage with GetParent() as a handle, but it does not work. Does anyone know how to do this? Thanks all!
|
|
|
|
|
How to add new button (beside min, max and close) to the right side of a caption bar? Any hints?
|
|
|
|
|
look for help about this function:
CDC::DrawFrameControl
Mike
|
|
|
|
|
Do you know how to get the working directory of a process? Do I need to access some shell objects in order to get the working directory of a process? Thanks all.
|
|
|
|
|
The current directory of your own process can be retrieved with GetCurrentDirectory. Is that what you were looking for?
|
|
|
|
|
Mike's right - though sometimes you may want to get the dir in which your app (or another) resides, in order to _make_ that the working dir (we don't always have a choice as to how our apps are invoked via shortcuts etc.).
GetModuleFileName will return the full path to the location of the exe or dll, and you can go from there.
|
|
|
|
|
Hi all,
Please help,
Can anyone rell me how to color text ina c++ consol application run in a dos window. I have tried all ways, and have had know joy.
What #include file and how?
Any help would be really accepted.
|
|
|
|
|
There are lots of great things you can do with the console api.
First you get a handle to the console:
hConsole = GetStdHandle(STD_OUTPUT_HANDLE);
This may be 0 - as long as its not INVALID_HANDLE_VALUE you're ok. (Note - you'll need to #include <windows.h>)
Now you can set colors. This sets white text on a red background:
SetConsoleTextAttribute(hConsole, FOREGROUND_RED |
FOREGROUND_GREEN | FOREGROUND_BLUE |
BACKGROUND_RED);
I tested with printf, and assume cout is ok. You might like to investigate the fns like WriteConsole etc. Search for "Console functions" in the msdn. There is stuff for positioning too.
|
|
|
|
|
Hi Everyone,
How do I pass the values of a variable in one dialog box to another dialog box??
For example, let say I have a dialog box with an edit box and a button. So when I type something into the edit box and presses the button, the value of what I typed is stored in the variable for the edit box.
Then how do I use that edit box variable in a DIFFERENT dialog box? Let say I want to display of whatever I typed in the edit box from the first dialog into a List box in the second dialog box, how do I do that?
If anyone has any ideas, PLMK.
Thanks in Advance!
Steve
|
|
|
|
|
If the windows are active at the same time, and you can get the hWnd of one from the other (perhaps a parent/child realtionship) you might use GetDlgItem to get a handle to the control in the other window.
Otherwise, you may have to set up a var somewhere that both dialogs can access.
|
|
|
|
|
Assumptions:
1) The other dialog box is instantiated when the button is pressed.
2) Both dialogs are contained in the same process (application).
3) You are familiar enough with Visual C and MFC to make this work.
///////////////////////////////////////////////////////
Put this in a header file used by both dialog box class CPP files:
const int UWM_MYMESSAGE = WM_APP + 1;
///////////////////////////////////////////////////////
Put this code in the dialog box that has the button in it (substitute your own identifiers for the ones I used):
CMyDialog1::OnButtonPressed()
{
CString sTemp;
GetDlgItem(IDC_MYEDITCONTROL)->GetWindowText(sTemp);
PostMessage(UWM_MYMESSAGE, (WPARAM)((LPCSTR)sTemp), 0);
}
////////////////////////////////////////////////////////
Put this line in the header file second dialog box that will be displaying the text:
afx_msg LRESULT OnMyMessage(WPARAM wParam, LPARAM lParam);
You have to put this just before the line that reads:
DECLARE_MESSAGE_MAP()
///////////////////////////////////////////////////////
Put his line in the CPP file for the second dialog box class:
ON_MESSAGE(UWM_MYMESSAGE, OnMyMessage)
Again, put the previous line just before this one:
END_MESSAGE_MAP()
///////////////////////////////////////////////////////
Lastly, put a function in the CPP file for the second dialog box class that handles the message:
void CMyDialog2::OnMyMessage(int nMsgType, CString sMsg)
{
// m_MyText is an edit control declared as a CString
// value
m_MyText = (LPCTSTR)wParam;
UpdateData(FALSE);
}
=======================================================
The code above allows you to exchange data between windows/dialogs without having to setup a global variables (global var'ables are bad, mmmokay?).
|
|
|
|
|
I have this problem. I have CView derived class. In the OnCreate function I
create a CRichEditCtrl like this:
AfxInitRichEdit();
m_richEdit.Create(ES_AUTOVSCROLL | ES_AUTOHSCROLL | ES_MULTILINE |
ES_WANTRETURN |
WS_CHILD | WS_VISIBLE | WS_VSCROLL | WS_HSCROLL, rect, this, 1);
where m_richEdit is a CRichEditCtrl variable defined in the header file of
my CView class. In OnSize I set the
appropriate size of the control.
Now I have this problem. What do I have to do to print the contents of the
m_richEdit and to see the contents of this
in Print Preview. I have tried many thinks, but I failed.
Thank you very much.
David Pokluda
pokluda@mujweb.cz
|
|
|
|
|
I have done this with a CView derived child (CScrollView) but not with a CWnd derived child. With the CView child the code looked like this:
void CViewClass::OnPrint(CDC* pDC, CPrintInfo* pInfo)
{
//Resize the child if needed.
m_child.MoveWindow(&m_rectChild, TRUE);
//Print the child.
m_child.OnPrint(pDC, pInfo);
//Call the base class.
CView::OnPrint(pDC, pInfo);
}
Now the CWnd child does not have the OnPrint(...) method. But you may be able to use the CWnd::Print(CDC* pDC, DWORD dwFlags) method instead.
Please let me know if it works...
Jonathan Craig
|
|
|
|
|
The CWnd::Print(…) method will not work. But the CRichEditCtrl knows how to render itself to a device context. The code below will work. I didn’t have a chance to figure out the formatting. You need to look up the FORMATRANGE structure in the MSDN. The code below was cut and pasted for the MSDN article CRichEditCtrl::FormatRange. Also look at the MSDN article Printing in Rich Edit Controls. If you don’t have MSDN you can search Microsoft’s web site.
void CPrintChildWindowView::OnPrint(CDC* pDC, CPrintInfo* pInfo)
{
FORMATRANGE fr;
long lPageWidth = ::MulDiv(pDC->GetDeviceCaps(PHYSICALWIDTH),
1440, pDC->GetDeviceCaps(LOGPIXELSX));
long lPageHeight = ::MulDiv(pDC->GetDeviceCaps(PHYSICALHEIGHT),
1440, pDC->GetDeviceCaps(LOGPIXELSY));
CRect rcPage(0, 0, lPageWidth, lPageHeight);
// Format the text and render it to the printer.
fr.hdc = pDC->m_hDC;
fr.hdcTarget = pDC->m_hDC;
fr.rc = rcPage;
fr.rcPage = rcPage;
fr.chrg.cpMin = 0;
fr.chrg.cpMax = -1;
m_pREC->FormatRange(&fr, TRUE);
// Update the display with the new formatting.
RECT rcClient;
m_pREC->GetClientRect(&rcClient);
m_pREC->DisplayBand(&rcClient);
CView::OnPrint(pDC, pInfo);
}
Good Luck,
Jonathan Craig
|
|
|
|
|
I have this problem. I am developing an application that needs to know how
many papers have been printed on the printer. I would like to do it this
way. The application would be a service or a program that would be running
all the time and when the user prints something it will get the info from
the printer manager. But...
How can I connect to a print manager so that I would now how many pages are
printed? If it is possible is it even possible to figure out the quality of
the printed pages (best/normal/economy)?
Thank you very much for any suggestion.
David Pokluda (pokluda@mujweb.cz)
|
|
|
|
|
How to get a CWnd(CView) background color in a MDI application.
|
|
|
|
|
Try GetDC()->GetBkColor()
|
|
|
|
|
How to get a CWnd(CView) background color in a MDI application.
|
|
|
|
|
How to get a CWnd(CView) background color in a MDI application.
|
|
|
|
|
Its the second time i got this message from ms visual studio 6.0 :
"Debug Assertion Failed !
Program : prgram.exe
File : dlgdata.cpp (?)
Line : 43
For info on debug [...] see ms vsc doc...
Press retry to debug the application"
It just seems to come out of nowhere since my program doesnt pose any problem during the compilation.
Can anyone help me please, i'm stuck ! !
thanks.
|
|
|
|
|
assertions are a good thing!
They are placed in code by the programmer to verify that something is true, and if it isn't true, force (when DEBUG is defined) the display of a nasty message like the one you describe.
You are getting this assertion from an MFC app (via the ASSERT() macro) but the standard library assert() is available as well for non MFC apps.
MFC code uses ASSERTs liberally - as it should. Very often you'll see code that does something like ASSERT(pointer != NULL). If the expression is true, the code continues - but if not (i.e. a NULL pointer) the code will 'assert'. The idea is that its better to see the fault here than to track a subsequent access violation (which may end up in a system DLL).
Note that you have to be careful not to put code with side effects inside an ASSERT - because it won't be compiled for a release build - MFC provides the VERIFY macro if you want to do the equivalent of an assert in a release build.
Philosophies vary on what constitutes a valid place for an assertion. Some say they should be reserved for critical things like NULL pointers that will generally cause a crash. I tend to use them for even minor things that may not be critical but I want to know about them - things that I might miss if I just TRACE a notification to the debug output window.
The ASSERT you are getting comes from CDataExchange - probably some problem with a dialog control ID. What you can do is choose Retry to invoke the debugger, then press Alt+7 to display the call stack. (Or View | Debug Windows | etc.) By looking at the ASSERT statement and the surrounding code, you should be able to identify some offending variable or resource define. You'll often need the call stack to backtrack to the source of the problem, but unless its some nasty mess in your resouce file you should be able to figure it out.
|
|
|
|
|
Thanx a lot !
You've been a great help, thanks to the call stack i noticed some references to edit box ID's which were useless since i had deleted the corresponding edit boxes...
Thank you again !!
|
|
|
|
|
Excellent summary Tim, you should submit it as an article.
As you and I both know , new MFC programmers (and many long standing ones), don't really understand the value and function of ASSERT()'s, and quite often after they start using them, place code in them not realizing the code is only included in a Debug build.
I also agree that they should be used liberally, as they have zero effect on the performance of runtime code.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
