C / C++ / MFC

Selecting A Directory - Common Dialogs

4-Feb-02 2:27

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

Re: activex controls

Jon Hulatt4-Feb-02 4:35

Jon Hulatt

4-Feb-02 4:35

did you compile in Release mode?

Sorry to dissapoint you all with my lack of a witty or poignant signature.

Process Memory

StuartHall4-Feb-02 0:42

StuartHall

4-Feb-02 0:42

Hi,

Can anybody tell me the equivalent of GetProcessMemoryInfo for Windows 98?

Thanks Eek! | :eek:

AJ1234-Feb-02 0:04

AJ123

4-Feb-02 0:04

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

Re: Selecting A Directory - Common Dialogs

Christian Graus4-Feb-02 0:04

Christian Graus

4-Feb-02 0:04

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

Expoert advice on MFC TCP/IP sockets, please?

Peter Sjöström3-Feb-02 23:31

Peter Sjöström

3-Feb-02 23:31

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?

Joaquín M López Muñoz3-Feb-02 23:51

3-Feb-02 23:51

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

Peter Sjöström3-Feb-02 23:59

Peter Sjöström

3-Feb-02 23:59

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.

4-Feb-02 0:45

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

4-Feb-02 1:04

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! Wink | ;)

Peter Sjöström4-Feb-02 1:25

Peter Sjöström

4-Feb-02 1:25

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).

markkuk4-Feb-02 1:46

markkuk

4-Feb-02 1:46

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.

Jay Beckert5-Feb-02 11:14

Jay Beckert

5-Feb-02 11:14

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.

scrolling

Chagit3-Feb-02 23:13

Chagit

3-Feb-02 23:13

How can I scroll down the html page, by vc++ code?

Confused | :confused:

Thank you

Chagit

How this is working?

3-Feb-02 22:50

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);
}

};

Re: How this is working?

Paul M Watt3-Feb-02 23:13

Paul M Watt

3-Feb-02 23:13

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

NikoTanghe3-Feb-02 22:19

NikoTanghe

3-Feb-02 22:19

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
}

Joaquín M López Muñoz3-Feb-02 23:37

3-Feb-02 23:37

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

NikoTanghe4-Feb-02 0:13

NikoTanghe

4-Feb-02 0:13

No, no UpdateData(), should it make a difference ?
The assert only occurs when accessing the pointer from the DLL.

Joaquín M López Muñoz4-Feb-02 0:21

4-Feb-02 0:21

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