Your opinion about best way to display Word documents inside an Access form (1 Viewer)

[lauro]

Hi,
I really would like to know your opinion and exploit your expertise about a problem is annoying me since quite long time.

Which is the best way to display the content of a Word document inside an Acces form?

My scenario is quite simple and I'm sure a lot of you runned already in a similar one.
I want to file Word documents in an Access database a let the user scroll in a form all the records and all documents.
Actually is a litlle bit more compliated, but not much:

• Word: 1 template(.dotm): 2 type of documents (.docx): whole documents and portions of documents.
• Access: 1 table and form for portions of documents (and metadata), 1 table and form for whole documents (and metadata).
• The user can create, search, display, modify portions both; insert part of document inside the whole one. After a parameter search, portions of (or whole) documents are shown in a Access form and the user can rapidly browse in their content.

How to display a Word document inside a form? I tried several approaches, but neither is fully satisfying. I'll hyperlink other post discussions of each problem.

1. Ole Bound Object Frame
   • First try, Microsoft adviced. But:
   • If Word files saved inside a OneDrive sub folder impossible to link OLE Object.
   • If Word template contains a ActiveDocument reference in its Document_Open routine error 4248 occurs, even only records navigating.
   • Beside why to store an OLE Object, if I could store only its FullName?
2. Ole Unbound Object Frame
   • I change the Source Control on Current event.
   • I'm spared to have the OLE object in Access table but, the other problems are still there.
3. Web Browser Control for PDF version
   • A word document cannot be displayed inside the form, only saved/downloaded.
   • I can modify my Document.Save command and everytime the user save the docx file also the pdf is saved. So I can shown in the Web Browser Control the PDF version. Fine, but
   • Sometime a (0:521) error is arised by Acrobat Reader (in Windows 11, Microsoft 365) (in old laptop with Windows 8 and Office 2010 no problem)
4. Web Browser Control for HTM version
   • I can modify my Document.Save command and everytime the user save the docx file also the HTM is saved (a little more burdensome because also a sub folder with images are saved).
   • I can shown in the Web Browser Control the HTM version without problem until now. But
   • I do not have Header/Footer and page brakes.
5. AcroPDF.PDF.1 Viewer for PDF version
   • I didn't succed in register the OLE server (on Windows 11, Microsoft 365) , I didn't succed to set the right reference to Source Control (on Windows 8 and Office 2010). I saved myself the trouble to solve those problem because I thought
   • I don't want the user to be involved in a lot of problems.

In conclusion, I think that to show the HTML version is the safer one, the one should less cause trouble to the final user (in every configuration he/her will have). I would have preferred the PDF solution, and of course the docx one.

I'm really surprised that Microsoft dosn't provide developers an easier/simpler solution to integrate two of their more popular applications!

I still have three problems to tackle (unless I will receive, as I hope, some illuminating advise from you, ):

1. Include in the modified Document Save command of Word the routine to insert page breaks, headers, footers of the docx version?
2. How to avoid the flickering of webpage/print view changes after the htm saving of the doc? The Application.ScreenUpdating = True/False doesn't work fine.
3. Saving all the documents in the two formats (with nowdays storage should not be a big concern) or save only the docx version and when the paramer query tell which files should be displayed save them as htm in a temp folder?
   1. But before the form is usable by the user (a lot of time: around 2 seconds each files on my system) or
   2. Save as htm only, let's say, 5 files, let with Do Events finish the others while user is watching the first one (I think to compliacated and sourde of problems)

Thank you very much, if you have read all my long post.
Of course I'm waiting for you opinions.
Lauro

 

[isladogs]

If you use the new Edge web browser control in Access 365 Current Channel Preview, you can view the Word doc converted to PDF inside the browser control. There should be no errors
See https://www.access-programmers.co.u...browser-control-is-finally-here.326988/page-3
Its a very long thread - post #49 is relevant

 

[The_Doc_Man]

The easiest way to show a Word document is with Word. One of your stated requirements is why I say that.

The user can create, search, display, modify portions both; insert part of document inside the whole one. After a parameter search, portions of (or whole) documents are shown in a Access form and the user can rapidly browse in their content.

You can open Word as an application object from Access and do so in a way that the user has control. Once you are inside Word, you can create, search, display, modify... and what you have when you are done is a Word document. Using any of the other methods you mentioned, you run into issues when trying to change the file in any way.

If Word files saved inside a OneDrive sub folder impossible to link OLE Object.

If you can do this from Word, then you can do it from Word as an App object. If you can't do it from Word, you will surely do no better using the other options you tried and didn't like. However, OneDrive has this problem that you really can't interact very well using Access because of protocol issues. You would do better to copy the file locally and then once done with diddling it, copy it back. OneDrive's protocols are not compatible with "normal" Windows File Sharing (using SMB protocol). OneDrive, like most "cloud-based" file services, wants to transfer whole files at once.

 

[Pat Hartman]

Since Word provides a pretty good interface for editing any document, I agree with Doc, I would open the document from Access so the user can edit it. I do have applications where I export to word and do some formatting before saving the document. I also have applications where I use OLE to populate bookmarks in documents created by the user. Both of those activities are different from what you described. I don't like putting Access in the middle when it is the user who will actually be doing the updating.

 

[lauro]

If you use the new Edge web browser control in Access 365 Current Channel Preview, you can view the Word doc converted to PDF inside the browser control. There should be no errors
See https://www.access-programmers.co.u...browser-control-is-finally-here.326988/page-3
Its a very long thread - post #49 is relevant

I changed my Office 365 subscription to Insider, first Current Channel then Beta. In both cases I connot use the "change to" option which is grayed. Could it be a geographic limitation? (I live in Italy).
If I will succed to use this new Web Browser Control and insert it in my Access Form, the final user of my solution needs to have the last Edge version installed on his/her computer? Or will it works whatever browser they have?
From the last posts of the thread you mentioned seems that both PDF and Docx files could be corectly displayed in the new control. Right?
Thanks, again
Lauro

 

[lauro]

The easiest way to show a Word document is with Word. One of your stated requirements is why I say that.



You can open Word as an application object from Access and do so in a way that the user has control. Once you are inside Word, you can create, search, display, modify... and what you have when you are done is a Word document. Using any of the other methods you mentioned, you run into issues when trying to change the file in any way.



If you can do this from Word, then you can do it from Word as an App object. If you can't do it from Word, you will surely do no better using the other options you tried and didn't like. However, OneDrive has this problem that you really can't interact very well using Access because of protocol issues. You would do better to copy the file locally and then once done with diddling it, copy it back. OneDrive's protocols are not compatible with "normal" Windows File Sharing (using SMB protocol). OneDrive, like most "cloud-based" file services, wants to transfer whole files at once.

YES. All the manipulation of the Word documents are made by Word itself. Or starting from Word itself or starting Word from Access.

My problem is only related on how to display the content of the Word docx in a Access form. In this Access form, linked to a dynaset/query/ several records, I have a multi tab control: in the first page there are metadata, in the second page the full name of the file and the preview of the file. This last preview is causing me troubles.

After perousing in the docx preview, the user will start the real work which will be delegated to Word.

 

[lauro]

Since Word provides a pretty good interface for editing any document, I agree with Doc, I would open the document from Access so the user can edit it. I do have applications where I export to word and do some formatting before saving the document. I also have applications where I use OLE to populate bookmarks in documents created by the user. Both of those activities are different from what you described. I don't like putting Access in the middle when it is the user who will actually be doing the updating.

Thanks for the contribution.
As I said to Doc, Word is taking care of the editing/manipulation.
My problem is how to display docx file inside access forms.
Lauro

 

[isladogs]

I changed my Office 365 subscription to Insider, first Current Channel then Beta. In both cases I connot use the "change to" option which is grayed. Could it be a geographic limitation? (I live in Italy).
If I will succed to use this new Web Browser Control and insert it in my Access Form, the final user of my solution needs to have the last Edge version installed on his/her computer? Or will it works whatever browser they have?
From the last posts of the thread you mentioned seems that both PDF and Docx files could be corectly displayed in the new control. Right?
Thanks, again
Lauro

Hi @lauro
I'm not aware of any geographical restrictions jn the use of the new Edge browser control. In any case, it should be released to the current channel in the next few weeks.
The browser control is totally independent of whichever browser app is used. However, end users will need to have a version of A365 that supports the new control. Older versions of Access won't get it.

In the other thread, it was stated that both online and local PDFs work in the new control. Online Word docs will work using redirection as explained by @mohsin Mailk. However AFAIK, local Word docs do not work now and will not work in future. That's why I suggested using PDFs or just open in Word.

 

[The_Doc_Man]

After perousing in the docx preview, the user will start the real work which will be delegated to Word.

Getting Access to display a Word document inside an Access form HAS to include Word itself, since Access (which is not a word processor) cannot actually read and interpret Word document format. One of those other methods you didn't like - for instance, an OLE link or hyperlink - will be needed since they can bring Word into the operation... with this warning: If you have the document open via some other method, Word will potentially balk at modifying a file that is already open by another process. Which means you would have to release the document via the other method first. In essence, you run into Windows file locking if you are not careful.

 

[Pat Hartman]

What is the perceived benefit of displaying the document constrained by a browser control on an Access form?

 

[lauro]

What is the perceived benefit of displaying the document constrained by a browser control on an Access form?

In that Form with a MultiTab control the user can see all the documents satisfying the research criteria: in one page the metadata, in another the actual document. Probably having only the metadata is not enough. On the other end, opening every document is too cumbersome.
After the choice of the document for the editing, the document is opend by Word.

 

[The_Doc_Man]

I'm really surprised that Microsoft dosn't provide developers an easier/simpler solution to integrate two of their more popular applications!

Except that it is actually quite easy to integrate Access with Word, Excel, or Outlook through the Common Object Model (COM) interface. Some of our members have also done PowerPoint integration. There IS a decent interface. The problem you have isn't the interface between Access and Word - it is the magnitude of intertwining that you want to achieve in an application what was originally built to support small businesses.

You have designed an extreme scenario. What you implied is to open each document to see what is in it and then when you have made your selection, open the document again, this time in R/W mode. It will of course depend on specific implementation, but I suspect you would quickly get an "out of memory" error if you actually opened all of those OLE frames into all of those files. You will be chewing up Windows file handles like crazy. To me it would be a toss-up between errors "Out of resources" and "Out of memory." Just how many searchable documents are we talking about here?

I might try developing a brief summary of each document when it is added, storing same in a LONG TEXT field. Show your metadata and the summary, but that summary won't involve opening a file. I would presume you have keyword lists you can put in a table so that users can ask for documents matching certain common keywords. If you actually wanted to search the documents on-the-fly for general keywords or specific phrases, you need to pull in Windows functions that would do that.

The REAL answer is that this might be more than Access can do for you unless you are willing to limit what you actually show.

 

[MajP]

On the other end, opening every document is too cumbersome.

Do you operate with more than one monitor? If so then do what Pat is suggesting. Your arguments for needing to open in a browser do not hold if that is the case. You can do everything you want and more by simply opening the document in Word. From Access you can open, navigate, edit, close a word document without ever using word controls or opening the document from Word.
I have an application where you select a Word document from the file browser which saves the path in a table. Then later you can pick directly from a table. It then reads the document and inserts certain types of based on a complicated regular expression and inserts these words into a table to then search for. Using controls in the Access form I can go to a word (and all locations) and use controls on the form to modify the words based on data in another table. I can search forward and back and do the find and replace all from Access. Bottom line you can fully control a Word document from Access, but if needed you can directly manipulate the Word document too. However, this only works on two monitors or a screen large enough to have access and word visible.

 

[The_Doc_Man]

Excellent point about "screen real estate" @MajP

 

[lauro]

Except that it is actually quite easy to integrate Access with Word, Excel, or Outlook through the Common Object Model (COM) interface. Some of our members have also done PowerPoint integration. There IS a decent interface. The problem you have isn't the interface between Access and Word - it is the magnitude of intertwining that you want to achieve in an application what was originally built to support small businesses.

It doesn't seem to me such a smooth integration:

• I cannot use OLE if the file linked are stored in a OneDrive folder (another Microsoft product);
• I cannot use OLE Frame if Word Document_open has an ActiveDocument line;
• I cannot scroll the document in the OLE frame
• All of this operations are better achieved in non Microsoft solutions: PDF or HTML.

You have designed an extreme scenario. What you implied is to open each document to see what is in it and then when you have made your selection, open the document again, this time in R/W mode. It will of course depend on specific implementation, but I suspect you would quickly get an "out of memory" error if you actually opened all of those OLE frames into all of those files. You will be chewing up Windows file handles like crazy. To me it would be a toss-up between errors "Out of resources" and "Out of memory." Just how many searchable documents are we talking about here?

I didn't think it an extreme scenario, but maybe I'm wrong. We are talking about around 100/200 word documents.

I might try developing a brief summary of each document when it is added, storing same in a LONG TEXT field. Show your metadata and the summary, but that summary won't involve opening a file. I would presume you have keyword lists you can put in a table so that users can ask for documents matching certain common keywords. If you actually wanted to search the documents on-the-fly for general keywords or specific phrases, you need to pull in Windows functions that would do that.

The REAL answer is that this might be more than Access can do for you unless you are willing to limit what you actually show.

I think the best solution for me will be abandon OLE: in the Access table put a field for the document file name, wich will be saved twice (DOCX and HTM): the first for manipulation/editing the secondo only for display: is it a waste of storage space: but with nowdays HD capacities I don't think I will have problem

I prefer HTM over PDF only because the final user will probably have less difficulties (though I losing page breaks, headers and footers.

 

[lauro]

Do you operate with more than one monitor? If so then do what Pat is suggesting. Your arguments for needing to open in a browser do not hold if that is the case. You can do everything you want and more by simply opening the document in Word. From Access you can open, navigate, edit, close a word document without ever using word controls or opening the document from Word.
I have an application where you select a Word document from the file browser which saves the path in a table. Then later you can pick directly from a table. It then reads the document and inserts certain types of based on a complicated regular expression and inserts these words into a table to then search for. Using controls in the Access form I can go to a word (and all locations) and use controls on the form to modify the words based on data in another table. I can search forward and back and do the find and replace all from Access. Bottom line you can fully control a Word document from Access, but if needed you can directly manipulate the Word document too. However, this only works on two monitors or a screen large enough to have access and word visible.

No I'm thinking of only one screen.

 

[The_Doc_Man]

The problem you are facing is that OneDrive protocols are more limiting than a simple LAN-attached disk, network-attached disk, local disk, or disk-like USB device. It isn't so much that you have an OLE problem; it is that you have a OneDrive problem. OneDrive is a whole-file solution but Office expects/uses a protocol based on getting selected disk blocks out of the whole file.

 

[561414]

I haven't read the entire thread.
Why do you not want to open the document from Access and make your edits in Word?
What advantage is Access expected to give you if you do it from Access?
What is the typical user going to do if you manage to sync the two apps?

 

[lauro]

I found in this post a solution to one of the major problem using a OLE Object Frame (Bound or Unbound) in an Access form when the file to link is in a OneDrive folder.
I didn't test extensivly, but it seems to work for me.

 

[lauro]

I haven't read the entire thread.
Why do you not want to open the document from Access and make your edits in Word?
What advantage is Access expected to give you if you do it from Access?
What is the typical user going to do if you manage to sync the two apps?

That is what the user will do!
But, maybe, after he/her gave a look to the content of one/more documents.