DLL for communication class
-
Hi to all, for my projects, sometimes i have to communicate with another computer, sometimes using serial port, sometimes using ethernet and so on: i had write some classes to use for this communication. Last time, on july of this year, my "communication partner" ask me to give him my class to be sure we use the some method, but i work with VC++ and MFC and he works with old visual basic; from this question, there is a way to make a DLL for each class i have, which is used by old visual basic, VC++ (with this, i think there is no problem), C# and Delphi (these are the most used languages in my neighborhood) ? I have to re-write all classes removing the MFC functions, or it's possible leave them so ? Thanks
-
Hi to all, for my projects, sometimes i have to communicate with another computer, sometimes using serial port, sometimes using ethernet and so on: i had write some classes to use for this communication. Last time, on july of this year, my "communication partner" ask me to give him my class to be sure we use the some method, but i work with VC++ and MFC and he works with old visual basic; from this question, there is a way to make a DLL for each class i have, which is used by old visual basic, VC++ (with this, i think there is no problem), C# and Delphi (these are the most used languages in my neighborhood) ? I have to re-write all classes removing the MFC functions, or it's possible leave them so ? Thanks
DRUGODRF, This is a great question. My initial thinking is that this is exactly the kind of situation that COM was developed for. However, if you already have working DLLs that are adequate for your purposes, then re-writing the Communication components in COM, would be extremely time consuming. I think the answer to your question depends on the output of the compiler used for whatever language employed, and the complexity (and compatibility of the type systems) of the communication class that you have designed. My coding experience is mainly C++ and Assembly language,...and, so, I have no idea how a Visual Basic compiler would implement your component. But, I think that if the dependent libraries for your component exist on both computers, then it doesn't really matter if you use MFC or not,...the code execution will jump to the location address specified in the import table of your DLL for the invoked function. But, the primary concern here is: just how reliable is this way of remote communication ???
-
Hi to all, for my projects, sometimes i have to communicate with another computer, sometimes using serial port, sometimes using ethernet and so on: i had write some classes to use for this communication. Last time, on july of this year, my "communication partner" ask me to give him my class to be sure we use the some method, but i work with VC++ and MFC and he works with old visual basic; from this question, there is a way to make a DLL for each class i have, which is used by old visual basic, VC++ (with this, i think there is no problem), C# and Delphi (these are the most used languages in my neighborhood) ? I have to re-write all classes removing the MFC functions, or it's possible leave them so ? Thanks
You have two alternatives, using COM or a C interface. Which one suits you best depends on what sort of data and parameters you have, and how complex your interface is. Putting a C interface on your classes means that you don't export any C++ classes or functions, and use no MFC or C++ classes in your interface. This tend to require a bit more work on the side of the user of the functions. For instance, instead of creating an instance of a class and call functions on that, you would call a free function that creates one internally, and gives you a handle to it. You then use that handle in subsequent function calls (in MFC, all CWnd classes wraps a HWND handle - for this you'd do the opposite). If you want to keep the class interactions, you have do duplicate them in COM. Keep the classes you have, but wrap them in COM class interfaces. This tends to be more work for the library writer, as you have to create and register interfaces and do marshalling and type conversions, but it will let VB, C# and Delphi to work with the COM classes rather than a C function interface. Both methods work for VB, C# and Delphi - it's just a matter of choosing where the pain is. :-)
-
You have two alternatives, using COM or a C interface. Which one suits you best depends on what sort of data and parameters you have, and how complex your interface is. Putting a C interface on your classes means that you don't export any C++ classes or functions, and use no MFC or C++ classes in your interface. This tend to require a bit more work on the side of the user of the functions. For instance, instead of creating an instance of a class and call functions on that, you would call a free function that creates one internally, and gives you a handle to it. You then use that handle in subsequent function calls (in MFC, all CWnd classes wraps a HWND handle - for this you'd do the opposite). If you want to keep the class interactions, you have do duplicate them in COM. Keep the classes you have, but wrap them in COM class interfaces. This tends to be more work for the library writer, as you have to create and register interfaces and do marshalling and type conversions, but it will let VB, C# and Delphi to work with the COM classes rather than a C function interface. Both methods work for VB, C# and Delphi - it's just a matter of choosing where the pain is. :-)