REPOST-MSOffice manipulation w/ WebPage or SmartClient?

[R Reyes]

Hi, no one answered so I thought reposting would get this some attention...

What is the best way to manipulate MSOffice programs? I understand that
regular web pages do not have certain permissions (because of safety
measures) to do things like open up MS word/excel programs, for example, from
a web site. Usually an activex control must be installed first I think?

What I need is a strategy for the best way to open up word/excel
applications and manipulate them by adding/removing text, formatting, and
doing mail merge types of transactions. Would ActiveX be the best strategy
to accomplish this from a web page?

I am NOT trying to make a desktop application to manipulate MSOffice only
because people want to be able to use this program from remote locations. I
have also taken a look at smart clients but I am not sure how difficult it is
to code them or if it is even a good idea?

Any thoughts or comments are welcome. Thanks in advance.

[Boyd Ferris]

You can programmaticall y manipulate Office documents on a web server,
but you will need to configure the code, web application, or the COM
object to run as a specific user that has the necessary permissions to
work with the documents.

If you want to manipulate Office documents on a server for a client,
then the best way is to use the Office Primary Interop Assemblies
(PIA), which can be downloaded from Microsoft. The PIA allows you to
interface with the Office COM objects, exposing the objects, methods,
and properties that will allow you to do just about anything to the
documents. Though, the PIA only exists for Office XP and 2003.
However, a cautious warning: Office was not intended to be automated
without an acutal user. Therefore, potential problems could occur
doing automation that will cause the process to hang. For instance, if
you are automating an Excel spreadsheet that generates some type of
prompting error during your manipulation, then the process will hang
because it is waiting for a user response that can never be given.

[R Reyes]

Thanks for replying.

The word/excel document templates will be loaded from the server on the
network and manipulated on the client machine. Any client machine on the
network should/will have permissions to access these documents. Howeve, I
thought that ASP.NET for example, was not allowed to load up Word/Excel using
the 'Set appWord = CreateObject("W ord.Application ")' command because of
security reasons. Guess I was wrong and it can in fact be done? I will take
a deeper look into this...

Any knowledge of Smart Client? I guess a Smart Client ISN'T the way to go
after all...I'm still a little unclear as to if using them would be a good
idea? It's just that my company currently uses a desktop interface on the
network and I thought that coding a Smart Client would give them the
familiarity of a desktop interface witih the ability to talk over the
internet/network w/ web services whenever needed. Then again, it may just be
a whole lot more work of code (creating XML web services and logic handlers
for Smart Clients) that do not need to be done. Do you have any knowledge of
Smart Client? If not, it's ok I will continue to look into your response.
Thanks again.

"Boyd Ferris" wrote:

You can programmaticall y manipulate Office documents on a web server,
but you will need to configure the code, web application, or the COM
object to run as a specific user that has the necessary permissions to
work with the documents.

If you want to manipulate Office documents on a server for a client,
then the best way is to use the Office Primary Interop Assemblies
(PIA), which can be downloaded from Microsoft. The PIA allows you to
interface with the Office COM objects, exposing the objects, methods,
and properties that will allow you to do just about anything to the
documents. Though, the PIA only exists for Office XP and 2003.
However, a cautious warning: Office was not intended to be automated
without an acutal user. Therefore, potential problems could occur
doing automation that will cause the process to hang. For instance, if
you are automating an Excel spreadsheet that generates some type of
prompting error during your manipulation, then the process will hang
because it is waiting for a user response that can never be given.

[Boyd Ferris]

Here are a few comments that may help you with your design or point you
in a better direction:

In a closed environment where everyone is using Windows and has the
..NET Framework, then a smart client is almost always a better solution
than a web page. Web pages are only good for two things: displaying
read-only information or providing an interface that can be usable
across multiple operating systems. If you have a Microsoft
environment, then use a smart client using no-touch deployment (NTD).
NDT may be called by other names, but searching for "no touch
deployment" or "NTD" will give you information about this type of
deployment. NTD will allow you to distribute a Windows Forms
application like a web page; someone would simply type the URL or click
on a web page link to access the application. (You may need to adjust
the client's .Net Security settings to allow the application to
execute.)

If you are going to manipulate the Office document on the client and
want to use web pages, then you could perform this task on the client
using JavaScript. The security policy on the client would need to
allow the creation of ActiveX controls via JavaScript, using the
ActiveXObject. For the Office document's location, you would use the
web path, such as http://MyWebServer/MyDocument.doc. Here is a link
for the description on the JScript object:

http://msdn.microsoft.com/library/de...iveXObject.asp

I do not know the type of application you are building, so a web
application may be the best solution. However, you may want to
consider Windows Forms instead of web pages: create a windows
application, deploying it via the web using NDT. However, the client
machines will need to have the Office PIA installed and may need their
security settings adjusted. Though, if you still want to use web
forms, then you could use a .NET assembly embedded on the web page
using the <object> tag, using JavaScript to access the .NET Object.
Catch you later,

Boyd

[Boyd Ferris]

Here are a few comments that may help you with your design or point you
in a better direction:

In a closed environment where everyone is using Windows and has the
..NET Framework, then a smart client is almost always a better solution
than a web page. Web pages are only good for two things: displaying
read-only information or providing an interface that can be usable
across multiple operating systems. If you have a Microsoft
environment, then use a smart client using no-touch deployment (NTD).
NDT may be called by other names, but searching for "no touch
deployment" or "NTD" will give you information about this type of
deployment. NTD will allow you to distribute a Windows Forms
application like a web page; someone would simply type the URL or click
on a web page link to access the application. (You may need to adjust
the client's .Net Security settings to allow the application to
execute.)

If you are going to manipulate the Office document on the client and
want to use web pages, then you could perform this task on the client
using JavaScript. The security policy on the client would need to
allow the creation of ActiveX controls via JavaScript, using the
ActiveXObject. For the Office document's location, you would use the
web path, such as http://MyWebServer/MyDocument.doc. Here is a link
for the description on the JScript object:

http://msdn.microsoft.com/library/de...iveXObject.asp

I do not know the type of application you are building, so a web
application may be the best solution. However, you may want to
consider Windows Forms instead of web pages: create a windows
application, deploying it via the web using NDT. However, the client
machines will need to have the Office PIA installed and may need their
security settings adjusted. Though, if you still want to use web
forms, then you could use a .NET assembly embedded on the web page
using the <object> tag, using JavaScript to access the .NET Object.
Catch you later,

Boyd

[R Reyes]

Thank you very much!

"Boyd Ferris" wrote:

Here are a few comments that may help you with your design or point you
in a better direction:

In a closed environment where everyone is using Windows and has the
..NET Framework, then a smart client is almost always a better solution
than a web page. Web pages are only good for two things: displaying
read-only information or providing an interface that can be usable
across multiple operating systems. If you have a Microsoft
environment, then use a smart client using no-touch deployment (NTD).
NDT may be called by other names, but searching for "no touch
deployment" or "NTD" will give you information about this type of
deployment. NTD will allow you to distribute a Windows Forms
application like a web page; someone would simply type the URL or click
on a web page link to access the application. (You may need to adjust
the client's .Net Security settings to allow the application to
execute.)

If you are going to manipulate the Office document on the client and
want to use web pages, then you could perform this task on the client
using JavaScript. The security policy on the client would need to
allow the creation of ActiveX controls via JavaScript, using the
ActiveXObject. For the Office document's location, you would use the
web path, such as http://MyWebServer/MyDocument.doc. Here is a link
for the description on the JScript object:

http://msdn.microsoft.com/library/de...iveXObject.asp

I do not know the type of application you are building, so a web
application may be the best solution. However, you may want to
consider Windows Forms instead of web pages: create a windows
application, deploying it via the web using NDT. However, the client
machines will need to have the Office PIA installed and may need their
security settings adjusted. Though, if you still want to use web
forms, then you could use a .NET assembly embedded on the web page
using the <object> tag, using JavaScript to access the .NET Object.
Catch you later,

Boyd