|
Try:
CString s = "Test";
char* ch = static_cast<char*>(s.GetBuffer(0));
- Nitron
"Those that say a task is impossible shouldn't interrupt the ones who are doing it." - Chinese Proverb
|
|
|
|
|
I tried the following:
CString s = "Test";
char* ch = static_cast<char*>(s.GetBuffer(0)), *test="Test";
int d = ( ch == test);
ch = test;
d = ( ch == test );
the first d is 0 and the second 1. so the arn't really equal
even though they seem so!!!
|
|
|
|
|
citroen wrote:
the first d is 0 and the second 1. so the arn't really equal
even though they seem so!!!
NO! NO! NO!
don't confuse yourself! Read my article on Pointers[^] and you'll see why ch != test. Actually, they'd better not be equal!
Download the demo project, and go over the article. It will hopefully enlighten you! I understand how confusing it can be at first, trust me. 
Let me know what you find out, and tell me why they are not equal.
- Nitron
"Those that say a task is impossible shouldn't interrupt the ones who are doing it." - Chinese Proverb
|
|
|
|
|
First, thanx.
It works.
so they will be equal I should have written:
*ch==*test; to dereference them.
thanx again
Moshe
|
|
|
|
|
citroen wrote:
so they will be equal I should have written:
*ch==*test; to dereference them.
 You are exactly right!
[happy-cry] sniff... sniff... I'm so proud... [/happy-cry]
- Nitron
"Those that say a task is impossible shouldn't interrupt the ones who are doing it." - Chinese Proverb
|
|
|
|
|
|
How can I get application path ?
such as I want to get icq path,acrobat path,...;
How should I do (Howto or Library) ?
Thank you for your kindness.
|
|
|
|
|
The way I solved this was to call GetEnvironmentVariable and ask for the 'path' variable. Here's an MFC code snippet:
<code>
DWORD dwPathLen = GetEnvironmentVariable("path", NULL, 0);
CString csCurrentPath;
DWORD dwPathLenVerify = GetEnvironmentVariable("path",
csCurrentPath.GetBuffer(dwPathLen), dwPathLen);
ASSERT(dwPathLenVerify == (dwPathLen - 1));
csCurrentPath.ReleaseBuffer();</code>
The only MFC thing about it is the GetBuffer call, which you could easily remove.
|
|
|
|
|
I am using winsock application. i am making the client server application. I want to get the ip address and port of the client connecting to my server socket. I am already using the function getpeername() but it is not working please help me.
Reply me soon
|
|
|
|
|
When you do accept, why don't you use the second parameter? read msdn about "WSAAccept" and pay attention to "ATM_CALLING_PARTY_NUMBER_IE" (I suspect that is why your getpeername call fails).
|
|
|
|
|
Thanx 4 guidence but we r simply using simple sockets not ATM based sockets. Is there any other function to get the information(e.g IP,Port no)of the client attached. Can u plz provide us with some helping code for proper understanding as we r beginners.
Reply me soon
|
|
|
|
|
Well, from what I just read this is provider specific.
What network are you using?
What is the error code (see error hadling example MSDN "IPv6-Enabled Client Code")?
|
|
|
|
|
Well I am using LAN(ethernet) with an OS Windows Xp. The exact thing that is happening is when I get the port no by
(getpeername), I receive junk not the exact port no and the junk value changes whenever the program is restarted. U can have a better idea of it by viewing the code. Plz help me out.
getpeername(ClientSock,
(struct sockaddr *) &accept_sin,
(int *) &accept_sin_len);
short x=accept_sin.sin_port;
m_port=x;
UpdateData(false);
MessageBox (x, TEXT("family"), MB_OK);
Reply me soon
|
|
|
|
|
Having not enough info to say directly. But if you accept your sockets through AcceptEx there is only one way how to get the socket info as the getpeername() doesn't work anymore after AcceptEx.
If this is your case, look at the GetAcceptExSockaddrs function, this is a way how to handle it.
|
|
|
|
|
Well I am using "accept" to make connection. The exact thing that is happening is when I get the port no by(getpeername), I receive junk not the exact port no and the junk value changes whenever the program is restarted. U can have a better idea of it by viewing the code. Plz help me out.
getpeername(ClientSock,
(struct sockaddr *) &accept_sin,
(int *) &accept_sin_len);
short x=accept_sin.sin_port;
m_port=x;
UpdateData(false);
MessageBox (x, TEXT("family"), MB_OK);
Reply me soon
|
|
|
|
|
Don't know if this is exact solution for your problem - problem is that in TCP/IP the numbers are in network byte order - this is OK for some big machines, but for Intel you have to switch the order (this is the Little/Big endian problem).
so the code should looks like:
<br />
getpeername( ClientSock, (sockaddr*)&accept_sin, (int*)&accept_sin_len);<br />
<br />
short port = ntohs( accept_sin.sin_port );<br />
...<br />
the same will be later on for the address...
|
|
|
|
|
hi all,
i want to use the version number system
major.minor.patch.build
for my software.
Should i reset the build count to 0 (zero) if i increment the minor or major version ? Or should i just keep the build number as it is ?
I know there are no strict rules. But.. just to be professional...
thanks in advance
Hari Krishnan
|
|
|
|
|
I usually use the date as my build number.
i.e.: v2.1.1.20030115
or you can be crazy and encode the date in hex: v2.1.1.131A2A3 
I usually only embed the build info into the help-->About box.
On a major release, I will reset the minor and patch numbers though
- Nitron
"Those that say a task is impossible shouldn't interrupt the ones who are doing it." - Chinese Proverb
|
|
|
|
|
There are many methods to redraw a window, like Invalidate, UpdateWindow, RedrawWindow ...
Can anyone explain me when to use every method and what they are doing?
Daniel 
---------------------------
Never change a running system!
|
|
|
|
|
UpdateWindow is for window's creation.
Invalidate is asyncronized.
RedrawWindow is syncronized.
includeh10
|
|
|
|
|
Hi all,
I try to use 'DeviceCapabilities' to get supported paper sizes...
Could you please help me to understand how to use 'DeviceCapabilities'
with DC_PAPERNAMES parameter...thank !
|
|
|
|
|
Hi all, I am writing a Backup program in which I want to be able to save files to the rewriteable CDROM drive on another computer. I am intending to use the MS application Direct Cable Connection but don't know how to gain access to the remote drives from within my program. Presumably, the operating system on the local system can "see" the remote drives with a specific pathname that I should be able to use with the CopyFile function. Can anyone enlighten me as to what this is, or failing that, a method to interface to the DCC program from within my program. Thanks !
Doug
|
|
|
|
|
DougButtimer wrote:
I want to be able to save files to the rewriteable CDROM drive on another computer
No matter if it's local or remote, CD-R/W need packet writing on the UDF filesystem.
I think there is now a Linux UDF driver you could peek at to see how the UDF filesystem works. Then you'd need to know how packet writing works, and learn SPTI to actually use it...
If you do it for a remote computer, you'd in addition most probably have to write your own network protocol and service.
++luck; // I think you might need it
|
|
|
|
|
Hi Mike,
Many thanks for your reply. Correct me if I'm wrong, but, as the CD's will always be formatted for direct R/W (i.e. will accept Explorer drag-and-drop operation), the actual mechanics of file-writing on the CDROM drive is not the issue, surely. I "assume" that I will be able to use the CopyFile() function if I can find out what the filepath (via DCC) of the remote CDROM drive is. Alternatively, if I knew how to emulate a drag-an-drop operation programatically within my program on the local computer's DCC window of the remote computer's sharable drive icons (I can do this manually !) then this would solve my problem. Any advice on either of these approaches would be greatly appreciated. 
Doug
|
|
|
|
|
DougButtimer wrote:
Correct me if I'm wrong, but, as the CD's will always be formatted for direct R/W (i.e. will accept Explorer drag-and-drop operation), the actual mechanics of file-writing on the CDROM drive is not the issue, surely.
That means you already have an R/W UDF driver and packet writer on the machine handling the CD-R/W.
You however only mention Explorer operations. What happens if you try to copy a file from a CMD.EXE shell (still only locally on the machine that has the CD-R/W) to that CD-R/W disk - does that work? If it does, then you're in a better seat to make the whole idea work. If not, you'd be back to (almost) square one I think.
If it doesn't work, I wouldn't be too surprised if that stuff is implemented by this particular vendor as an Explorer shell extension... You judge how easy and/or "fun" it would be to try to interact with it.
I "assume" that I will be able to use the CopyFile() function if I can find out what the filepath (via DCC) of the remote CDROM drive is.
I seem to recall that "assumption is the mother of all fsck-ups".  This often is even more true when dealing with Microsoft APIs and other creations.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
