C / C++ / MFC

Re: fatal error C1189: #error : This add-in is for VC++ 6.0 only

14-Feb-09 23:25

Sounds to me like the add-in is verifying that it's being built for VC++ 6. If you're porting the add-in to VC2005, then you need to remove that line as part of the porting process...

But if it's really that tied to VC++6, you're going to have real problems porting it to VC2005, as the add-in model's changed big time between the two versions, I think.

Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

pandit8414-Feb-09 23:39

pandit84

14-Feb-09 23:39

yes that adding was built for VC++6.0.. that code is of CPPUnit for making the Unit Test script for new feature development.
Now i have "Batch Builded" my framwork of CPPUnit. The error in subject line doesnt occurs instead a new one is generated like this

"Error 44 error PRJ0019: A tool returned an error code from "duplicating DLL to lib directory" DSPlugIn"

Error 43 Could not delete file 'd:\CPPUnit\cppunit-1.12.1\src\msvc6\DSPlugIn\TestRunnerDSPlugin.tlb'.
Make sure that the file is not open by another process and is not write-protected. DSPlugIn

kindly provide the comments so that i can resolve the issue..

Thanks

Re: fatal error C1189: #error : This add-in is for VC++ 6.0 only

Stuart Dootson15-Feb-09 0:39

15-Feb-09 0:39

Sounds like you have the addin open somewhere - are you using VC6 with the CppUnit at the same time?

Also - things I've read (including the source-code - src\msvc6\testrunner\MsDevCallerListCtrl.cpp in the latest source tarball) imply that no add-in is required for Visual Studio later than VC6. The add-in is used to support jumping to source code when double-clicking on an error in the MFC test runner, something that can be accomplished without the plug-in for later Visual Studio editions.

Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

CEditView

grassrootkit14-Feb-09 22:44

14-Feb-09 22:44

I created an MFC application for SDI. And after everything, I changed the inheritance of my CMyCview class to CEdit View. Compiled, but when I try to execute the application I get an assertion in

void CEditView::OnPrepareDC(CDC* pDC, CPrintInfo* pInfo)

What are the other things I should do to make my SDI work like a notepad?

grassrootkit14-Feb-09 22:56

14-Feb-09 22:56

Ok.. I found and replaced all CViews with CEditView. And it's not asserting now. Is it a right way? If it's possible for you to say the sequence of steps I need to do to create a notepad app?

I will have a separate class to read/write to a given file path.

On Opening a document, I read the text and keep it in a variable.

In the OnDraw() function in the view, I keep "SetWindowText()" that read content.

Are these enough for a read operation?

Stuart Dootson14-Feb-09 23:13

14-Feb-09 23:13

grassrootkit wrote:
Ok.. I found and replaced all CViews with CEditView. And it's not asserting now. Is it a right way?

Yeah, that should now be correctly deriving from CEditView.

grassrootkit wrote:
I will have a separate class to read/write to a given file path.

grassrootkit wrote:
On Opening a document, I read the text and keep it in a variable

You should have read/write operations as methods of your document class, and store the text in a member variable of an instance of your document class (presuming you're using the document/view bits of MFC).

grassrootkit wrote:
In the OnDraw() function in the view, I keep "SetWindowText()" that read content

You should probably do that in the OnUpdate handler - that should get called when the document is updated, by the document calling its UpdateAllViews method (that's part of CView).

The idea of the doc/view stuff is for you to put operations affecting the document in your document class, operations affecting the view in your view class, to get separation of concerns.

Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

grassrootkit15-Feb-09 0:50

15-Feb-09 0:50

Thanks for your replies again. I've done those changes you suggested. Now the reading part moved to document. but I'm still calling the document's reading functions from the view. Is that ok? Please find below ,In the CmyCView::OnOpen function,

<br />
CmyCView::OnOpen()<br />
{<br />
  CFileDialog dlg(TRUE,NULL,NULL,NULL,szFilter);<br />
  CSDITestDoc* pDoc = GetDocument();<br />
  if (dlg.DoModal() == IDOK)<br />
  {<br />
	pDoc->readFile((LPCTSTR)dlg.GetPathName());<br />
  }<br />
	CString str = pDoc->getText().c_str();<br />
	CEdit& ced = GetEditCtrl();<br />
	ced.SetWindowTextA(str);<br />
}<br />

So far so good, some queries regarding the below comment:

Stuart Dootson wrote:
You should probably do that in the OnUpdate handler - that should get called when the document is updated, by the document calling its UpdateAllViews method (that's part of CView).

The only interface between the user & the document object(here a text content) is the CEditview, where the user modifies the text and when he saves, it's going be View->to->Doc. And it's going to be one way. Where does your comment fit in? I can't get the picture.. How does the document get modified by itself so that it updates the view from there? May be you are talking about multiple view?

Question No 2:
I guessed about a scenario where , as you said the document gets modified from an external window, may be another dialog. So added a dialog. Now I dont have any clue how do I get the document pointer into my Dialog? looks like I'm on the other end of the river..

Stuart Dootson15-Feb-09 3:01

15-Feb-09 3:01

I've just created a tiny MFC SDI app (using VS2008) to test this out.

To hold the text you're editting, I added a member to my document class, plus an accessor function.

public:
   CString const& GetText() const { return text_; }
protected:
   CString text_;

To read/write a file, I added functionality to the document's Serialize method:

void CdddDoc::Serialize(CArchive& ar)
{
   if (ar.IsStoring())
   {
      ar.Write(text_, text_.GetLength());
   }
   else
   {
      const UINT fileSize = (UINT)ar.GetFile()->GetLength();
      CStringT<char, StrTraitMFC_DLL<char> > byteString;
      ar.Read(byteString.GetBufferSetLength(fileSize), fileSize);
      text_ = byteString;
      UpdateAllViews(0);
   }
}

The byteString stuff is because I had a file with ASCII text, while my app is Unicode, so I need to read the file into a 'byte per char' string and then convert to the standard CString.

Then I added an OnUpdate handler to my view, to set the view's text:

void CdddView::OnUpdate(CView* /*pSender*/, LPARAM /*lHint*/, CObject* /*pHint*/)
{
   SetWindowText(GetDocument()->GetText());
}

To update the document in line with the edit view, I'd add a method to the document class that would allow me to update the text somehow.

So, as you can see, by complying with the standard MFC doc/view framework, I've got plenty of functionality for very little effort!

Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

grassrootkit15-Feb-09 5:34

15-Feb-09 5:34

Thanks a lot for the sample.. I'll try the same in my application.

grassrootkit15-Feb-09 22:31

15-Feb-09 22:31

Hi Stuart, I've put the logic in ::Serialize function. But how will I connect this function in "Open New file". The control flow is a bit unclear.

When I open a document, the first function that gets called is the below one.

The void CMyTestView::OnFileOpen()
{
 ..

}

Also in the document class, I've got,

BOOL CMyTestDoc::OnOpenDocument()
{
	return TRUE;
}

Where should we call the ::Serialize() function?.

When I open a new file, what the functions happens/I should call. Can you please..just type down the function names. I'll figure out and end the conversation.

Like,

Open A new document:

1.
void CMyTestView::OnFileOpen()
{
   //Load the file path of the selected file.
}

2.
BOOL CSDITestDoc::OnOpenDocument()
{
    return true;
    //Call Serialize()
}

3.
void CSDITestDoc::Serialize(CArchive& ar)
{
 // read the file
 //Update view.
}

Stuart Dootson15-Feb-09 23:30

15-Feb-09 23:30

As I've said in my other reply - I think you should probably leave handling OnFileOpen to CWinApp, a) because it fits better with the model of responsibilities and collaborations the MFC doc/view framework was designed around, and b) it fits with MFC, so you don't need to write as much code!

Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

grassrootkit15-Feb-09 22:54

15-Feb-09 22:54

I got a nice example diagram :
http://www.informit.com/content/images/bok_0672312417/elementLinks/09fig06.gif[^]

But shouldn't that be view's OnFileOpen? It shows as CWinApp::OnFileOpen?

Stuart Dootson15-Feb-09 23:26

15-Feb-09 23:26

grassrootkit wrote:
But shouldn't that be view's OnFileOpen

Not necessarily - thanks to the wonders of command routing, OnFileOpen can be handled by many different things.

The best way to look at whether your view should be handling OnFileOpen is to think about what your view's responsibilities are - display a view of the document and feed back user interactions with that view. Document management (which is what opening a file counts as) isn't really the responsibility of the view.

It becomes clearer when you move to MDI, or if you have multiple views on a single document:

An application has zero to many documents
Each document is related to precisely one application, but can have one to many views
Each view is related to precisely one document

HTH!

Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

grassrootkit14-Feb-09 23:00

14-Feb-09 23:00

Why this doesn't write anything on the Edit window?
CEditViews handle things differently from CView?

void CSDITestView::OnDraw(CDC* /*pDC*/)
{
CSDITestDoc* pDoc = GetDocument();
ASSERT_VALID(pDoc);
if (!pDoc)
return;

CString str = "Hello CEditWorld!";
CEdit& ced = GetEditCtrl();
ced.SetWindowTextA(str);
// TODO: add draw code for native data here
}

grassrootkit14-Feb-09 23:11

14-Feb-09 23:11

Damit OnDraw never gets called for CEditViews. Frown | :(

.. Where I can I find a tutorial that clearly talks about a CEditView ? possibly with a notepad example.

Stuart Dootson14-Feb-09 23:17

14-Feb-09 23:17

Google[^] is your friend[^]

Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

grassrootkit14-Feb-09 23:27

CListCtrl "show selection always" doesn't work in vista aero theme

14-Feb-09 23:27

The content in CPP-Home is relatively good. But in all other places, they quickly move on to explain other inherited views. I hate them. I think too few people use SDI,CEdit views in this world Big Grin | :-D

. Thanks a lot for the explanation & link. I'll try to make use of the doc class. And will come back with another set of questions. Smile | :)

xanagan66614-Feb-09 21:05

xanagan666

14-Feb-09 21:05

I just noticed that when running my application on vista with vista theme (aero glass on or off)
my CListCtrl doesnt hightlight the last selection item before it lost focus
even thought I enable "show selection always".

It still work when vista is set to use classsic style.

Is there any way to make "show selection always" work with vista theme with out custom draw the control myself ?

Re: CListCtrl "show selection always" doesn't work in vista aero theme

Stuart Dootson14-Feb-09 23:14

Re: 871127 - intellisense

14-Feb-09 23:14

It probably is shown, but not very obviously. I've found previously that when a list loses focus, the selection is shown as very light grey, rather than the blue shading that's normally used.

Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

871127 - intellisense

ilostmyid214-Feb-09 17:30

ilostmyid2

14-Feb-09 17:30

hi in visual studio 2005, i need to know whether a macro is defined when intellisense is processing the source so that i may distinguish between when the compiler is parsing the source code and when the intellisense is reading and processing it.
how it be useful? i need not to limit definitions of classes, variables, etc. for intellisense. although they may not be met sometimes when they're compiled, i need intellisense to meet them everytime. since there's only one definition of everything, there will be no conflict.
i hope i could describe what i'm looking for properly.
any idea?

Stuart Dootson14-Feb-09 23:20