|
You should question any design that entails objects being cast from void*. In general it's just plain bad.
But, that's just my opinion... I could be wrong.
|
|
|
|
|
Hi, i've got the following line in my app:
printf("Press Enter to continue\n");
...
clrscr();
i want to display the message until the user presses enter and then clear the screen.
what command should i use for that?
I need only ANSI C commands
i remember that in pascal you can use
readln;
thanks!
|
|
|
|
|
How about:
do
{
printf(...);
} while (getch() != 0xa);
clrscr();
"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen
|
|
|
|
|
#include <conio.h>
getch();
getch will wait until any key is pressed - test the return for
'\n' if you want the enter key.
do
{
ret = getch()
}
while (ret != '\n');
Dave
|
|
|
|
|
I cannot get specific dates to go bold in the DateTimeCtrl. I want to specify which days are bolded in the popup calendar. I do the following:
OnDropdownDateTimePicker(...)
{
CMonthCalCtrl * cal = m_ctrlDTP.GetMonthCalCtrl();
MONTHDAYSTATE *md;
short len;
SYSTEMTIME tFrom, tTo;
if (cal)
{
cal->ModifyStyle(0, MCS_DAYSTATE); // change style to allow daystates
len = cal->GetMonthRange(&tFrom, &tTo, GMR_DAYSTATE);
md = new MONTHDAYSTATE [len];
memset(md, 0, sizeof(MONTHDAYSTATE) * len);
BOLDDAY(ms[0], 1); // MS macro to set day 1 of first month bold
cal->SetDayState(len, ms);
}
}
and nothing happens.
Anybody know what I am missing? 
Thanks
Dave
|
|
|
|
|
DRHuff wrote:
Anybody know what I am missing?
Per MSDN:
After creating the control, you can change all of the styles except for MCS_DAYSTATE and MCS_MULTISELECT. To change these styles, you will need to destroy the existing control and create a new one that has the desired styles.
"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen
|
|
|
|
|
Thanks.
I missed that completely.
Dave
|
|
|
|
|
How do I stop VC from removing NULLs from my string. I have to have nulls filling up 53 bytes before the begining of my message header...is there a way to stop VC from removing these when I send the packet over TCP/IP?
Thanks
Tom Wright
tawright915@yahoo.com
|
|
|
|
|
Without seeing the code that is "removing NULLs from my string", any answer would be a guess at best.
"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen
|
|
|
|
|
Here is my code snippet:
<br />
char sHeader1[54]={"\x00"};<br />
CString sHeader2;<br />
sHeader2.Format("%s rest of message header here", sHeader1);<br />
m_sConnectSocket.Send((LPCTSTR)sHeader2, sizeof(sHeader2));<br />
return 1;<br />
When I look at the packet on the other end, I do not see the nulls. It looks as though it removing them. This there a way to stop VC from doing this?
Thanks
Tom Wright
tawright915@yahoo.com
|
|
|
|
|
Try this :
<br />
<br />
char message[128];<br />
memset( message, 0, sizeof( message ) );<br />
strcpy( &message[53], " rest of message header here" );<br />
m_sConnectSocket.Send( message, 81 );<br />
<br />
__________________________________________
a two cent stamp short of going postal.
|
|
|
|
|
Nope. It seems that as soon as the socket sees those nulls it stops sending. If i send the message like you suggest I get nothing. But if I take out the memset (nulls) and send the string....it sends it.
I'm thinking that the people that made up this custom packet, are missing something.
Could this have anything to do with me passing data from a PC to a main frame?
This packet is based on the DMPP-2020 Message Layout.
Thanks for the help
Tom Wright
tawright915@yahoo.com
|
|
|
|
|
Tom Wright wrote:
m_sConnectSocket.Send((LPCTSTR)sHeader2, sizeof(sHeader2));
Why are you only sending 4 bytes?
"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen
|
|
|
|
|
Sorry your right. After sending I only get 4 bytes...but still not the leading nulls.
This has really got me puzzled.
Tom Wright
tawright915@yahoo.com
|
|
|
|
|
Let's test another theory. Initialize sHeader1 to something besides '\0', like 'A'. What does that produce on the receiving end?
"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen
|
|
|
|
|
Okay, if I setup my string like this:
<br />
char sHeader1[53]={"A"};<br />
CString sHeader2;<br />
sHeader2.Format("%s rest of my message here", sHeader1);<br />
m_sConnectSocket.Send((LPCTSTR)sHeader2, strlen(sHeader2));<br />
I get this:
A rest of my message here
If I change my code to this:
char message[128];<br />
memset( message, 41, sizeof( message ) );<br />
strcpy( &message[53], " rest of message header here" );<br />
m_sConnectSocket.Send( message, 128 );<br />
I get this:
))))))))))))))))))))))))))))))))))))))))))))))))))))) rest of message header here
Now I know that the )'s are supposed to be A's I think I put in the wrong number for A.
So I replaced 41 with 0 and I got nothing.
I'm thinking that I cannot send anything with leading nulls....which if you think about it, is right....how would the system know the end of one packet and the beginning of another is it did not reference nulls as the end or beginning of something.
Tom Wright
tawright915@yahoo.com
|
|
|
|
|
That is never going to work because CString holds a C-style string. C-style strings, by definition, cannot contain embedded 0 characters because the first 0 marks the end of the string. CString is just the wrong class to use in this case.
Also consider what happens when Format() goes to insert the sHeader array in place of the %s. Again, %s means a C-style string, so it looks at sHeader1, sees that the first character is 0, and stops because that's the end of the string.
--Mike--
Personal stuff:: Ericahist | Homepage
Shareware stuff:: 1ClickPicGrabber | RightClick-Encrypt
CP stuff:: CP SearchBar v2.0.2 | C++ Forum FAQ
----
You cannot stop me with paramecium alone!
|
|
|
|
|
So is there a way to send leading nulls? Or is this a loosing battle?
This mesage layout is based on the DMPP-2020 layout...which is a packet coming from a PC and going to a mainframe. Do mainframes allow leading nulls?
Thanks
Tom Wright
tawright915@yahoo.com
|
|
|
|
|
I'd just do two separate send calls, one for the block of 0s, then another for the text string. If you have to do it in one send call, you'll need to allocate a BYTE buffer of the right size and fill it in with the 0s and the string.
--Mike--
Personal stuff:: Ericahist | Homepage
Shareware stuff:: 1ClickPicGrabber | RightClick-Encrypt
CP stuff:: CP SearchBar v2.0.2 | C++ Forum FAQ
----
Pinky, are you pondering what I'm pondering?
I think so Brain, but if we shaved our heads, we'd look like weasels!
|
|
|
|
|
Michael one last question. If I setup this BYTE buffer and set my string like I want it, will it loose those nulls when I retype it as an LPCTSTR in my Send() method?
The MSDN says:
Pointer to a constant null-terminated string of 8-bit Windows (ANSI) characters. For more information, see Character Sets Used By Fonts.
This type is declared in Winnt.h as follows:
Thanks again for all the help
Tom Wright
tawright915@yahoo.com
|
|
|
|
|
How are you inspecting the packet received? Could it be that your inspection mechanism gets fooled by leading nulls (like for instance if it dumps the packets to the console like they were C-style strings), but these are actually transmitted?
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Good point I'll step thru my code and see what's being sent before it's sent.
Tom Wright
tawright915@yahoo.com
|
|
|
|
|
As far as I can think, the closest solution should be replacing those null's with some other characters those otherwise will never be used in your application, for example, if your sure you'll never use the character '#', then:
#define THE_HEADER _T("###...##")
CString sPacket = CString(THE_HEADER) + _T("your real contents");
socket.Send((LPCVOID)(LPCTSTR)sPacket, sPacket.GetLength() * sizeof(TCHAR));
TCHAR szReceived[1024] = _T("");
receiver.Receive((LPVOID)szReceived, 1023);
for (int i = 0; szReceived[i]; i++)
{
if (szReceived[i] == _T('#'))
szReceived[i] = _T('\0');
}
|
|
|
|
|
Neither the Send function nor the corresponding Receive function strip out any characters from the buffer (nulls or otherwise). The Send function does not care what type of data you are sending. It takes a void pointer as a parameter. The data you send does not even have to be text. I send binary data over a socket all the time.
If it helps think of your final send and receive buffers as a block of miscellaneous bytes. It can be a string, a structure, random bytes, whatever. The length value is the number of bytes in the buffer to send. This is not necessarily the same as the number of characters in the string.
There is no need to replace the NULLs with another character unless that is more convenient for the receiving side.
A couple questions to ask:
What does the spec call for? 53 bytes of 0 followed by a variable length string? Is the string null terminated as well? Must the string be ASCII encoded? Can it be Unicode? This is important because the CString type will change depending on how the program is compiled. So, it's usually better to be more specific by using CStringA or a char array.
Another thing to consider is how much data you plan to send? If there are a lot of Send calls in a row, Send can fail as there is no more room in the internal buffer. Then you have to wait and resend the data. And that may not be all of the data either as Send can send part of your data (whatever fills up the buffer). It will always send bytes in the order passed to it, though.
Any way, yet another simple Send example (assumes ASCII bytes and variable null terminated string):
This version is done with two calls to send. In a low-load app, there won't be much of a performance difference between one call and two calls to send. You can replace the const char pointer with CStringA and lstrlen with GetLength if desired.
int SendStringWithLeadingNulls( CAsyncSocket &SendSocket, const char *Str )
{
BYTE NullBuffer[53] = {'\0'};
int BytesSent;
BytesSent = SendSocket.Send( NullBuffer, sizeof(NullBuffer) );
if( BytesSent < sizeof(NullBuffer) )
return(BytesSent);
return( SendSocket.Send( Str, lstrlen(Str)+1 ) );
}
When receiving, examine the buffer as a byte array and not a string and you will see the leading bytes.
BYTE Buffer[1024];
int BytesReceived;
CString Str;
BytesReceived = ReceiveSocket.Receive( Buffer, sizeof(Buffer) );
if( BytesReceived > 53 )
Str = (char *) (Buffer + 53);
|
|
|
|
|
Tom Wright wrote:
So is there a way to send leading nulls? Or is this a loosing battle?
NO! This is done all the time.
Tom Wright wrote:
Sorry your right. After sending I only get 4 bytes...but still not the leading nulls.
This has really got me puzzled.
That is because you don't understand C/C++ strings. They are never going to have leading NULLs since all string library functions interpret the first NULL byte as the END OF THE STRING.
Tom Wright wrote:
I'm thinking that I cannot send anything with leading nulls....which if you think about it, is right....how would the system know the end of one packet and the beginning of another is it did not reference nulls as the end or beginning of something.
Absolutly WRONG!
Tom Wright wrote:
and I got nothing.
Tom Wright wrote:
When I look at the packet on the other end,
How do you know what you got? I thought you sent it to a mainframe?
Tom Wright wrote:
Here is my code snippet:
First we don't know what m_sConnectSocket is?
If we assume it's send() method is equivalent to the socket API send() then Tom you need to get this. send() only knows about the type byte. You give it the starting address of the memory block of bytes you want it to send and the number of bytes to send. It will either send all of them or none or some of them. The return value is the exact number of bytes sent or an error indicator. Are you checking the return value?
So to sum up if you call send( someAddress, 128) and the return value is 128 then the stack sent the 128 bytes of data starting at the address "someAddress" it does not care what freakin values are in those bytes, period. Please respond in the affermative if you understand this.
Tom Wright wrote:
Do mainframes allow leading nulls?
Well if they don't then why would you have a specification to send it leading nulls? 
Watch out! I'm a CPian on the edge!
I have a new Gold rating and I'm not afraid to use it! -pete
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
