|
1 possibility springs to mind:
in both your OnPaint() and OnEraseBkgnd() handlers you call ExcludeClipRect() on the device context to clip out the header rect.
|
|
|
|
|
Throughout my code, after creating an application, I see comments in the header files such as:
//{{AFX_INSERT_LOCATION}}
// Microsoft Visual C++ will insert additional declarations immediately before the previous line.
#endif // !defined(AFX_XMAINWINDOW_H__CB25AA97_9522_4128_9EAE_946D14A1C1EB__INCLUDED_)
What purpose do they serve and I am required to keep them there? I'd prefer to remove them to keep my code as clean as possible for my own organization.
Thanks,
-Matt
|
|
|
|
|
There's an option when you start a new project...
"Would you like to generate source file comment?"
Yes, please
No, thank you
Selecting no generates a project without all the of the source code comments like you described...
|
|
|
|
|
Perhaps it's becuz i use learners edition, I can't afford the full package, but even when I select no comments I still get the comments mentioned by the original poster...
"An expert is someone who has made all the mistakes in his or her field" - Niels Bohr
|
|
|
|
|
I think it only turns off the big comments like the stuff in InitDialog and InitInstance. The small stuff mentioned above is kept, especially the classwizard related stuff.
Michael
Time flies like an arrow. Fruit flies like a banana
|
|
|
|
|
this is part of a header guard. it's a C/C++ trick to prevent a header from being included more than once during a compilation (to avoid multiple declarations). it matches up with the # if!defined and #define stuff at the top of your headers.
don't touch it. these aren't just comments.
-c
For men use, if they have an evil turn, to write it in marble:
and whoso doth us a good turn we write it in dust.
-- Sir Thomas More
|
|
|
|
|
I found this code to create a combobox (to be embedded in a toolbar)
CRect rect;
int nIndex = m_wndToolBar.GetToolBarCtrl().CommandToIndex(ID_COMBO);
m_wndToolBar.SetButtonInfo(nIndex, ID_COMBO, TBBS_SEPARATOR, 205);
m_wndToolBar.GetToolBarCtrl().GetItemRect(nIndex, &rect);
rect.top = 1;
rect.bottom = rect.top + 250 ;
if(!m_comboBox.Create(CBS_DROPDOWNLIST | CBS_SORT | WS_VISIBLE |
WS_TABSTOP | WS_VSCROLL, rect, &m_wndToolBar, ID_COMBO))
{
TRACE(_T("Failed to create combo-box\n"));
return FALSE;
}
I need an editbox, not a combobox. How do I modify this code ? Also, if I want to write stuff to this cEdit , how do I do that? Theres no m_Edit variable as I would have if it were on a form by itself, to do setwindowtext.
Thanks,
|
|
|
|
|
Actually I see that there will be an m_Edit variable so I suppose I can do a SetWindowText.
|
|
|
|
|
You'd change the first parameter to reflect the flags you wanted to apply to the edit box. They are listed in MSDN. The WS_ flags are generic and would remain.
Christian
We're just observing the seasonal migration from VB to VC. Most of these birds will be killed by predators or will die of hunger. Only the best will survive - Tomasz Sowinski 29-07-2002 ( on the number of newbie posters in the VC forum )
Cats, and most other animals apart from mad cows can write fully functional vb code. - Simon Walton - 6-Aug-2002
|
|
|
|
|
i use c++ to communicate with a java app through pipe (simply u can think the java app is javac.exe).
when the java app writes data to pipe (std io), i read data by c++ (Windows-not dos or unix).
with java 1.4, there is no any problem. but for jdk 1.3 or 1.2, i have trouble:
if the java app exits with no suitable signal, c++ doesn't know (if jdk 1.4, c++ knows) and is still waiting there.
i think there must be some idea to know because another side of pipe is closed.
key functions used are:
CreatePipe, CreateProcess, ReadFile.
i think ReadFileEx should be better but i got no idea about it after testing.
thx for ur suggestion.
;);P ((
includeh10
|
|
|
|
|
Are you calling CloseHandle on the pipe handles when you are done with them? This should signal to either the Write or the Read side that the pipe has been closed/broken and you can cleanup/exit.
i.e.:
DWORD dwBytesToRead = 0;
<P></P>
BOOL bStatus = ReadFile( m_hReadPipe, &SomeData, dwBytesToRead, &dwBytesRead, NULL );
<P></P>
if( bStatus && (dwBytesRead > 0) )
{
<P></P>
CloseHandle(m_hReadPipe);
m_hReadPipe = INVALID_HANDLE_VALUE;
}
else
{
if( m_hReadPipe != INVALID_HANDLE_VALUE)
{
CloseHandle(m_hReadPipe);
m_hReadPipe = INVALID_HANDLE_VALUE;
}
}
Roger Stewart
"I Owe, I Owe, it's off to work I go..."
|
|
|
|
|
I had similar problems with a C++ client. The read did not always
give the right error codes to see if the conn was broken.
I used named pipes and there is a very handy function named
PeekNamedPipe
if PeekNamedPipe returns an error, You can be sure that the conn is lost.
If no data is pending, nothing happens.
|
|
|
|
|
I am having some problems on VS.Net
I've just created a popup menu with some IDs (ID__LAUNCHEXPLORER, ID_CLOSEAPP) in the resource editor.
Within VS.Net development environment, I go to the properties page and select 'Menu Commands' then expand the listbox that has ID__LAUNCHEXPLORER so it has the COMMAND field visible. When I then click on the combo box dropdown list and click on 'add' the following error message occurs: "Add/Remove of the function is impossible, because the parent class code is read only"
I can (and did) add the functions manually and type in the mapping through the message map manually too (which works) but I haven't a clue why VS.net's doing this?
Anyone any ideas? Bring back ClassWizard! VS.Net seems to want so many windows open at once I might be persuaded to buy a 24" monitor or something just so I can see the postage stamp that's left for my code!
see ya
Adam.
"I spent a lot of my money on booze, birds and fast cars. The rest I just squandered"
George Best.
|
|
|
|
|
I have a MDI project derived from CFormView. My first form (CMyProjView) links a second form (CForm2) which contains an embedded property sheet.
My data is located inside my Document class (CMyProjDoc) and I want to access
it from the property sheet inside CForm2.
I tried this but get an access violation; probably because the pointer reaching CForm2 only.
CMyProjDoc* pDoc=(CMyProjDoc*)GetTopLevelFrame()->GetActiveDocument();
ASSERT_VALID(pDoc);
pDoc->GetData(0);
How to get a pointer to my Document class?
Any suggestions?
Thanks
Kash
|
|
|
|
|
can you just pass a doc pointer from your view to the property sheet?
-c
For men use, if they have an evil turn, to write it in marble:
and whoso doth us a good turn we write it in dust.
-- Sir Thomas More
|
|
|
|
|
First off, thanks for all the help you all are giving me. I've, however, tried all your suggestions without success. Here's the problem: I want to populate dialog fields with data from my Document class. What I did makes logical sense, but it gives me an 'illegal operation' message when I run the program. Here is the code:
BOOL CSetupDlg::OnInitDialog() {
CDialog::OnInitDialog();
//get pointer to Document
CSEIDoc *pDoc;
//initialize combo box
m_nPeriodDlg.SetCurSel(pDoc->m_nPeriod);//assertion failure here
//initialize check buttons
m_cbCheckGrowth.SetCheck(pDoc->m_bCheckGrowth);//and here
m_cbCheckFeed.SetCheck(pDoc->m_bCheckFeed);//and here
//initialize slider control
m_sdrHaloScale.SetRange(0,15);
m_sdrHaloScale.SetPos(XDIM/96);
return TRUE;
}
How can I overcome this? Thanks again,
Ralf.
ralf.riedel@usm.edu
|
|
|
|
|
CSEIDoc *pDoc; This only declares a pointer to your document class, but does not actually retrieve it. Try with
pDoc=(CSEIDoc *)((CFrameWnd *)(AfxGetMainWnd())->GetActiveView()->GetDocument());
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
I've tried to use CSEIDoc *pDoc = CSEIView::GetDocument; The error message was 'illegal call of non-static member function'. The statement you suggested '(CSEIDoc *)((CFrameWnd *)(AfxGetMainWnd())->GetActiveView()->GetDocument());' gives me a ''GetActiveView' : is not a member of 'CWnd'' error. Any idea how to fix this? Thx,
Ralf.
|
|
|
|
|
CSEIDoc *pDoc = (CSEIDoc *)(((CFrameWnd *)AfxGetMainWnd())->GetActiveView()->GetDocument()); Parentheses were not quite correct.
PS: Don't mean to be rude, but this was easy enough for you to fix on your own. I'd suggest you revise your knowledge about casting syntax. If you don't understand what this line of code is doing, please take the time to analyze it --getting help without trying to acquire some expertise on the way won't make you a better programmer.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
RalfPeter wrote:
//get pointer to Document
CSEIDoc *pDoc;
Can you see the problem? You declared a pointer pDoc of the type CSEIDoc, but did not initialize it. Later, you try to access the members of the object the pointer is supposed to point to, but does not, since it has not been made to do so.
Regards,
Rohit Sinha
|
|
|
|
|
RalfPeter wrote:
//get pointer to Document
CSEIDoc *pDoc;
that doesn't get a pointer to your doc. that just declares a pointer (which is filled with random garbage at best). you need to really get the pointer.
it's much nicer to do all your dialog variable setting/getting from the parent (ie. the doc in this case), rather than forcing the dialog to go back to the parent. the first way allows your dialog to be used anywhere (not just from a doc). the second way ties your dialog to the doc forever. maybe that's not an issue here, but in general it's nice to have a dialog that you can reuse.
-c
For men use, if they have an evil turn, to write it in marble:
and whoso doth us a good turn we write it in dust.
-- Sir Thomas More
|
|
|
|
|
when i use that function (AfxGetInstanceHandle())in managed class i got an exception i do not know how to handle it.
how to sue it in managed vc++ code ?
how to sue it in c# code ?
plz help me.
r00d0034@yahoo.com
|
|
|
|
|
I don't know how to maximize app window (I want to have window which will fill whole desktop). I have a MDI application and I'm also not sure which window should be maximized (it sounds stupid, isn't it?), should it be MainFrame? Thanks for any help.
|
|
|
|
|
AfxGetApp()->m_pMainWnd is a pointer to the the window to maximize.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Call AfxGetApp()->m_pMainWnd to get a pointer to the main application window and then call SetWindowPlacement() for the returned pointer.
If you want to keep the existing flags and other things for the window, call GetWindowPlacement() prior to calling SetWindowPlacement() and store the WINDOWPLACEMENT data that you get and then change the showCmd member of the WINDOWPLACEMENT structure.
Regards,
Rohit Sinha
|
|
|
|