C / C++ / MFC

Re: Detecting Server (Socket) Disconnect?

15-Feb-09 3:09

Go back to Beej's networking guid that you were looking at a few days ago - that says this in the section about recv

Wait! recv() can return 0. This can mean only one thing: the remote side has closed the
connection on you! A return value of 0 is recv()'s way of letting you know this has occurred.

[edit]I'd modify the ClientSocket class to do something like throw an exception on getting a return value of zero from recv.[/edit]

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

gvanto16-Feb-09 17:26

gvanto

16-Feb-09 17:26

Thanks alot, think the recv() == 0 should do the trick.

I've set it up to be reconnecting every somany seconds, when it does it keeps listening.

Many thanks again guys,

onto threads now! Smile | :)

(multiple clientsockets within class)

Find Your Dream Job in Australia, Free!
http://www.WebCV.com.au

Re: Detecting Server (Socket) Disconnect?

Eytukan15-Feb-09 5:48

Eytukan

15-Feb-09 5:48

It simply sucks to go through the junk. Please remove it.

Also, to answer your question, based on my guess, I think you are not talking about a natural disconnect between server & client. TCP is connection oriented, when one breaks it , you should get an exception. But there's one exception, when there's a slight network disruption, the server actually loses it's connection with client, but it acts to be there alive. The client gets notified but the server don't. even the send function wouldn't convey us anything.That's a problem. There we need to set up a ping mechanism. The server asks "Are you all alive".. the clients say "Yes we are". If few client's don't say, they are actually out. We need to remove them from association with server.

I don't remember the scenario so clearly. I did these long before. I'm not sure If I'm right :P. A couple of years before I replied to the same question with a more vivid answer. lol memory's fading. Sigh | :sigh:

OK,. what country just started work for the day ? The ASP.NET forum is flooded with retarded questions. -Christian Graus

Best wishes to Rexx[^]

error MIDL2020 : error generating type library : SaveAllChanges Failed :

pandit8415-Feb-09 0:19

pandit84

15-Feb-09 0:19

Please tell me what will the cause for this.
i have checked the path for MIDL compiler also. Please help

Re: error MIDL2020 : error generating type library : SaveAllChanges Failed :

Nuri Ismail15-Feb-09 0:49

Nuri Ismail

15-Feb-09 0:49

This error can occur in many cases:

- The type library could not be generated. One possible cause of this error is specifying a path to the IDL file that is longer than 126 characters. Oleaut32.dll does not support path names longer than 126 characters.

- Another way to get this message is to have the .tlb file write-protected, as you do when you use a code management tool...

I think that you first have to check your .tlb files if you use some code management tool

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

pandit8414-Feb-09 23:18

pandit84

14-Feb-09 23:18

I am getting an error as said in the subject line . I know this is because i am porting my code from VC 6.0 to .NET 2005. But dont know how to troubleshoot this problem. Can you please tell me is there any setting required for this ...because my other adddins are building properly except for one i am getting such an error.

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

Stuart Dootson14-Feb-09 23:25

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

Re: CEditView // Displaying text

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