Full Version: Ribbon In Runtime- Export To Word, Email Attach, Excel Gone
UtterAccess Forums > Microsoft® Access > Tool bars, Menu bars + Ribbon
Hello UA,
I've got a totally unexpected problem. My app usually deploys in Runtime 2010 with an accde file. I'd made a custom ribbon for reports, using xml. However, some of the buttons disappear when the app is in runtime- namely the Export buttons: Word, Excel, Email as Attachment. The export to PDF button remains. I'd copied the xml for the buttons from the toolbar list. This all works fine with full Access but not in Runtime.
My old app ran in 2002 Runtime and the export to Word, email as attachment, and Export to Excel worked great in Runtime. Is it possible that in 2010 these buttons simply don't work? How could MS go backwards with features like that, if that's the case? I need a simple solution, if possible, as I am not overly familiar with xml coding for the ribbon. Any help would be greatly appreciated!
Hi Kevin,
don't play with the Runtime much but can you check if the method TransferSpreadsheet is available in the Runtime? If so, then you may be able to use that method in a function that you can call from your Ribbon Button's OnAction attribute.
Just my 2 cents...
There are several previous post on the subject.
From a a quick search here is a Previous Post (Click Here) that should help.
Thanks for the links HiTechCoach,
Oread Albert's response in the post and it seems the closest to what I need to do. I've tried getting the public function right for the RTF export and it keeps hanging up. I'm using:
div class='codetop'>CODE
Public Function MyWord()
DoCmd.OutputTo acOutputReport, Screen.ActiveReport.Name, acFormatRTF
End Function

It hangs up, though, when I try to run the function even independently. Is this the right code for exporting the report that has the focus?
And In the ribbon the button is part of a group (small size buttons) and I've put in what Albert is using, but with the 'MyWord' called. My XML warning keeps coming up though when I open the db, so it must not be in right. I'm trying the below xml:
<control idMso="ExportWord" label="Export To Word" enabled="true" onAction= "=MyWord()"/>

I must be missing a piece of the puzzle.
I ended up using this xml for the button and it worked well:
<button id="WordExport" label="Export To Word"
enabled="true" size="large"
onAction= "=MyWord()"
So that ends up getting the function to run. However it's just exporting to rtf when I'd like it to actually open it in rtf.
Hi Kevin,
could be wrong with this but I think to be valid XML, there has to be a space before the closing tag. For example:
...onAction="=MyWord()" />
Just my 2 cents...
Hi DBGuy,
I think you're right -is it ever otherwise? <- I did an edit on my last post to show the xml that worked ok. My only question now is how to word the public functions. The RTF function I'm using just exports the report to RTF. The user has to save it first before opening it. How would one word the public function to open as rtf instead of export?
lso, I need to do the same thing with Excel in a public function. Would that be essentially the same kind of code to open (instead of export) in excel?
One last question. As mentioned in previous posts, sometimes the user doesn't have Word or Excel. In the public function is there a way to check and send a message instead of just getting the error, if they don't have Word or Excel installed?
Thanks guys, very much, for your help on this.
Hi Kevin,
One of the arguments for the OutputTo method is whether to open the native application or not. Try adding True at the proper place in your syntax. For example:
DoCmd.OutputTo acOutputReport, Screen.ActiveReport.Name, acFormatRTF, "c:\filespec\filename.rtf", True
There is no way (that I know of) to open it without saving it to a file first. You can just delete it afterwards if you don't need it anymore. I believe the OutputTo will also overwrite the previous file if you use the same filename.
Coach mentioned that he did have a technique to check if the Office application is installed first to avoid the error. Perhaps he would share it with us.
Just my 2 cents...
Hi DBGuy,
Owent over it a few different way and I think it probably is best to require the user to save the file first, before opening it. The reason being that if it overwrites the previous file with the same name (previous export) they might do that inadvertently and this protects that. It looks more impressive to just pop it open directly into a Word doc but when it comes down to user confusion that may not be the best approach.
How all I need to do is test for an install of Word and Excel (and Outlook for the email as attachment) beforehand. If we can get that that'd be excellent.
One other, related thing- I posted in the Module forum my Public Function. I was trying to figure the best way to put an message box if the user doesn't save the file, instead of the error that comes up. I've got the message box ok but then can't leave the public function after the message box is clicked OK (it keeps popping back up). Is there a quick way to leave the public function?
Hi Kevin,
That sounds good!
If Coach doesn't come back with his method, I'll see if I can find something for you. I suspect that you could try creating an object and just catch the error if the application is not installed.
If it's not too late yet, I'll try to take a look.
There are a few ways to handle this.
) Interrogate the registry. I generally avoid this method so I do not have to worry about the user's permissions. Keeping up with all the possible apps that could be installed in not an easy task.
2) Use an API to locate the EXE . My preferred method.
used the code from here: http://vbnet.MVPs.org/index.html?code/syst...dexecutable.htm
There is a Access VBA version Posted Here
TIP: To test for Outlook create a file with a .msg extension.
Also, are you using late binging with any automation code?
Hi Boyd,
Thanks for the links and the advice. I've been doing some testing and it seems to work with Office 2007 and 2010 (using the Access 2010 Runtime) so it must be something at odds with earlier versions of office. Perhaps an accde vs mde issue? I know there have been some other Runtime limitations and bugs (a linking bug is a big one) so it wouldn't be too far off if that was the case. I think what I'm going to do is just require users to have 2007 Office or later to use those features, just to keep it simple, and wait for the Access SP1 to come out, test some more, and then see exactly what's up.
Is for late binding, the only place I'm using that is to export events to Outlook's calendar. I don't have a lot of experience with late binding but DBGuy helped me out with that particular function and the export works well even with older Office versions. Thanks again for the help on this.
Curious, What does not work with earlier versions of office?
still use the Access 2003 runtime a lot. The code I have suggested for testing for Office apps I currently use with Access 2003 without any issues.
Hi Boyd,
Oupgraded my Access 2002 app into the new 2010, in accdb format. There has been a lot of issues... A big one is that the re-linking doesn't work if the BE is moved after the FE has been linked to it, and you need to link again (if you install to new customers this is a normal process). Apparently it's an Access bug that will be fixed with the SP1 release (I'd spent 50 + hours trying to figure this out, on forums and off to no avail- the workaround is to compact/repair the FE After the BE has been moved and BEFORE it's re-linked or saved as an accde).
lso, regarding this thread, the code I've always been using to export query results to Excel does not work if the installed Office version is older than 07, and the app is using the 2010 Runtime. I don't know if this is a Runtime bug as well- I never had a problem with this code at all in 2002. I'm going to do as much testing as possible to find out. But it was an unexpected restriction. Hopefully that will be the last of them..
Are you saying that the MDB/MDE (Access 2002/2003 format) does not work correctly in the Access 2010 runtime? Does it work correctly with Acess 2007 runtime?
No- I imported all objects from the original mdb into a 2010 accdb. I did this piece by piece to make sure everything went in and was imported correctly. So it's all in an accdb format. The excel export code, though, is exactly the same as what was in the original mdb. It also does work normally either with full Access or if the computer has Office 07-10 (and the accde is in 2010 Runtime). But if the computer has older Office (2000-2003) the export does not work (again, this is using an accde in 2010 Runtime).
I used to use the original mdb (2002) or mde with a 2007 Runtime to utilize the pdf as attachment feature (2002 runtime did not have that) and everything worked fine. So it seems that it's an issue with an accdb or accde file using 2010 Runtime only. Probably it's a 2010 Runtime bug, as there seem to be many.
Ooo ooo, I realise you have moved on from this now but I actually have a solution for this problem (I actually had to work it out for myself this morning), I have an app that automatically writes discharge letters for patients and occasionally the user will want to write a completely custom letter and my solution was to export to word and have them edit to their needs, due to confidentiality I couldn't have it save anywhere.
My solution uses a .dot template and runs it as a user would had they opened it manually (not saved anywhere and prompted for a location if they try).
If you are interested in this let me know and I'll share the code. BTW, I am using to export one record at a time, if you are exporting multiple some thinking may be required.
Ah .. so it is Access 2007/2010 and Excel/Word/ in Office 20003 or prior.
I have used the Access 2003 full and runtime to export via automation with Word/Excel 2007.

I am curious to see if my automation code works in a ACE (.accdb/Access 2007) database and Word/Excel 2003. Since I use late binding it should work. I will have to try it.
This is a "lo-fi" version of UA. To view the full version with more information, formatting and images, please click here.