|
Hi,
I'm having some trouble with this component in Borland 6. I can start the server using TcpServer->Open(); and see that it is "listening" when I go "netstat -an".
However when I try to close the server using, TcpServer->Close(); or TcpServer->Active = false; the socket remains in a "listening" state and I can still connect to it using my client. The OnDestroyHandle event is triggered however for some reason, I cannot close the server. When I use ServerSocket and ClientSocket components, it works perfectly. I just thought the TcpServer is just a ServerSocket component with a TCP layer over the top.
Would this have something to do with the BlockMode property ?
I appreciate any help.
Regards,
Alan.
|
|
|
|
|
I came across an odd difference in CString between Visual C++ 6.0 and Visual C++ 2003. The question is, which would you consider the correct (expected) result from the following code snippet. MFC/SDI basic app for demo...
CString GetString()
{
CString sReturn;
sReturn.Format("%c%c%c%c",'T','h',0,0);
return sReturn;
}
void CteststringView::OnInitialUpdate()
{
CView::OnInitialUpdate();
CString sTemp=GetString()+GetString()+" From String Literal\n";
TRACE(sTemp);
}
// Using Visual C++ 6.0, the TRACE yields
// ThTh From String Literal
// Using Visual C++ 2003, the TRACE yields
// Th
Have they improved CString, broke it, or am I just missing something obvious?
|
|
|
|
|
I'm a bit rusty on C++, not having done any for 18 months. But tried your example in VC++ 6, 7.1 and 8. Get same behaviour as you in the first two. In the last your code doesn't compile!
Kevin
|
|
|
|
|
This is pretty interesting. Personally, without looking into it any further, I would expect the first result.
The returned string from GetString() should returns "Th" (truncated due to the '\0' characters). This then gets appended to the rest and results in "ThTh From Str....".
It seems the VS2003 seems include the null termination character in its concatenation operator, resulting in the "Th" string.
I prefer VS6.0's result anyhow.
I Dream of Absolute Zero
|
|
|
|
|
However, VS6.0's results is not standard behavior! It erased data or corrupted data.
|
|
|
|
|
For VS 2003, they improved CString.
The reasoning is that when you format a string with embedded zeros, you want those zeros to be part of the data set.
A good example where this is uses is in multi-strings (multiple strings separated by a terminating zero and a double zero at the end.)
You can force CString to truncate to the terminating zero by simply calling CString::ReleaseBufffer() right after the call to CString::Format.
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
I have some odd behavior in my program, and I want to make sure
I understand message handling behavior. Let's say I have a simple
mfc dialog application where I do a .DoModal in the InitInstance of the
application. The dialog itself draws a little picture and uses a timer event
for animation.
So, let's say our timer is really fast. Things are thundering along, and the user presses ok. The OnClickOkBtn executes, at which point we do a:
KillTimer(nId);
EndDialog(IDC_OK_BTN);
The $10 question: do any other events execute before execution returns to the InitInstance method? The help file is tantalizingly playful and says:
"EndDialog does not close the dialog box immediately. Instead, it sets a flag that directs the dialog box to close as soon as the message handler returns."
This would seem to imply that I might get just a little more activity.
Charlie Gilley
Will program for food...
Whoever said children were cheaper by the dozen... lied.
My son's PDA is an M249 SAW.
My other son commutes in an M1A2 Abrams
|
|
|
|
|
charlieg wrote: This would seem to imply that I might get just a little more activity.
That seems likely. Try watching the messages with Spy++.
led mike
|
|
|
|
|
This is one of the weirdest things I've ever seen. And its been very tricky to nail down.
We instantiate a class (foo *somefoo = new foo() ) using 'new' and get a pointer to that class.
Later in code, witihin a function of another class, we 'new' a new piece of memory (char *buff = (char*) new char [buffSize]) VERY oddly, this 'new' is returning the address of "somefoo" we instantiated earlier and not a new piece of memory.
Any ideas why this is happening? Or how we can avoid this? Remarkably, its happening at the same point in code EVERY time, although we use new everywhere. This was a pain in the a#$ to find.
Help please!?!?!?!?!?
-C
|
|
|
|
|
Wheatbread wrote: We instantiate a class (foo *somefoo = new foo() ) using 'new' and get a pointer to that class.
Wheatbread wrote: Any ideas why this is happening?
There are a few things that might be going on here. First, check to see if delete is every called on somefoo, or if some method that is called has a delete this somewhere. Second, the Java-style declaration of your pointer may be causing some problems (try removing the ()'s from the declaration). If you are sure the object is being created properly, then place some code around the area you are having problems to see where somefoo becomes invalid.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Zac Howland wrote: First, check to see if delete is every called on somefoo, or if some method that is called has a delete this somewhere.
I already replied that 90 minutes ago in the C++/CLI forum so he must not think that is it.
Zac Howland wrote: Second, the Java-style declaration of your pointer may be causing some problems (try removing the ()'s from the declaration).
That should have no effect.
Second time today someone cross-posted and ignored my reply to their first post. I guess I should take the hint.
led mike
|
|
|
|
|
led mike wrote: I already replied that 90 minutes ago in the C++/CLI forum so he must not think that is it.
99.999% of the time, things like this are simply not realizing you called delete somewhere. I don't check the C++/CLI forum, otherwise I would have yelled at him for that ...
led mike wrote: That should have no effect.
Should, but I have run into cases where doing that actually returns a function pointer instead of an object. Its more that they aren't necessary, so why put them there.
led mike wrote: Second time today someone cross-posted and ignored my reply to their first post. I guess I should take the hint.
It happens. I personally love when they do that then then realize 3 months later that you gave them the right answer the first time.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
I havent deleted somefoo (at least I dont think I have). Below is a code snippet.
somefoo *gSomefoo;
class somefoo {...}
somefoo* somefoo::GetInstance (CString fooType){
somefoo *medDevice = (somefoo *) new derivedSomefoo (fooType);
}
void InitParams(){
somefoo fooFactory;
gSomefoo = fooFactory.GetInstance(fooType);
}
fooFactory is a local copy in InitParams, and I see that destroyed as expected. But gSomefoo is global and pointer returned from fooFactory.GetInstance should be valid. What's happening is later in code, another call to new (char *buff = (char*) new char [buffSize]) is returning the pointer of gSomefoo and not a new pointer. Just weird.
BTW, this is all in a DLL, that happens to be loaded/unloaded regularly. gSomefoo has to be global instead of a class member variable for a variety of reasons.
Thanks.
-C
|
|
|
|
|
How are you linking with the C Runtime? Try linking both the exe and Dll with the DLL version instead of static version of MSVCRT.
Thanks
W.
|
|
|
|
|
Wheatbread wrote: another call to new (char *buff = (char*) new char [buffSize]) is returning the pointer of gSomefoo and not a new pointer. Just weird.
Wheatbread wrote: BTW, this is all in a DLL, that happens to be loaded/unloaded regularly. gSomefoo has to be global instead of a class member variable for a variety of reasons.
The part about the DLL being loaded/unloaded would have helped point out your problem much earlier. Load the DLL once and leave it in memory until you close the application. I'll bet you won't see this behavior happening then.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
I wish I could load it once. Its not possible with our implementation. Its loaded at startup, but a few various actions in the app causes it to be unloaded, then loaded again.
Is there any advantage in making the function GetInstance a static class function? Or making the global variable static?
-C
|
|
|
|
|
Methods like GetInstance are usually used in the singleton pattern, in which case all constructors for the object are private and you keep a pointer to the instance in the class itself (if it is null, you create a new one, otherwise you just return the pointer to the object that already exists).
Fixing that, however, will not fix the problem you are seeing. Knowing that you are loading/unloading the DLL constantly, my guess is that somewhere you create the object, the DLL is unloaded (thereby releasing any memory it had allocated and invalidating it), and then you declare a character array that happens to get the same address.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Is there anyway a file is saved or not ? MSDN doesn't tell much on that
hitherto shall thou come but not further thee
|
|
|
|
|
what? How is it a file if it is not saved?
Nice try deleting your post and reposting in this forum. 
|
|
|
|
|
nope I meant if the file is already created and the file has been changed by some other editor but the file has not yet been saved .Is there a way i can get all the file descriptors opened for a given file?
OOps that was unintentional i wawnted to post it on this forum itself.
hitherto shall thou come but not further thee
|
|
|
|
|
napoleaninlondon wrote: nope I meant if the file is already created and the file has been changed by some other editor but the file has not yet been saved .Is there a way i can get all the file descriptors opened for a given file?
I don't think so from an external point of view; unless the file is still opened, then you could assume that the file will be modified.
but if an application loads a file data and then close the file, and makes some modification to the data, you cannot know that from the "outside"
|
|
|
|
|
Maximilien wrote: but if an application loads a file data and then close the file, and makes some modification to the data, you cannot know that from the "outside"
How about the GetFileAttributesEx() set of functions through which you are able to fill a WIN32_FILE_ATTRIBUTE_DATA struct. You can then check the FILETIME ftLastAccessTime; FILETIME ftLastWriteTime;members for the dates and times.
|
|
|
|
|
napoleaninlondon wrote: Is there a way i can get all the file descriptors opened for a given file?
Even if you could they would not tell you if the "other" application intends to write to the file in the future. I am afraid your current view of this does not appear logical. You might need to step back and reframe the requirements and goals of the project.
led mike
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
