Home |
Search |
Today's Posts |
#1
Posted to microsoft.public.excel.programming
|
|||
|
|||
Using Excel 2007 as a thin client...
To the point: Excel is a application interface that people are comfortable
with and that (thankfully) isn't going away any time soon. As a result when dealing with certain custom applications, using the Excel interface is just the way to go. Question: Assume I wanted to write a custom application in Excel and deploy it to 1000 people (since Excel 2007 is already on everyones desktop). In the past we would have to write VBA modules and bake them into the spreadsheet. That doesn't scale when attempting to deploy to 1000 users. People would copy the spreadsheets everywhere and updates would be a nightmare. How do I get around this issue? How can I leverage Excel to write scalable and maintainable software? Any help pointing me to resources explaining how to approach this would be appreciated. |
#2
Posted to microsoft.public.excel.programming
|
|||
|
|||
Using Excel 2007 as a thin client...
Put all the code in an add-in.
Tim "X-MSFT" wrote in message ... To the point: Excel is a application interface that people are comfortable with and that (thankfully) isn't going away any time soon. As a result when dealing with certain custom applications, using the Excel interface is just the way to go. Question: Assume I wanted to write a custom application in Excel and deploy it to 1000 people (since Excel 2007 is already on everyones desktop). In the past we would have to write VBA modules and bake them into the spreadsheet. That doesn't scale when attempting to deploy to 1000 users. People would copy the spreadsheets everywhere and updates would be a nightmare. How do I get around this issue? How can I leverage Excel to write scalable and maintainable software? Any help pointing me to resources explaining how to approach this would be appreciated. |
#3
Posted to microsoft.public.excel.programming
|
|||
|
|||
Using Excel 2007 as a thin client...
Could you point me to some reference material? I would imagine the Add-In
needs to be deployed. What would the deployment look like? How is it maintained? "Tim" wrote: Put all the code in an add-in. Tim "X-MSFT" wrote in message ... To the point: Excel is a application interface that people are comfortable with and that (thankfully) isn't going away any time soon. As a result when dealing with certain custom applications, using the Excel interface is just the way to go. Question: Assume I wanted to write a custom application in Excel and deploy it to 1000 people (since Excel 2007 is already on everyones desktop). In the past we would have to write VBA modules and bake them into the spreadsheet. That doesn't scale when attempting to deploy to 1000 users. People would copy the spreadsheets everywhere and updates would be a nightmare. How do I get around this issue? How can I leverage Excel to write scalable and maintainable software? Any help pointing me to resources explaining how to approach this would be appreciated. |
#4
Posted to microsoft.public.excel.programming
|
|||
|
|||
Using Excel 2007 as a thin client...
I have used Inno Setup (find it via Google) for years to deploy Excel
add-ins. I also use a VB6 routine during the setup process to assign the proper registry entries, but I believe I could also do this using Inno. A recent article on Jan Karel Pieterse's web site (http://jkp-ads.com) describes a method by which an add-in can check for a newer version, and if necessary, download and upgrade it. - Jon ------- Jon Peltier, Microsoft Excel MVP Tutorials and Custom Solutions Peltier Technical Services, Inc. - http://PeltierTech.com _______ "X-MSFT" wrote in message ... Could you point me to some reference material? I would imagine the Add-In needs to be deployed. What would the deployment look like? How is it maintained? "Tim" wrote: Put all the code in an add-in. Tim "X-MSFT" wrote in message ... To the point: Excel is a application interface that people are comfortable with and that (thankfully) isn't going away any time soon. As a result when dealing with certain custom applications, using the Excel interface is just the way to go. Question: Assume I wanted to write a custom application in Excel and deploy it to 1000 people (since Excel 2007 is already on everyones desktop). In the past we would have to write VBA modules and bake them into the spreadsheet. That doesn't scale when attempting to deploy to 1000 users. People would copy the spreadsheets everywhere and updates would be a nightmare. How do I get around this issue? How can I leverage Excel to write scalable and maintainable software? Any help pointing me to resources explaining how to approach this would be appreciated. |
#5
Posted to microsoft.public.excel.programming
|
|||
|
|||
Using Excel 2007 as a thin client...
This has been a useful reference for me:
http://www.amazon.com/Professional-E.../dp/0321262506 Tim "X-MSFT" wrote in message ... Could you point me to some reference material? I would imagine the Add-In needs to be deployed. What would the deployment look like? How is it maintained? "Tim" wrote: Put all the code in an add-in. Tim "X-MSFT" wrote in message ... To the point: Excel is a application interface that people are comfortable with and that (thankfully) isn't going away any time soon. As a result when dealing with certain custom applications, using the Excel interface is just the way to go. Question: Assume I wanted to write a custom application in Excel and deploy it to 1000 people (since Excel 2007 is already on everyones desktop). In the past we would have to write VBA modules and bake them into the spreadsheet. That doesn't scale when attempting to deploy to 1000 users. People would copy the spreadsheets everywhere and updates would be a nightmare. How do I get around this issue? How can I leverage Excel to write scalable and maintainable software? Any help pointing me to resources explaining how to approach this would be appreciated. |
#6
Posted to microsoft.public.excel.programming
|
|||
|
|||
Using Excel 2007 as a thin client...
I have had success with using Excel as the business logic and user interface
layers while deploying the data layer in a database somewhere. XL itself stores no data. It just reads and writes to and from a database. Doing it this way I just place a read only copy of the spreadsheet in a central location that everyone who needs access can get to. When they log in it determines who they are and configures itself for their needs. This approach works well when the spreadsheet is designed to fascilitate a colaborative effort such as budgeting. Just my 2 cents. -- HTH... Jim Thomlinson "X-MSFT" wrote: To the point: Excel is a application interface that people are comfortable with and that (thankfully) isn't going away any time soon. As a result when dealing with certain custom applications, using the Excel interface is just the way to go. Question: Assume I wanted to write a custom application in Excel and deploy it to 1000 people (since Excel 2007 is already on everyones desktop). In the past we would have to write VBA modules and bake them into the spreadsheet. That doesn't scale when attempting to deploy to 1000 users. People would copy the spreadsheets everywhere and updates would be a nightmare. How do I get around this issue? How can I leverage Excel to write scalable and maintainable software? Any help pointing me to resources explaining how to approach this would be appreciated. |
Reply |
Thread Tools | Search this Thread |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Forum | |||
2007 workbook for 2003 client | Excel Discussion (Misc queries) | |||
Excel 2003 chart lines are too thin | Excel Discussion (Misc queries) | |||
Thin Borders | Excel Programming | |||
Excel & 'Thin Client' experience anyone ? | Excel Discussion (Misc queries) | |||
GetSetting & SaveSetting in Thin Client Environments | Excel Programming |