 |
On Thu, 3 Jul 2008 04:28:15 -0700 (PDT), Mikel <...@gmail.com
On 3 jul, 13:01, "RB" <NoMail@NoSpam
Well, that's exactly what it is doing, take the head of the list, cast
it to CEditView* and call its SetWindowText.
If you call SetWindowText directly, you are calling the SetWindowText
member of the class you are calling from (or its base class), if it is
CWnd derived or has a SetWindowText. So if you are calling it from,
say, a CDialog derived class, you would be calling
CDialog::SetWindowText (or CMyDialog::SetWindowText if you override
it).
Another option would be to call ::SetWindowText(HWND, LPCTSTR), but
that's WIN32 API, not MFC. That's what MFC does, wrap all those API
calls so that you don't have to get the HWND and call the API (and
much more, of course).
Hope this helps
|
|
On Thu, 03 Jul 2008 08:40:55 -0400, David Wilkinson <...@effisols.com
RB;
the code is equivalent tt
CEditView* pEditView = (CEditView*)m_viewList.GetHead();
pEditView-
which I prefer, actually. The compiler will optimize away the temporary anyway.
Actually, SetWindowText() is a method of CWnd, so the cast should not be necessary.
In fact, though, don't you have to use GetEditCtrl() to get the underlying Edit
control before you call SetWindowText()? Like this
pEditView-
in which case you do need the CEditView cast. Or does CEditView::SetWindowText()
perform some trickery to send the text to the edit control?
--
David Wilkinson
Visual C++ MVP
|
|
On Thu, 03 Jul 2008 10:03:41 -0400, Joseph M. Newcomer <...@flounder.com
Writing a piece of code like this is typically indicative of a serious design error. You
should not be trying to set the text of a view from outside the view, and certainly it
doesn't make sense to be doing something like this.
This is calling SetWindowText on the view, nothing more. Parse it. The result of
m_viewLlist.GetHead() is the first element of a list (and it is not at all clear what
happens if the list is empty). The question then is "what is the type of the list
element?", a little fact you omitted to tell us. I presume it is CView*. So it is cast
to a CEditView*, because only CEditView supports SetWindowText, and the result is the same
as writing
CView * view = m_viewList.GetHead();
CEditView * eview = (CEditView *)view;
eview-
But ultimately it is very questionable as to why a piece of code like this would be
written. I find it a common design error that "if you include enough header files and it
compiles, it must be right" without asking the question "Why do you need to include this
header file?" (For example, the HTML Editor example in the MSDN is the latest example I
have of egregiously poor programming on the part of Microsoft, because it contains exactly
this sort of code)
joe
On Thu, 3 Jul 2008 07:01:28 -0400, "RB" <NoMail@NoSpam
Joseph M. Newcomer [MVP]
email: newc...@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
|
|
On Thu, 3 Jul 2008 12:04:36 -0400, "RB" <NoMail@NoSpam
"Joseph M. Newcomer" wrote in message
The code of previous question came right of out of an MFC generated app for the
OnNewDocument, with Doc/View support and CEditView being the base class. I probably
should have show the whole sequence to eliminate ambiguity. But anyhow if I understand you
correctly then the code is calling
((CEditView*)m_viewList.GetHead()) so as to point to the correct window to set text ?
See this is one of the main areas of my confusion so far. I'm used to dealing with window
handles. I'm still struggling with how to connect with the correct window without a hwnd.
But I think you have helped me along my way with some more practice and printouts
!!! While !!!
I'm here can you guys give me some insight on where I should declare an instance
of a generic class that I created ? Does it matter or should I instance it in the
MainFrame.cpp.? I'm somewhat confused with a WinMain function. If it does not
need global scope then I can instance it where ever I want correct ?
Thanks to all replies, as usual all you all have been a tremendous help to a struggling
learner of C++ and MFC.
|
|
On Thu, 3 Jul 2008 12:47:10 -0400, "Scott McPhillips [MVP]" <org-dot-mvps-at-scottmcp
"RB" <NoMail@NoSpam
In MFC a window is accessed with a pointer to the associated CWnd-derived
object, instead of using window handles. If you peek inside an MFC function
like CWnd::SetWindowText you will see a little one-line function like
::SetWindowText(m_hWnd, ...), so MFC is merely hiding the handle (m_hWnd)
inside a C++ object.
Yes, you can add a generic class anywhere you want. Making it a member of
the CDocument is probably the most common place, because views have easy
access to the associated CDocument. That's the place for "data."
--
Scott McPhillips [VC++ MVP]
|
|
On Thu, 03 Jul 2008 12:53:21 -0400, Joseph M. Newcomer <...@flounder.com
Yes, code like this *would* be found under the hood of MFC, because it has to handle all
kinds of things that users should never be attempting. Code out of context is
unintelligible; we have no idea if it is part of the application, some third-party
library, the MFC implementation, etc. The assumption is that unless you say otherwise it
is code you wrote.
You cannot connect to a window without an HWND. A CWnd* contains an m_hWnd member which
has the HWND.
The HWND is not defined until the Create member is called; so when you have a CWnd
declaration, such as
CEdit stuff;
it has no HWND at all. Eventually, one of two things will happen:
You will call
stuff.Create(...);
to create the window, or someone will call
stuff.Attach(handle_of_some_window);
which will set the m_hWnd member. The above line is what is executed when you do a
DDX_Control call in a DoDataExchange (the result of creating a control member variable)
You need to create the instance at a point where you want the window to be known. The
lifetime of the variable must be at least as long as the desired lifetime of the window,
because when the variable is destructed (CWnd::~CWnd) the DestroyWindow API is called.
So if you do
class MyThingView : public CView {
CEdit c_Name;
then c_Name will exist throughout the lifetime of the view. When the view is destroyed,
the child windows are implicitly destroyed.
If you did
BOOL CMyForm::OnInitDialog()
{
....
CEdit name;
name.Create(...);
... other stuff
}
then when you leave OnInitDialog, the CEdit control is destructed, and the window
disappears in a puff of greasy blue smoke.
It is very rare that you would declare such variables in the main frame or app classes
because they are then not accessible to anyone who needs them. And the "toss #include
directives and casts at the code until it compiles" is not the correct solution. Only the
app-class.cpp file should have access to the app-class.h file, and only the mainfrm.cpp
file should include mainfrm.h. To do otherwise is a serious design error.
WinMain is irrelevant to MFC programmers; it is completely hidden from you and you don't
care about it. THerefore, you would not declare it. THere is no need to declare it, and
declaring it would be an error because you would get multiply-defined symbols.
You would be creating your application using the MFC AppWizard, so none of this is a
concern to you. TYpically, you will not worry about creating windows until you need them,
and that is actually fairly rarely; MFC handles most of this, nearly all the time. You
would have to explain more about why you think you need to create them at all.
joe
On Thu, 3 Jul 2008 12:04:36 -0400, "RB" <NoMail@NoSpam
Joseph M. Newcomer [MVP]
email: newc...@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
|
|
|