|
I forgot to say thank YOU
so THANKS
|
|
|
|
|
First, try using a debugger, it really makes finding bugs a LOT easier.
Next, check the code:
else
mi = mi;
When you get a match, lo and hi are not getting changed and thus you test the same index over and over again. Instead of "mi=mi", you should have a break statement there to get you out of the loop.
Tim Smith
Descartes Systems Sciences, Inc.
|
|
|
|
|
class A{
public:
int m_var;
A(){
m_var=0;
};
}
class B{
public:
A m_var2; //I want to know where the class A's struct function can be execute? thanks!
}
|
|
|
|
|
The constructor is called before B's constructor, so if it took an argument, you could not do this:
class A{
public:
A(int n){ m_n = n;};
etc.....
class B{
public:
A m_var2;
A()
{
m_var2(7);
}
You'd need to do this in your cpp file:
A::A() : m_var2(7)
{
}
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.
|
|
|
|
|
the Server end send 3 times, while one recv in Client CAsyncSocket will get all 3 packets, why?
one is the other who absorbs the thoughts of others
|
|
|
|
|
Sounds like you are using UDP. Since UDP is packet based instead of stream like TCP, a recv will return only 1 packet at a time.
Tim Smith
Descartes Systems Sciences, Inc.
|
|
|
|
|
no, i am using TCP
the snippet is here
BOOL bOK=pSock->Create();
if(bOK)
{
pSock->AsyncSelect(FD_READ | FD_WRITE | FD_CLOSE | FD_CONNECT | FD_OOB);
retcode=pSock->Connect(m_host,m_port) ;
one is the other who absorbs the thoughts of others
|
|
|
|
|
TCP is a stream based protocol, there's no relation between the number of send() calls at one end of connection and recv() calls at the other end. The network is free to split or merge "packets" as long as all bytes get transmitted and the ordering stays correct.
|
|
|
|
|
when i used the class, it recves 3 packets all in one buffer, for example:
if the server send 1) "aaa" 2)"bbb" 3) "ccc" each time,
then the client should first recv "aaa" when recv next time it should be "bbb" then "ccc".
but in my program, it recves "aaabbbccc" in the recv buffer if the buffer large enough to hold them.
so I suppose the class has some problems.
which when workes properly should recv once the packet arrives.
if one server sends 3 times, then another client should recv 3 times accordingly.
one is the other who absorbs the thoughts of others
|
|
|
|
|
The class is working fine. As markuk pointed out, TCP/IP is a stream based protocol, and not packet based.
In practical terms, what this means is that you will not receive packets in the client but bytes. Theoretically, in your example you could even receive 1 byte at a time (agreed that it is unlikely), but by calling recv repeatedly you will eventually receive all of the bytes that you sent, and in the same order.
So, whether the server sends "aaa" followed by "bbb" followed by "ccc", TCP/IP will treat it exactly the same as if it had sent each letter individually as "a","a","a","b","b","b","c","c","c" or even all together as "aaabbbccc". These are NOT indivdual packets but just bytes within the stream.
What you need, as a very simple solution, is to place a 'framing' character within the stream that indicates the end of each individual message. For example, write a zero into the stream after each message. You will have to modify the client to break the stream back into messages by scanning for these zero bytes. Don't forget that TCP/IP will only give the client the part of the message that has so far been received - sometimes you will have to wait for the zero byte to arrive.
Hope this helps.... Good luck with your code 
Dhar
|
|
|
|
|
I tend to treat a TCP stream just like you treat a record/segment-based file. The stream is a series of segments, each segment should contain a header on it.
The segment header contains information about the segment you are reading -- most importantly the size of the segment. I also tend to mark each header with a 'signature' marker too.
struct segmentHeader
{
WORD m_Signature;
WORD m_SegmentSize;
}
So, as you read the incoming TCP stream, you read a chunk of data (which may be a partial segment, or a bunch of segments) and given what you know about your stream format, you can act accordingly.
What am I trying to say here -- well, the gist is this: Treat a TCP connection just like a flakey file connection. Make sure that the data which you feed into the stream has a defined 'format' which can be recognized at the other end of the connection.
|
|
|
|
|
k here is my problem
print a table of decimal, binary, octal, and hexadecimal equivalents
this is supposed to be programmed in c not c++
graceful gal
|
|
|
|
|
Why does it need to be in C ? IOStreams would do this for you pretty much for free. Is it an assignment ?
I believe sprintf allows you to specify what base a number is, I'm guessing that's what you should use.
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.
|
|
|
|
|
Are you supposed to do the coversion and write a routine yourself?
because you can use printf which is in the C runtine library. It has conversions for all but binary, and that is simple enough.
Construct your string like this:
char string[100];
int x = 16;
printf(string, "decimal = %d, octal = %o, hexidecimal = %x", d, d, d);
|
|
|
|
|
If you actually need to write the code yourself to convert the number formats, did you see the new article on number conversion today?
|
|
|
|
|
char szData [32];
long lValue = 40;
ltoa (lValue, szData, 8);
ltoa (lValue, szData, 10);
ltoa (lValue, szData, 16);
Tim Smith
Descartes Systems Sciences, Inc.
|
|
|
|
|
Hi everyone. I have a few buttons on a dialog, and when the window resizes, I want the buttons to stay at a fixed distance from the bottom of the dialog window's client area.
<br />
CRect rect;<br />
GetClientRect(rect);<br />
rect.bottom -= 40<br />
GetDlgItem(IDC_BTN_ADDITEM)->MoveWindow(rect);<br />
I even tried making the button a variable, and tried doing m_btnAddItem.MoveWindow(rect), and it also caused the same assertion.
When the code executes, I get an assertion error in winocc.cpp, line 279, below
<br />
void CWnd::MoveWindow(int x, int y, int nWidth, int nHeight, BOOL bRepaint)<br />
{<br />
ASSERT(::IsWindow(m_hWnd));<br />
...<br />
}<br />
<br />
Can anyone tell me the proper way to move the control, so it does not assert? Thanks in advance!
|
|
|
|
|
On which function of your dialog is this code inserted?
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
|
You're calling MoveWindow before it has an h_Wnd
try this;
<br />
if(GetDlgItem(IDC_BTNADDITEM)->m_hWnd)<br />
MoveWindow(rect);<br />
|
|
|
|
|
Sorry, I meant for it to be this:
if(::IsWindow(GetDlgItem(IDC_BTNADDITEM)->m_hWnd))
MoveWindow(rect, TRUE);
Are you calling it from OnSize? I did this in my own code, and when it is resized when it is initially displaying it, I guess it doesn't have an m_hWnd. If it still doesn't work, use class wizard to create a class for it (control class) then use that to get the m_hWnd
Josh
|
|
|
|
|
That worked, thanks! I just had to change m_hWnd to GetSafeHwnd(), it causes an access violation if you use m_hWnd.
This brings up another question. I am resizing in the code below, which does center the button horozontally and keeps the button at the same place vertically.
<br />
CRect rect;<br />
<br />
rect.left = cx - (415 + 102);<br />
rect.right = rect.left + 40;<br />
rect.bottom = cy - 40;<br />
rect.top = rect.bottom - 14;<br />
<br />
if(::IsWindow(GetDlgItem(IDC_BTN_ADD)->GetSafeHwnd()))<br />
GetDlgItem(IDC_BTN_ADD)->MoveWindow(rect, TRUE);<br />
In the code above, I specify 40 to be the width of the button, and the 14 to be the height. But when the button is drawn, the button appears to be 10 in height, if it were drawn in the resource editor, and the width appears to be about 25. Is there way to adjust this, so the button appears like it would in the resource editor, that is, with a height of 10 and a width of 40?
|
|
|
|
|
For grins, try using the other version of MoveWindow() and specify the width and height in the parameters, and seee if that works.
Josh
|
|
|
|
|
I tried it, and it still produced buttons which are too small. At the risk fo sounding dumb (which isn't uncommon for me  ) I always assumed that the resource editor and code functions all used the same units (pixels). If they are not the same, is there a formula or ratio to convert resource editor units to code units, so to speak?
|
|
|
|
|
May be try this
GetDlgItem(IDC_BTN_ADDITEM)->ShowWindow(SW_HIDE);
GetDlgItem(IDC_BTN_ADDITEM)->MoveWindow(rect);
GetDlgItem(IDC_BTN_ADDITEM)->ShowWindow(SW_SHOW);
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
