|
Hi, all.
I am encoutering some communication problem while using synchronous SOCKET.
I have a client which sends data to server with Gbps network in the speed of about 200kB/s. I invoke select function to judge whether I can send data everytime.If it fails I will re-create a socket to connect the server. But when I count the packets sent in client and received in server, I find they are not the same. why this happens? how to impove it?
|
|
|
|
|
What network protocol do u use?
Mohammad
And ever has it been that love knows not its own depth until the hour of separation
|
|
|
|
|
|
From my little experience with winsock, I suggest that you do not re-create a socket everytime select fails (if 'fails' means that you cant write to the socket at the moment), but if 'fails' means that the connection fails, you should recreate a socket on the client AND put the socket on the server in listen mode.
I imagine that ur problem goes in the following scenario:
Client: Connect ,Server:OK
Client: Send ,Server: recv
Client: Send (fails) ,Server recv() no data
Client: Re-connect , Server (Still waiting for data) - not ready to welcome incoming connection
Regards,
Mohammad
And ever has it been that love knows not its own depth until the hour of separation
|
|
|
|
|
I added a cbutton to a cstatusbar. the button comes with thick borders around it when viewed in xp style. how to remove the borders?(I have set noborders style to the status bar pane)
|
|
|
|
|
|
|
Is it possible to have a multi-document project and make one of the documents another executable from createprocess or shellexecute? I guess an example would be starting up the calculator inside a C++ MDI application AND have it be a child document.
Chris
|
|
|
|
|
Chris a "process" is NOT a "document". Please clarify.
led mike
|
|
|
|
|
I think I figured it out in a round about way. It looks like I am going to have to create a blank document and use createprocess to create a process and then position the process overtop the blank document to give a feel that it is inside the window. Ofcourse I am going to have to handle the size changes and the position changes but this is the only solution I have right now.
Chris
|
|
|
|
|
Chris, are you new to MFC? In MFC using the word "document" is associated to the CDocument class. CDocument is NOT a "window" or visual class but is designed to expose "data" elements of the application. It might be viewed as the "model" element of the Model View Controller design pattern.
chris175 wrote: position the process overtop the blank document to give a feel that it is inside the window
That sounds like a terrible hack and not advisable. Good luck with that solution.
led mike
|
|
|
|
|
I know it sounds like a terrible hack and I really cannot argue because it is a terrible hack, but if anyone has any better solutions, I would be greatly appreciative. My main goal is to be able to use C# Forms created in Visual Studio 8.0 in a C++ application in Visual Studio 6.0. I do not want to have to create an ActiveX control to do this.
Chris
|
|
|
|
|
chris175 wrote: My main goal is to be able to use C# Forms created in Visual Studio 8.0 in a C++ application in Visual Studio 6.0.
What? Why? What is the "business requirment" that calls for that implementation?
chris175 wrote: I do not want to have to create an ActiveX control to do this
Why not? That would be better than the other suggested solution.
led mike
|
|
|
|
|
led mike wrote: What? Why? What is the "business requirment" that calls for that implementation
The application I am working on needs to advance to the newer technology. The problem is that the project is so big that it cannot be upgraded at one time. That would take too long to fix, stop production for a time that isn't beneficial, and too many errors to fix.
led mike wrote: Why not? That would be better than the other suggested solution
I have never created an ActiveX control before. I think I remember reading or overheard someone saying that this may be a possible solution but I haven't found anything on the web to assist me with this option.
Do you know of a good link or tutorial as to how to do this with ActiveX and how to build one?
Chris
|
|
|
|
|
chris175 wrote: C# Forms created in Visual Studio 8.0 in a C++ application in Visual Studio 6.0.
Try this:
Create a mixed mode VC++ 8.0 DLL project with MFC support. This project will export a C++ class, in this discussion we call it "foo".
In the DLL You can create a window or dialog using things like CWinFormsView[^] or CWinFormsDialog etc.
Then in the VC6 project use the new DLL and import the C++ class "foo". Using the interface provided by "foo" the new VC8 DLL will create the window and collect the data from the user. The data can be exposed through the plain C++ class "foo" to communicate between the VC6 project and the VC8 DLL.
led mike
|
|
|
|
|
Very Interesting. I am going to try this. I really hope I am able to get it. I am guessing I can also create a VC8 C# DLL to do the same thing a VC8 C++ DLL can do with CWinFormsView? I really would like to use C# instead of C++. Its just easier.
Chris
|
|
|
|
|
chris175 wrote: I am going to try this.
Post back and let us know how it goes. Maybe write an article. 
led mike
|
|
|
|
|
Hi Chris,
have you been successful in connecting the MFC and Windows Forms world?
I currently have a similar problem: We want to expose a Windows Forms control as ActiveX and have no real clue on how to do this. As far as I can see there are some completely different approaches. One would be using a MFC ActiveX as host container for the Windows Forms control. And then using CWinFormsDialog or CWinFormsView to host the Windows Forms control. Another approach would be to rebuild the complete ActiveX interfaces with C# and expose it directly to COM.
So far, we tried approach one and created a MFC ActiveX container to host the Windows Forms control. Now, as we switched on Common Language Runtime support (/clr) we have the major problem that Visual Studio 2005 gets locked up while loading the project. Did you experience something similar? It really seems to have nothing to do with our project, VS2005 stop when loading CRT dlls like 'mscoree.dll', 'mscorwks.dll'.
The only thread I found about the problem is this[^]
Using MFC as unmanaged host for WinForms controls seems to be documented very badly. The basic examples[^] work flawlessly but if you want to do the same thing with a MFC ActiveX nothing seems to work!
Perhaps you can share a bit of your knowledge with me?
cheers,
mykel
If they give you lined paper, write the other way!
|
|
|
|
|
Thanks again for the help.
Chris
|
|
|
|
|
Chris, your post in the C# forum is headed in the wrong direction. Any native C++ code, which is what VC6 is, cannot call into a .NET (managed) library. .NET libraries cannot export function in _cdecl form.
VC7 and VC8 introduced support for "mixed mode" development. This provides the ability for DLLs developed using those tools to export plain C++ interfaces to native code, while accessing the managed world at the same time. You will need to use one of them to bridge between "native" and "managed" worlds, without COM or ActiveX.
Perhaps you should use Google to find some articles on MSDN and read about this a little before you begin.
led mike
|
|
|
|
|
My function looks somethin like that : :
void SEHWrapper(RPC_BINDING_HANDLE &pbh, wiret_STREAMS NewJobList[], char Flags)
{
...
c_SubmitNewList(pbh, sizeof NewJobList / sizeof(wiret_STREAMS), NewJobList, Flags);
...
}
This doesn't work. The Debugger tells me, that sizeof NewJobList returns 4. Why is that so ? Shouldn't it return the size of the array in bytes ? The array is statically allocated in the calling function.
|
|
|
|
|
Mr.Brainley wrote: void SEHWrapper(RPC_BINDING_HANDLE &pbh, wiret_STREAMS NewJobList[], char Flags)
Here wiret_STREAMS NewJobList[] is equvivalent to wiret_STREAMS *NewJobList, and hence its giving sizeof(NewJobList) as 4(sizeof int).
|
|
|
|
|
an array is actually a pointer to the 1st element of that array. so, as you are on a 32 bits system, your pointer is 4 bytes wide...
|
|
|
|
|
If your array is allocated on the heap, sizeof will only return the size of the pointer to the memory you allocated (not the memory size that was allocated there). This isn't the case on the stack (where it will return the size of your array in bytes).
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
|
|
|
|
|
The compiler does not know who calls the function! The only thing he knows is that this is a pointer!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
