|
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!
|
|
|
|
|
Using VS-2005, when creating a dialog control using the resource editor and toolbox, all windows are created with a 3-D/sunken type border instead of a basic flat border. No combination of border property settings (StaticEdge, ModalFrame, ClientEdge, Borders) will allow the basic flat border. If I create the controls in code the borders are as advertised so it appears somewhere the VS is overriding my properties. Anyone know where this is done?
Thanks in advance,
Tracy Hanahan
tsh5@psu.edu
|
|
|
|
|
Hi all,
I am writing a namespace extension and have run into a little problem. I havea a context menu handler that gets called with 'open' when the user double clicks on a subfolder of my namespace extension. At the moment I take the PIDL of the subfolder, turn it into a real path and call ShellExecuteEx on it. However, this always opens the subfolder in a new window- I want it to open in the existing window.
Is there a function of IShellFolder I can call to open the desired PIDL? I've tried BindToObject but it doesn't work.
Any help would be much appreciated, this is really holding my work back now...
Thanks in advance,
Dave Kerr
codechamber@hotmail.com
http://www.codechamber.com
|
|
|
|
|
Hi, i have a small problem i hope to get some help with.
I am working with the SerialPort class in .NET 2.0. I want to use the SerialPort's write() method as defined below with the following overloaded arguments.
public:
void Write (
array<unsigned char="">^ buffer,
int offset,
int count
)
The program on the other end of the serialPort is using C code. The serialPort on the other end uses a serial port read function which takes in a unsigned char array.
ie. void read(unsigned int i)
Does anyone have any ideas how i can pass my data through? (ie from a CLR array to a function that takes native arrays). I am stuck as there are no overloaded write methods in SerialPort class which allow me to pass a native array. I can only think of one solution at the moment, and that is deriving my own class inherited from SerialPort and overload the write method to take in a native array, but i have no idea to write a method which will write data to a serial port.
PS. most of my work is already completed in .NET so there is no chance of starting over in unmanaged C++, and the other end cannot be changed to .NET as it is legacy system.
|
|
|
|