|
plz any one can send me logic gates in C#
|
|
|
|
|
|
I need ftp C/C++ functions/classes to process ftp uploading/downloading tasks.
When I used software [FileZilla FTP Client], it sends/obtains many interesting events/messages, such as:
Status: Resolving address of www.xyz.com
Status: Connecting to 11.222.333.444:21...
Status: Connection established, waiting for welcome message...
Response: 220---------- Welcome to Pure-FTPd [privsep] [TLS] ----------
Response: 220-You are user number 3 of 1000 allowed.
Response: 220-Local time is now 15:16. Server port: 21.
Response: 220-This is a private system - No anonymous login
Response: 220-IPv6 connections are also welcome on this server.
Response: 220 You will be disconnected after 15 minutes of inactivity.
Command: USER xyz
Response: 331 User xyz OK. Password required
Command: PASS *****************
Response: 230 OK. Current restricted directory is /
Command: SYST
Response: 215 UNIX Type: L8
Command: FEAT
Response: 211-Extensions supported:
Response: EPRT
Response: IDLE
Response: MDTM
Response: SIZE
Response: REST STREAM
Response: MLST type*;size*;sizd*;modify*;UNIX.mode*;UNIX.uid*;UNIX.gid*;unique*;
Response: MLSD
Response: AUTH TLS
Response: PBSZ
Response: PROT
Response: ESTA
Response: PASV
Response: EPSV
Response: SPSV
Response: ESTP
Response: 211 End.
Status: Connected
Status: Retrieving directory listing...
Command: PWD
Response: 257 "/" is your current location
Command: TYPE I
Response: 200 TYPE is now 8-bit binary
Command: PASV
Response: 227 Entering Passive Mode (74,220,215,241,4,101)
Command: MLSD
Response: 150 Accepted data connection
Response: 226-Options: -a -l
Response: 226 33 matches total
Status: Directory listing successful
(many more ...)
Those events are very useful and in details, I think MFC FTP classes are NOT powerful enough to process them.
What FTP C/C++ functions/classes are used by [FileZilla FTP Client] (or better than them)? I'd like to try them.
Thanks for links and comments.
.
|
|
|
|
|
|
I have created very simple dialog based project by using visual C++.
I have build it in release mode
Now I added this exe is FileGroups link of installshild ,then I compiled and run the setup
folder get created in C:\program files ,but it contains only uninst.isu file
I have licenced version of Visual studio 6.0,so problem of corrupt files.,
Please help me on this issue
Be Happy
|
|
|
|
|
What is the MFC mechanism for accessing UI controls from background threads?
In C#, we use "InvokeRequired" and "BeginInvoke" to schedule a function call on the UI thread, but how is that done in MFC?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
In MFC, you should not directly access UI elements from background threads.
Instead, you must send messages to the UI thread to get and set elements for the UI.
Use can use SendMessage or PostMessage.
modified 23-Jun-12 0:36am.
|
|
|
|
|
«_Superman_» wrote: In MFC, you should not directly access UI elements from background threads.
True.
«_Superman_» wrote: Instead, you must send messages to the UI thread to get and set elements for the UI.
Use can use SendMessage or PostMessage.
Not entirely true.
The reason for not accessing UI elements from another thread than the main thread is that you can quite easily create a deadlock situation. MFC classes for UI elements uses ::SendMessage() which will block until the message has been handled. If the main thread is not processing messages, possibly waiting for the thread that manipulates the UI element, the application will deadlock.
This of course means that you cannot use ::SendMessage(), even if you call it directly, as it would create the same potential deadlock situation.
::PostMessage() must be used since it doesn't wait for the message to be handled. It is possible to use ::SendMessageTimeout() to avoid a deadlock situation, but if the call fails the receiving thread never gets the message.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Thanks for clarifying that!
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
SendMessage and PostMessage will do the job. You may also like to use PostThreadMessage instead of PostMessage 
|
|
|
|
|
If you pass the window handle that contains the UI you want to manipulate to the thread when created you can use it in ::PostMessage().
|
|
|
|
|
Have a look at the below code:
#include "stdafx.h"
#include "conio.h"
int _tmain(int argc, _TCHAR* argv[])
{
char name[20] = "Some Name";
printf("%s\n", name);
name[1] = 'a';
printf("%s\n", name);
char * name2 = "Some Name";
printf("%s\n", name2);
name2[1] = 'a';
printf("%s\n", name2);
getch();
return 0;
}
Why we get Runtime error when we modify name2[1] = 'a';?
|
|
|
|
|
It all boils down to the difference between an array and a pointer. For name, you have set aside room for 20 characters (that are initialized to "Some Name"). For name2, you are pointing to a static piece of memory. That memory cannot be changed.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
Thanks Crow. That is constant piece of memory.
|
|
|
|
|
In this case... your definition of name2 is what is referred to as a string literal and points to data that is considered constant.
See here[^].
|
|
|
|
|
You are trying to modify a const char array (pointer).
This is not C++.
if you were writing proper C++, you would not get those problems (or a lot less likely).
std::string name = "some name";
std::cout << name << std::endl;
std::string name2 = "some name";
std::cout << name2 << std::endl;
name2[1] = 'a';
std::cout << name2 << std::endl;
Watched code never compiles.
|
|
|
|
|
Technically, to pick nits, it *is* C++ as C++ is a superset of C. What you are really saying is that it isn't "Object Oriented Programming" which is true, but it is still within the definition of C++.
|
|
|
|
|
Chuck O'Toole wrote: Technically, to pick nits, it *is* C++ as C++ is a superset of C
Does the newest ANSI C++ standard incorporate the latest ANSI C standard as a subset?
Last I heard that was not the case
|
|
|
|
|
The point is, C++ did *not* decommit the "char" data type nor pointers. std::string is *not* the only way to do string manipulation in C++. It may be the perferred way for some people but it's not the only way.
|
|
|
|
|
Chuck O'Toole wrote: The point is, C++ did *not* decommit the "char" data type nor pointer
I was responding to what appeared to be a general comment about the language in general and in its entirety and not just one small part.
And that general comment, at this time (new standards), is wrong.
|
|
|
|
|
Context dude, gotta read comments in the context of the thread
|
|
|
|
|
Chuck O'Toole wrote:
Context dude, gotta read comments in the context of
the thread
And respond in that context.
Since another poster read your response in way similar to the way I read it, it suggests that your response is the one at fault.
|
|
|
|
|
C++98 is not a superset of C90 - especially when you consider const and what happens when you cast away const. C allows modification of literals (string and constants) through pointers while C++ doesn't or rather considers it undefined behaviour.
|
|
|
|
|
The point is, C++ did *not* decommit the "char" data type nor pointers. std::string is *not* the only way to do string manipulation in C++. It may be the perferred way for some people but it's not the only way.
|
|
|
|
|
Agree with Chuck... technically it is C++.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
