Updated an application that uses DDE. Specific requirements.
-
This is sort of a "What would you do in this situation" post. Our company has had a Windows program in use for many years since VB6. The short description is that this program collects data points. It also makes use of DDE to make that information available to Excel. The user enters the server and topic in an Excel cell and gets the value from our program or can set a new register to monitor. I have been asked to update the program to .NET and add some features. I am doing this is C#. DDE is of course outdated and I have been trying other alternatives OLEDB / Interop and such. The problem is that management wants all of the configuration to be on the Excel side so that its stored with the worksheet. (As it had been previously). For example my program shouldn't put a value in a specific cell. Rather it should behave like the DDE example did. and it shouldn't be using VBA to call the program via dlls or anything as the customer won't have access to that. My background is not primarily .NET and I don't do much with OLE/COM/Interop ect. I have been reading as much as I can and I have gotten to the point that if I know what cells to work with from the C# side I can get most of the functionality I want. However I have no idea how I would make this work such that the customer can specify everything about the shared data on the excel side. Any thoughts? How would you approach a solution? Edit: Edited to try to clarify that the management is really just trying to retain the functionality that the previous software versions had via DDE. As a developer I am trying to determine the best solution knowing DDE is obsolete. As of yet I haven't been able to find a newer technology that will meet the specific requirements of this tool. Its not a contentious situation or anything like that and I have no issues speaking up when I don't believe things make sense. So really the question should be rephrased as.... "How would you approach a technical solution?" Regards,
-
This is sort of a "What would you do in this situation" post. Our company has had a Windows program in use for many years since VB6. The short description is that this program collects data points. It also makes use of DDE to make that information available to Excel. The user enters the server and topic in an Excel cell and gets the value from our program or can set a new register to monitor. I have been asked to update the program to .NET and add some features. I am doing this is C#. DDE is of course outdated and I have been trying other alternatives OLEDB / Interop and such. The problem is that management wants all of the configuration to be on the Excel side so that its stored with the worksheet. (As it had been previously). For example my program shouldn't put a value in a specific cell. Rather it should behave like the DDE example did. and it shouldn't be using VBA to call the program via dlls or anything as the customer won't have access to that. My background is not primarily .NET and I don't do much with OLE/COM/Interop ect. I have been reading as much as I can and I have gotten to the point that if I know what cells to work with from the C# side I can get most of the functionality I want. However I have no idea how I would make this work such that the customer can specify everything about the shared data on the excel side. Any thoughts? How would you approach a solution? Edit: Edited to try to clarify that the management is really just trying to retain the functionality that the previous software versions had via DDE. As a developer I am trying to determine the best solution knowing DDE is obsolete. As of yet I haven't been able to find a newer technology that will meet the specific requirements of this tool. Its not a contentious situation or anything like that and I have no issues speaking up when I don't believe things make sense. So really the question should be rephrased as.... "How would you approach a technical solution?" Regards,
So your company wants you to create a solution in Excel but will not allow you to use VBA (or the current scripting language). Management straight out of the 1980s. You may be able to launch the c# app from a button in the excel sheet, you can also use c# as the scripting language behind the sheets (it is no VBA after all ;P ) I think there may be events available on the cell (onleave maybe) which may be used to access the code behind. I also think there are excel clones that can be embedded into a c# winforms app that looks and feels like excel that hooks in all the usual events so you can use c# to do the work. I would stronly recommend telling management that they are shooting themselves in the foot!
Never underestimate the power of human stupidity - RAH I'm old. I know stuff - JSOP
-
So your company wants you to create a solution in Excel but will not allow you to use VBA (or the current scripting language). Management straight out of the 1980s. You may be able to launch the c# app from a button in the excel sheet, you can also use c# as the scripting language behind the sheets (it is no VBA after all ;P ) I think there may be events available on the cell (onleave maybe) which may be used to access the code behind. I also think there are excel clones that can be embedded into a c# winforms app that looks and feels like excel that hooks in all the usual events so you can use c# to do the work. I would stronly recommend telling management that they are shooting themselves in the foot!
Never underestimate the power of human stupidity - RAH I'm old. I know stuff - JSOP
Love the username Mycroft. and the 1980s comment. The spreadsheets in this case would generally be setup by the customer using our equipment. Our prior app just acted as a server. At the moment the argument is that all of my solutions are too complicated for the customer or won't save with the excel file. Its for industrial customers not the typical office user. I thought I might be able to get away with automation and maybe referencing by named ranges. I haven't been able to get it to work from the C# app trying to use named ranges though. Not without the app already knowing what they are. Believe me. They have heard my complaints. :laugh: This is a rarely used feature but they insist it still needs to support it without changing it much. I may have to wind up using DDE (NDDE maybe?) though I would really rather not. Thanks for the suggestions. :)
-
This is sort of a "What would you do in this situation" post. Our company has had a Windows program in use for many years since VB6. The short description is that this program collects data points. It also makes use of DDE to make that information available to Excel. The user enters the server and topic in an Excel cell and gets the value from our program or can set a new register to monitor. I have been asked to update the program to .NET and add some features. I am doing this is C#. DDE is of course outdated and I have been trying other alternatives OLEDB / Interop and such. The problem is that management wants all of the configuration to be on the Excel side so that its stored with the worksheet. (As it had been previously). For example my program shouldn't put a value in a specific cell. Rather it should behave like the DDE example did. and it shouldn't be using VBA to call the program via dlls or anything as the customer won't have access to that. My background is not primarily .NET and I don't do much with OLE/COM/Interop ect. I have been reading as much as I can and I have gotten to the point that if I know what cells to work with from the C# side I can get most of the functionality I want. However I have no idea how I would make this work such that the customer can specify everything about the shared data on the excel side. Any thoughts? How would you approach a solution? Edit: Edited to try to clarify that the management is really just trying to retain the functionality that the previous software versions had via DDE. As a developer I am trying to determine the best solution knowing DDE is obsolete. As of yet I haven't been able to find a newer technology that will meet the specific requirements of this tool. Its not a contentious situation or anything like that and I have no issues speaking up when I don't believe things make sense. So really the question should be rephrased as.... "How would you approach a technical solution?" Regards,
eremitic19 wrote:
The problem is that management wants all of the configuration to be on the Excel side
Yup. That's the problem. And what made those managers such specialists that they get to decide about a technical problem?
eremitic19 wrote:
How would you approach a solution?
I'd be asking management what qualifies them to dare bring solutions to the table. And yes, not going to make you popular, but that's what I'd do, since that's what they paying me for.
Bastard Programmer from Hell :suss: "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.