|
It could have to do with licensing issues (machines with VC++ installed do not have these problems as the IDE comes with a "developing license"). This article I found in Usenet might be helpful to you.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
did you compile in Release mode?
Sorry to dissapoint you all with my lack of a witty or poignant signature.
|
|
|
|
|
Hi,
Can anybody tell me the equivalent of GetProcessMemoryInfo for Windows 98?
Thanks
|
|
|
|
|
Hi,
I want to provide a facility to select a directory. Been looking at CFileDialog but there doesn't seem to be anything to aid me.
Anyone any bright ideas?
Cheers
Rich
|
|
|
|
|
SHBrowseForFolder will do it for you.
christian
I have come to clean zee pooollll. - Michael Martin Dec 30, 2001
Picture the daffodil. And while you do that, I'll be over here going through your stuff.
Picture a world without war, without hate. And I can picture us attacking that world, because they would never expect it.
Sonork ID 100.10002:MeanManOzI live in Bob's HungOut now
|
|
|
|
|
I seriously suspect MFC's socket implementation is broken. We have developed commercial software based on the MFC CSocket and CAsyncSocket classes. We've used the MFC examples using CFile and CArchive for communication.
We have separate software using these classes and they all seems to suffer from the same problem: sockets lockup. When it happens communication stops one way until the socket is closed and a new connection is opened.
Anyone here know of any problems in MFC sockets? Will they be solved if we re-write using WinSock, C raw sockets or whatever? What is an expert's advice?
|
|
|
|
|
Warreng Young's article CSocket Considered Harmful strongly discourages the use of MFC socket wrappers. It is hard to know wheter the problems you're experiencing with your app are due to bugs in the implementation of these classes, but you'll be probably better off using raw Winsock sockets (to which the MFC wrappers add little) or some other, better designed, socket library (the Winsock Programmer's FAQ names a few).
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Thanks, I'll read the link.
I doubt we have any bugs. The software's are three years aold and are installed at numerous customers and have been disected over and over again to find these problems. We've reaching a point where we are convinsed it's a Windows/MFC/WinSock problem. We don't suspect network hardware, since it's running on numerous environments using various network cards, routers, switches and configurations. It's also running on both W2000 and NT4 enviroments, sometimes mixed.
|
|
|
|
|
We've been using the MFC CAsyncSocket class for a number of years now, in part of a commercial distributed system. While we have experienced 'broken' code in the past (I think with the release of VC 4.2, there was an error in one the MFC header files, and the Ioctl call didn't work!), everything does seem to work with the current VC 6.
We probably send hundreds of thousands of realtime messages daily, and don't experience any lockups, so I wouldn't immediately suspect MFC.
It isn't easy to diagnose a problem like this from a short message, but I would suggest looking at your socket 'reader' programs. I have in the past had lockups when the 'reader' program had a bug and stopped reading the socket. The TCP buffers then filled up, and the 'writer' was blocked.
I've implemented socket code both using winsock and MFC, and have found the MFC version generally easier to use. Unless you really want to write and manager your own event loop, I would look for the cause of your problem instead. In any case, you might experience the same problem even if you re-write if it is just a 'reader' bug.
Hope this helps...
Dharminder Birdi
|
|
|
|
|
I agree with you. I also have been using the CSocket class extensively in a lot of programs, there were three things that got me in the past:
1. You have to call AfxSocketInit() in each thread you use CSocket.
2. You need a message pump in the thread that uses CSocket if you expect the handlers (such as OnAccept, OnReceive, etc.) to work.
3. You need to check the error code whenever possible and re-establish the connection if necessary.
Other than that, it is great! 
|
|
|
|
|
1. We do this.
2. We use these callbacks
3. We do, including exception handling. What we have done is have parent threads ping the worker threads for alive status. If they are not alive, locked up somehow, first we check IsBlocking() and it is, then we call CancelBlocking() which causes an exception which we then handle and can get out of the locked state.
But because this software is communication intensive, it's used for semi-realtime applications that cannot ever lose connection, this is not a satisfactory solution.
To answer previous poster, we constantly send messages. One application combination uses one message per second one way, plus other communication originating from both sides. Another application sends at least one message per second, plus otehr communication from both sides frequently (every few seconds kByte sized packets).
|
|
|
|
|
Rewrite using WinSock. I tried using MFC CSocket/CFile/CArchive communication in a project about a year ago, suffered mysterious crashes and lockups in testing, and solved all problems by rewriting code with WinSock calls.
|
|
|
|
|
markkuk wrote:
Rewrite using WinSock. I tried using MFC CSocket/CFile/CArchive communication in a project about a year ago, suffered mysterious crashes and lockups in testing, and solved all problems by rewriting code with WinSock calls.
I never had problems with CSocket/CFile/CArchive but I never used it for intensive tasks, just simple text back and forth. Once I tried using it for file transfers it would crash every time. Though not very portable once you send objects through.
I like to convert my projects over to WinSock, just havn't got around to it yet. I would recomend that to others as well.
|
|
|
|
|
How can I scroll down the html page, by vc++ code?
Thank you
Chagit
|
|
|
|
|
Please look at the follwing code.When I create an object a set of memory location is allocated to that object(item).
Though I am calling within a member function of
Class A the data member of item belongs to the Object(item),
not to the Class A. So data member should be protected
from illegal access (being private and encapsulated within item).
This holds true when I create an object Out side class A.(Get an error that
you cannot access private members).But when
I create an object within A I don't get any
error and I can access an objects private members.
#include "stdafx.h"
class A
{
private:
int data;
public:
static void Test()
{
// data is a private member!
A* item = new A();
int j=item->data =100;
printf("\n %d",j);
}
};
|
|
|
|
|
Smith wrote:
class A
{
private:
int data;
public:
static void Test()
{
// data is a private member!
A* item = new A();
int j=item->data =100;
printf("\n %d",j);
}
};
Test is a member function of class A, therefore it has access to all of A's members and member functions.
|
|
|
|
|
Some Code:
//App = SDI
CMyFormView::OnInitialUpdate()
{
//..
//initialise logging
CMainFrame* pMainFrame = (CMainFrame*)AfxGetMainWnd();
//Logging class is an exported class from a dll
//linking is done by making project dependend
pMainFrame->m_Logging.init(&m_RichEditControl,AfxGetResourceHandle());
//fails
pMainFrame->m_Logging.log(IDS_TEST);
//works
m_RichEditControl.SetWindowText("test");
}
bool CLogging::Init(CRichEdit* pRichEdit,HINSTANCE ResourceHandle)
{
//..
AfxSetResourceHandle(ResourceHandle); //to make CString::LoadString() work
m_pRichEdit = pRichEdit;
//..
}
bool CLogging::Log(UINT uID)
{
csString.LoadString(uID);
//..
m_pRichEdit->SetWindowText(csString); //Gives an assert ASSERT(IsWindow()), ptr is valid
}
|
|
|
|
|
Seems that you deleted some code to make your post shorter. Is there any UpdateData(FALSE) between the line failing and the one that works?
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
No, no UpdateData(), should it make a difference ?
The assert only occurs when accessing the pointer from the DLL.
|
|
|
|
|
No, no UpdateData(), should it make a difference?
Yes, it is on the first call to UpdateData that control variables are attached their corresponding HWNDs.
If you can debug into the DLL, try to check how the m_pRichEdit contents look like when the program arrives at the offending line. The fact that the call to SetWindowText is being made inside a DLL should make no difference, as far as I know.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Also, is this code in DLL? So make sure it is MFC Extension DLL and not regular. Things may work (but may not) when you are in debug build, but definately won't work if you in release.
This also can be your problem, that u have a Regular DLL and trying to pass MFC classes as function parameters
Philip Patrick
"Two beer or not two beer?" (Shakesbeer)
Web-site: www.saintopatrick.com
|
|
|
|
|
i have a problem using CRecordset. it return false when i call CanUpdate ().
i want to add new item inside my database but it failed because of this. it seems my database is not in write mode, but in read mode only.
i used sql server for my database. however when i use access file the CanUpdate () return true !
could any body help me. if you don't understand my problem, i can write it again clearly and detail about the problem.
|
|
|
|
|
Check your "Curser type" it must be 'dynaset' or 'dynamic'
Mazy
You can find a solution (even a foolish one) for all problems (even big ones)
|
|
|
|
|
You must define at least one index for your table; without index CanUpdate doesn't work.
By
|
|
|
|
|
How can I compare ".wav" files, by vc++ code?
Thank you
Chagit
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
