I was called in this morning to work on a tool that I had built in Excel a while back. The tool generates a report and then prints it to a pdf. The problem they called me in for was that for one user the line spacing in the PDF was off. It took me a while to figure out the cause of the problem. It was the DPI. The user who has trouble seeing the font had increased the font of Windows to 150% and for some reason that causes excel to export to pdf differently.
I know what the problem is but asking the user to change the DPI (forcing the user to log off), log back in, open excel and run my macro and finally change back the DPI is not a reasonable solution. I hope that there is a guru out there that will be able to help me find a solution. I don't mind adding VBA code to temporarily change the DPI while the program is running but I'm not sure how to do that or if its possible.
Thanks
For more clarification its windows 7 and the aspect I’m speaking of is if you go to change the resolution there is a link asking if you want to “Make text and other items larger or smaller”. The slider was changed from the defaulted 100% to 150%.
I cannot think of an easy way of overcoming this problem. Something that you could try is to create an OLE application (in C#, VB.NET or C++ for example) that uses Excel internally just to open the file and export it to PDF. Then you can create a new user on the system and lunch this application from a batch file using the command runas.
Back in Excel again, you can lunch the batch file using the Shell command.
The workflow would be:
1- Using VBA and the Shell function,invoke the batch file from Excel with the current file as parameter.
2- The batch file calls a custom application MyAppExportToPDF using runas and passes the current Excel file as parameter.
3- MyAppExportToPDF opens a new instance of Excel using OLE, loads the file, and exports it to PDF.
Since MyAppExportToPDF will run in a different user, the new Excel instance should also run under that user. The DPI settings under this user should be the ones you need.
Disclaimer: This is just an untested idea.
Related
I'm encountering an issue trying to get some macros and VBA scripts working on a new coworker's computer. I've been using the same code for years on my machine and several others without issue, but when my new analyst tries to run it, it throws an error stating it couldn't save the file. He can manually save the file without issue, but running the script throws the error. The really weird part is that it lists the file path, but replaces the filename with a seemingly random hex byte.
On another file, if he opens it, closes with or without saving, then I open the file and try to save it using a macro, it fails saying "cannot access file...". If I copy and paste the file, open and run the macro again, it saves over the offending file no problem.
We've checked permissions and settings and haven't found anything that was different between the two systems. We're both on VMs. His hardware allowance is less than mine but otherwise they're both IT-managed and identical. I'm at my wits' end... Any advice on what may be the source of my grief would be helpful, even if not a solution.
A couple of things I'd check before trying to step through debugger mode.
Coworker does not have write access to the directory (I think you said you checked already)
The new users' Trust Center Settings are not correct
File > Options > Trust Center > Trust Center Settings... > Macro Settings > Ensure the box is checked to trust the VBA model and that macros are not disabled
The new user does not have the same libraries referenced.
Alt + F11 > Tools > References... > Check if coworkers' libs match yours
Is he using a new/different version of Excel that you? A lot of older code got bojangled when Office 365 hit the scene.
After checking settings, I would ask the following:
What error is thrown when coworker attempts to run the macro?
When does the error get thrown? It could be that you have code that is attempting to edit the file (or has another file stuck in an edit) at the same time you're trying to save it.
I would see why the file name is getting corrupted. It sounds like coworkers' machine is looking to a bit of memory or memory address that is somehow getting forgotten. Like the code is referencing a variable that is out of scope.
User Access Control has been enabled on his VM that is somehow preventing him from saving the file correctly.
Your code does not properly Quit the Excel application, so its still running in the background on coworkers' machine. Have them open/close without saving a file and check Task Manager to see if Excel is still up to confirm
Instead of having the VBA code saved in a module inside the Excel file, I would like to have the code saved in a text file, for example module1.vba. In Excel, module1.vba would be loaded or imported and run as it was a normal module.
Is that possible? How to do that?
In Excel, in the VBA editor, there is the option Insert > File... in the menu that does sort of what I want, but I don't know how to automate that with a minimal VBA code to load the real code saved as text.
Reason for this is to allow code revision control using text based applications like git.
--- edit ---
This answer shows a good alternative work around. However I'm still not too happy in duplicating things.
You can easily import a VBA file using a simple one-liner:
Application.VBE.ActiveVBProject.VBComponents.Import "C:\Path\To\File.bas"
This works with files exported from the VBA IDE, which include information like module name and other properties that can be configured on a per-module basis.
You need to enable Trust access to the VBA project object model for this to work. You can find that in the trust center settings, under Macro Settings.
Our application exports snippets of databases in XLSX format. We wrote our own code on top of System.Packaging as it is many (many!) times faster than using the Excel objects.
Right now we save these files with a .xlsx format, and that works OK. However, it would be much nicer if double-clicking one of these opened our app instead, but failed back to Excel on machines without it.
I know that SpreadsheetML has a feature to do this. If you insert this near the top of the file:
<?mso-application progid=""Excel.Sheet""?>
some sort of magic occurs that causes Excel to open on Win machines. While this might work in SML files, it does not appear to work in "real" xlsx files - I tried adding this line to various parts of the workbook structure but it remained unrecognized.
So is there a similar mechanism we can use in "true" XLSX files generated by System.Packaging? Or some other Windows mechanism we should use in these situations?
I have a specific requirement in our organization.
We are using a third-party tool to convert excel to pdf. Our excel files contain financial data and charts and the tool converts them to pdf files. Once converted, they are sent for printing.
Now I need to write a vb code which tampers with the printer configuration. After conversion to pdf, when I click on print in the tool, it should not go to default printer to print the physical file, nor should it display the dialog box asking for printer to choose, rather it should pop-up a custom dialog box indicating file being saved in the network drive. The drive and file name should be pre-configured.
I know there are quite a few solutions which caters to this problem of saving a file without displaying the default dialog box but my problem is, I am not printing files from the same application. Files are prepared by a third-party application and print option is pressed from here itself. When the file leaves for printing, I want my code to take effect. In a way, if this application is configured in a computer, no matter which tool you are using to print, the files should get saved to a network drive without popping up the default print dialogue box.
Thanks in advance. Any guidance is much appreciated.
Thinking that to solve a problem I've got this is the fastest solution:
Generate a custom CSV file on the file (this is already done via Perl).
Have a XLS document opened via commandline via a scripting language (clients already got a few Perl scripts running in this pipeline.)
Write VBA or record a macro that executes the following OnLoad:
Imports a the data from the CSV file into the report template,
Print the file via PDF driver to fixed location using data in the CSV to name the file.
Closes the XLS file.
So, is this possible via Excel macros, if not is it possible via VBA -- thanks!
NOTE: Appears I've got to have a copy of MS Office anyway, so this is much faster to get going than using Visual Studio Tools for Office (VSTO). The report template is going to be on a server, and this way the end user can build as many reports as they like, "test" by printing a PDF using a demo CSV file, and import/embed the marco or VBA when they're done. I'd looked in Jasper Reports, but the end user is putting ad-hoc static text and groupings all over the report and I figure this way they can build reports how ever they want and then automate them. Both of these questions by me and the resulting comments/feedback are related to this question:
In Excel, is it possible to automate reading of CSV data into a template and printing it to PDF from the commandline?
Is it possible to deploy a VB application made in Excel as a stand alone app?
FOCUS OF QUESTION: Again, focus of the question is if this is possible via Excel marcos, if not macros VBA, and if there's any huge issue with this approach; for example, I know this is going to be "slow" since Excel would be loaded per job, but there's 16GB of ram on the server and it's not used at all. Figure since I've got to have a copy of office on the server anyway, this is a much faster approach.
If you've got any questions, let me know via comments.
I suppose you could launch the report file from perl and then have a macro inside the report file automatically look for the newest csv file to import. Then you could process and output. So you just need to launch the proper excel file with the embedded macros from perl and then let excel and VBA take over.