I need to change Print Settings to Print Active Sheets instead of Print Selection.
I tried using macro recorder, but it did not capture any code.
Also, this simple vba code just print the active sheet, but it does not change print settings as required at run time.
ActiveSheet.PrintOut
In advance, your help is appreciated.
The setting in discussion is workbook specific. You cannot change it globally even using another language, because of the previous mentioned truth. I mean, using a specific language method.
But you can do it, using VBA, simple running a piece of code like the following one printing two sheets. Next time, for that specific workbook the setting will be changed. You obtain what you need when the code runs and also change the setting:
Sub printActiveSheets()
Dim wb As Workbook
Set wb = ActiveWorkbook
Sheets(Array(wb.Sheets(1).name, wb.Sheets(2).name)).PrintOut
End Sub
It will print first and second sheet and will also make the change you need.
In order to check that, please manually print a selection, then look at that specific setting. It will be changed in 'Print Selection`. Then, run the above code and make the same check. You will see 'Print Active Sheets'. It will also be memorized for that specific workbook if you save it.
It is not easy to change that setting, let us say, As Default, being valid for all open workbooks. I cannot swear that it is impossible. If I will take it like a challenge I will maybe find some Registry keys able to be handled (as Excel does) in order to do it for all involved workbooks. But the effort cannot be covered by the result, I think. This is the way Excel works, should be the essence of the answer, I also think.
There are tons of questions already posted with a similar problem, but none of those solutions works for me. I'm using Office 365, so maybe it's something that changed there. Anyway, here is my issue.
I have a file that pulls info from one main tab into other tabs. On the subsequent tabs, I have VBA that auto-hides rows depending on the value that was pulled from the main tab. Anytime the data in the main tab is updated, the subsequent tabs should also update. I had an issue with making this work, but I worked it out by using another cell to store the previous value that had transferred (comparing them, and running the code any time they were dissimilar). The problem now is, of course, that it wont run when the tabs are protected. The tabs need to be protected to prevent end-users from corrupting the formulas and formatting, but I can't make it work with any of the solutions posted on StackOverflow. My code looks something like this:
Sub Worksheet_Calculate()
If Range("Old Value") <> Range("New Value").Value Then
Range("Old") = Range("New").Value
Rows.EntireRow.Hidden = False
<<Insert code to auto-hide based on "New Value" cell>>
End If
End Sub
I've tried adding Worksheet.Unprotect Password:= and Worksheet.Protect Password:= commands on either side of the If statement, and I get a 424 Object Required error. I've tried using the "UserInterfaceOnly = True" command with my password protection, and it changes nothing (still get the trying to change a protected sheet error). I've tried creating another subroutine for unprotecting and re-protecting, then using a GoTo to run the original subroutine; but that didn't work either. I see a lot of solutions using ActiveSheet commands, but I don't think I can use them. I'm updating the main tab, and the action is happening on another tab. I'm fairly new to coding, and I'm teaching myself as I go; so, I could be missing something obvious.
It works perfectly when unprotected, so I guess I may have to just leave it that way. I hate wasting time fixing the files when end-users do their best to ruin them, though, so I'd love to leave it protected.
This may not be the final answer, but I seem to have stumbled upon a solution. Since the only thing I want happening on the protected sheet is for rows to auto-hide, I left row formatting unprotected. It seems to work fine that way. You would think there's a way to run your VBA normally without having to jump through hoops because of protection....but, I'll take it for now.
I inherited a file from a co-worker that is no longer with the company.
In the file are about two dozen of Sub's, with a lot of duplications and redundancy's. There are about a dozen of userform inputboxes in the excel file.
Is there an easy way to check if a certain sub is linked to an inputbox?
I know I can check for each inputbox which Sub is linked to it, but I want to check for it the other way around.
Set breakpoint at every sub. Having set that, play with inputbox in any way you can imagine. If this triggers any sub, you will see that, because code will stop at the breakpoint.
This is most straightforward approach I can think of.
I have experienced the exact same problem as mentioned in this post.
Excel thinking cells are locked when they aren't
I tried to ask for clarification by responding / reviving the thread but it appears this is not the correct protocol. I only came across this post after numerous search string searches and this is the only relevant "hit" I could find.
My spreadsheet is similarly complex and has been running flawlessly through Excel 98, 2003 and 2010. When I use Excel 2013 (and I believe same problem happens with Excel 2016) I find cells which are unprotected (for data entry) become locked following use of a macro button, typically navigating to view a graph and then returning. Properties of the cell confirms the cell is not protected.
Reading the above post and the Microsoft links, I have only a shallow understanding of the problem i.e. SDI / Single Document Interface.
The above referenced post received a solution that was acknowledged as having resolved the issue. Perhaps I did not fully understand but no matter where I placed the code snipped it did not help me.
The code offered was:
Private Sub UserForm_Layout()
Static fSetModal As Boolean
If fSetModal = False Then
fSetModal = True
Me.Hide
Me.Show 1
End If
End Sub
There was another suggestion to try: MyForm.Show False I did not know where to pace this similarly to the main suggested code to resolve.
VBA did not like me using "Me" (Me.Hide / Me.Show 1). I tried place the code snippet in several places ... the main opening macro, the navigation macro to and from the sheet that is affected, changing "Me" to the sheet name all to no avail. It is a sheet but since the unique variables are gathered here, it may loosely be viewed as a "Form".
I used to be a competent amateur but never an expert. I am appealing for a kind person to help direct me to overcome this "Excel 2013" problem. I have tried and failed many times and spent many hours trying to fix only to find the problem is because I'm using Excel 2013. There are even now no issues using Excel 2010 which I am able to access via a friend.
I'm sorry my first post is so detailed and hopefully not over-complex. I only wanted to give the correct information about the problem.
I recently took a large, stable XLSM file, and split it apart into an XLAM and XLSX. Thousands of cells in the XLSX call (udfs) functions in the XLAM, and each such udf begins with the statement "Application.Volatile" (overkill, to force recalc).
The XLSX will NOT recalc with F9 thru Ctrl-Alt-Shift F9, nor with Cell.Calculate thru Application.CalculateFull. The XLSX cells are simply "dead" ... but ... I can reawaken them one by one if I hit F2 to edit the formula and then hit ENTER. Cells reawakened this way seem to stay awake, and recalc normally thereafter.
Has anyone encountered this strange behavior and are there any additional ways to force Excel to reconstruct the calc graph from scratch that I should try ?
One additional note in case it matters: I opened the XLAM and the XLSX via File Open, and have not installed the XLAM using the File ... Options ... Addins route - because in the past when I have done so, the minute you "uncheck" and installed XLAM then all the UDF references get replaced by full pathname links - pretty ugly. Alternatively if someone can outline a workaround for installing XLAM addins that doesn't create broken links everywhere I'll go with that.
This works:
Sub Force_Recalc()
Cells.Replace What:="=", Replacement:="=", LookAt:=xlPart, SearchOrder _
:=xlByRows, MatchCase:=False, SearchFormat:=False, ReplaceFormat:=False
End Sub
Figured it out - not sure why Microsoft has this "feature":
The condition arises when a virgin XLSX that uses an XLAM function is opened / created prior to opening the XLAM. In this case no amount of cajoling will cause the XLSX formulas to bind to and execute those XLAM functions, UNLESS you go into each cell & touch the formula bar & hit ENTER (or, as I discovered, do so en masse via a global replace - in my case all the funcs began w a "k", so globally replacing "k" with "k" fixed the error). The problem does not occur if the XLAM is opened first.
For UDFs who can access to Application instance could use:
Application.CalculateFull()
MSDN source here
You can force recalculation in this situation by search and replace on the = which is at the start of all formulae. You can also make this into a macro and map it to a key combination.
Edited to add
See the macro Greg Glynn has in his answer.
One possible solution: Set calculation mode to manual, then back to automatic
Application.Calculation = xlCalculationManual
Application.Calculation = xlCalculationAutomatic
Press CTRL+ALT+SHIFT+F9
This may recalc more than wanted, but it updated my UDF.
(Source)
Here is what I found. I haven't tested it but I believe there may be a work-around.
This is a direct quote:
"Excel depends on analysis of the input arguments of a Function to determine when a Function needs to be evaluated by a recalculation. "
from http://www.decisionmodels.com/calcsecretsj.htm
Here's what I'm going to try later today.
I am going to generate a specific address of a table, dynamically within my function.
Based on why we're here, I should not get an update should the value at the calculated address change.
By including the whole table as a parameter, even without using the parameter, the function should update if anything in the table changes.
In this way, your function hits the dependency tree regardless if you actually process the whole table.
My screen shot:
I had the same problem. Find and Replace works, but not very nice. My solution is:
go to Data tab > Edit links > Click Open Source will resolve this
Excel will monitor the range mentioned in the formula for any change, I faced this today and I was thinking and realized that. So to fix it, make a dummy argument in your function which takes the range you want to monitor or create a dummy function. In my case I called it monitorRange which returns nothing
Function monitorRange(rng As Range)
End Function
and I mentioned it in my formula example
=myfunction(a,b) & monitorRange(RANGE_TO_MONITOR)
This worked very well and it should work with any other function
Ice ages after the original question, but ran into a similar problem just today where I had created a UDF to determine which values of a pivot table filter were selected. The UDF would work fine in when running in macro editor as well as when directly updating the field where the UDF was used, but would throw a "#VALUE!" when updating the sheet or pivot table.
It was killing me until I incrementally added content from my original UDF to Ali's simple monitorRange function. I then found that my UDF had a pivot table refresh statement that when removed eliminated the "#VALUE!" error. Below is the specific offending lines from my UDF, but I the general rule is that the UDF cannot have any code in its call chain that updates other workbook content. That is, the UDF must only GET values, NOT SET values.
I verified this with the following two scenarios, which both cause this error:
Refresh a pivot, e.g.: pt.PivotCache.Refresh
Change a value of another cell, e.g.: Range("AA1").Value = "Test"
Strangely, I tested and found that it is absolutely okay (kinda cool, actually) that the UDF can include a MsgBox call to display a dialog without problem. This would allow a UDF to monitor a range, then popup a msgbox dialog for any condition you wish to include in the UDF. I will keep that in mind for other situations.
Hope this helps others running afoul of this nasty litter issue.
I've tried the above solutions.
The problem is, calculating all the formulae in the file takes too long when you have thousands of formula.
I tried the following solution, and it works.
In VBA Editor, set the object to Workbook, and procedure to SheetChange, and paste the following.
Private Sub Workbook_SheetChange(ByVal Sh As Object, ByVal Target As Range)
Target.Calculate
End Sub
I was having the same issue...I found (in another post) that adding Application.Volatile to the function code made it calculate with the spreadsheet (f9)