|
Aric Green wrote: The problem is that because of a very small size of packets and so a large amount of packets there is a small gap between them...
As well as multiple buffers as suggested above by Covean, you should try to use larger packets, to reduce the amount of unnecessary processing you're doing. Using very small packets will be more likely to cause you problems, as you're experiencing.
Days spent at sea are not deducted from one's alloted span - Phoenician proverb
|
|
|
|
|
Thank you answay!Covean's reply just to the point.I found my fault,thx again!
I am not a genius, but shed more sweat!
|
|
|
|
|
hi
can the tutorial in learn vc++ 21 days about socket programming work without the code related to SetParent(this). I am implementing the same program but not in a dialog or a view class.
thanks
Darshi
|
|
|
|
|
Yes it will work fine until the GetParent() call (i.e. dumb question-dumb answer)... 
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
well u mite think its dumb.
The original code goes like this
void CMySocket::SetParent(CDialog *pWnd)
{
m_pWnd = pWnd;
}
<pre>
I wanna modify it to
void CMySocket::SetParent(CWeigh *pWnd)
{
m_pWnd = pWnd;
}
Weigh is a class created for my program which has no base class. I have made all the declarations correctly. When i add the header file of CWeigh Class to the header file of Socket class i get errors.
Plz help, and hence the question of eliminating SetParent
|
|
|
|
|
OK, things are getting a little better now.
In the original code (you have it, I haven't) the CMySocket::m_pWnd member is possibly a pointer to a CDialog object while you're passing a pointer to CWeight one, hence (probably) the compile errors.
To get better help, you should post, at least, the exact error message and the line of code wherein the error occurs.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
I have included the header file for my weigh class as follows
#include "Weigh.h"
#if !defined(AFX_MYSOCKET_H__57CF680B_2F58_4A22_81FF_1A8C4841E38E__INCLUDED_)
#define AFX_MYSOCKET_H__57CF680B_2F58_4A22_81FF_1A8C4841E38E__INCLUDED_
#if _MSC_VER > 1000
#pragma once
#endif // _MSC_VER > 1000
I have declared the pointer and the setparent class as follows
void SetParent(CWeigh* pWnd);
CWeigh* m_pWnd;
I am getting errors which state
error C2061: syntax error : identifier 'CWeigh'
|
|
|
|
|
It looks like you included Weigh.h inside a header file (usually you include header inside source, i.e. cpp files) and that you've included it before the multiple inclusion guard (the block starting with #if !defined(...), ending with #endif), hence your compilation error may occur because of header multiple inclusion. Do the following change (if you really need to include the header inside the other header... )
#if !defined(AFX_MYSOCKET_H__57CF680B_2F58_4A22_81FF_1A8C4841E38E__INCLUDED_)
#define AFX_MYSOCKET_H__57CF680B_2F58_4A22_81FF_1A8C4841E38E__INCLUDED_
#if _MSC_VER > 1000
#pragma once
#endif // _MSC_VER > 1000
#include "Weigh.h"
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Hi ALL,
Which one is easier to develop a GUI.Is it VC++(MFC) or is it VC++/CLI(i.e.VC++.NET).Please advice.
Thanks,
ashwath.
|
|
|
|
|
I would not use Managed C++ to build a GUI. I would use instead C#. That said, MFC is quite powerful (nothing is really easy when talking about Windows programming).
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Agree that one should not use Managed C++ for building GUI. Managed C++ is mainly for compiling legacy C++ code, where performance is not an issue. Or wrapping native C++ code as standard .NET classes.
I would choose Winforms/C# over MFC/C++.
|
|
|
|
|
Starting from what level of development skills ?
IMO, they are both equivalent, have a look at your requirements and match them to what MFC and .NET (forms) have to offer.
M.
This signature was proudly tested on animals.
|
|
|
|
|
It's also depends a lot on the UI features you want to develop. Could you elaborate a bit on that part ?
|
|
|
|
|
If you have experience in .NET, you could choose .NET because it's easier. I'd personally choose MFC, because I've been using it to build GUI for a while and I find it convenient for my purposes.
“Follow your bliss.” – Joseph Campbell
|
|
|
|
|
Hi expert,
I've experience in Paint, should I use it?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Why not? But, I must warn you that it might take longer than expected.
“Follow your bliss.” – Joseph Campbell
|
|
|
|
|
Well, could always draw in paint the code you want to write, then use OCR to convert it to text and paste it to your compiler, but I'm not so sure that it is the most efficient solution
|
|
|
|
|
I think you should use C# or VC++/CLI, Because MFC is dieing. Fewer and fewer people are using MFC.
modified on Tuesday, January 19, 2010 2:11 PM
|
|
|
|
|
CODEPC wrote: Fewer and fewer people are using MFC.
Which puts me into the fewer and fewer category, I guess.
Maya just doesn't play along well with .NET and most of our applications are written in C++, so there's no point in writing only the UI with .NET. Some may think I'm "stuck" with native language programming, but I'm doing it because I'm liking it.
“Follow your bliss.” – Joseph Campbell
|
|
|
|
|
COBOL death was ruled many many years ago, before you and possibly I (!?!) were born, anyway there are still job openings for COBOL people. 
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
I'm for one glad that COBOL is not the standard requirement for new job positions. Awful language when having tried Java or .NET.
|
|
|
|
|
Who, besides Nish, is using C++/CLI for an actual shipping program? (C++/CLI is one of the biggest pains in the ass I've ever used.)
|
|
|
|
|
There a lot of old applications that still are implemented in MFC. These will not disappear soon, but yes any new GUI applications are usually implemented either as a web-application or using Winforms/WPF.
|
|
|
|
|
If MFC is dying, why do new versions keep being released for each new version of VS [^]?
Steve
_________________
I C(++) therefore I am
|
|
|
|
|
We are changing the style of our MFC app to be the "XP Style" - mainly this was done by setting the manifest using a #pragma comment in stdafx.h.
The problem we have is that edit fields created in Dialogs using the resource editor have a blue border to them, whereas dynamically-created ones have a black border. I had planned to get around this by subclassing CEdit and overriding OnNcPaint() and OnNcCreate().
The OnNcPaint() works fine - as the mouse passes over the entryfield the border colour is changed to the blue as required. However, the field is still initially created with the black border, so I had expected to also need to override OnNcCreate():
BOOL CXPEdit::OnNcCreate(LPCREATESTRUCT lpcs)
{
CEdit::OnNcCreate(lpcs);
OnNcPaint();
return TRUE;
}
However this doesn't seem to work. I do have the "ON_WM_NCCREATE()" and the method is definitely called, it just doesn't repaint the border. I tried adding Invalidate() and UpdateWindow() to no avail.
Any ideas?
Thanks
-M.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
