I have a userform that is supposed to insert a row on Sheet3 and populate some cells in that row with some values. it works great as long as I have sheet3 displayed. (The form is shown modeless to give me access to the sheets).
Anyway, I happened to have another sheet active and ran it again and was surprised to see it inserted the row not in sheet3, but in the one I had displayed... (Thank God I saved first!)
In the code, I specified a range object as follows to find the insertion point: (I'll truncate the code a bit to keep it simple)
Dim RecordRange As Range
Set RecordRange = Sheet3.Cells(RowVariable,ColumnVariable)
RecordRange.Offset(1,0).EntireRow.Insert
blah blah blah.
A workaround is to activate the sheet first:
Sheet3.Activate
That at least inserts into the correct sheet, but I'd rather not have sheet3 be displayed when I add the record, so I even surrounded that line with:
Application.ScreenUpdating = False
Sheet3.Activate
Application.ScreenUpdating = True
unfortunately, ScreenUpdating doesn't work from within a Userform Code module, so that bites...
I still don't understand why it chooses to insert the row into whatever sheet is active, when I've already specified sheet3 in the code. I have another Macro very similar that doesn't have this problem.
any ideas?
...so you figure your workaround needs a workaround? Hmm... I think that qualifies as a double-negative since a workaround is supposed to, by definition, fix problems rather than cause them...
A workaround is a bypass of a recognized problem in a system. A
workaround is typically a temporary fix that implies that a genuine
solution to the problem is needed. But workarounds are frequently as
creative as true solutions, involving outside the box thinking in
their creation.
Typically they are considered brittle in that they will not respond
well to further pressure from a system beyond the original design. In
implementing a workaround it is important to flag the change so as to
later implement a proper solution.
Placing pressure on a workaround may result in later system failures.
For example, in computer programming workarounds are often used to
address a problem or anti-pattern in a library, such as an incorrect
return value. When the library is changed, the workaround may break
the overall program functionality, effectively becoming an
anti-pattern, since it may expect the older, wrong behaviour from the
library. (Wikipedia)
Just sayin'... :-)
So instead of fixing the workaround, your original issue is (thankfully) straightforward.
You're using Sheet3 as an object, and I suspect you haven't assigned anything (like Worksheets("Sheet3") to an object called Sheet3.
Try this instead:
Dim RecordRange As Range
Set RecordRange = Worksheets("Sheet3").Cells(RowVariable,ColumnVariable)
RecordRange.Offset(1,0).EntireRow.Insert
If you indeed intended to use Sheet3 as an object then make sure it's declared as set, so for example you could instead use:
Dim RecordRange As Range
Dim Sheet3 As Worksheet
Set Sheet3 = Worksheets("Sheet3")
Set RecordRange = Sheet3.Cells(RowVariable,ColumnVariable)
RecordRange.Offset(1, 0).EntireRow.Insert
Also, just to point out: If either of these solves your issue then the problem would've "made itself known", by including one line at the top of every module (at least during development & troubleshooting):
Option Explicit
This link has a short explanation, but basically it forces you to properly declare all variables (thus helping to prevent future workarounds!)
Related
I have been developing a VBA, UserForm1 program for the past few weeks and I have performed numerous test and never once had this problem.
The code, shown below, is part of the Initialization routine. I made some enhancements to the program, far deeper in the code than the code under discussion. Now, I can't get past this point in the program. I replaced "Activate" with "Select", but this did not affect the outcome, i.e., an aborted run.
Please, can someone suggest what I am doing wrong? Or, how can a program that been tested dozens of times, suddenly develop a fault out of thin air?
'======================================================================
Dim WPA() As Variant 'Workbook path for Category Class
Dim WBA() As Variant 'Workbook name for Category Class
Dim WSA() As Variant 'Worksheet name for Category Class
'======================================================================
Dim WBK() As Workbook
..........
Set WBK(S) = Workbooks.Open(WPA(S))
Workbooks(WBA(S)).Worksheets(WSA(S)).Activate 'Activate Worksheet
NWS(S) = CheckSheetExists(WSA(S)) 'Check for Worksheet
..........
Function CheckSheetExists(SheetName) As Boolean
CheckSheetExists = Evaluate("ISREF('" & SheetName & "'!A1)")
If CheckSheetExists = False Then
MsgBox "Worksheet " & SheetName & " does not exist. Run aborted."
End '<==================Run aborts
End If
End Function
It looks like you are using global variables?
If so, you should be aware that they are not as permanent as you might expect.
There are a number of things which cause global variables to reset and become undefined.
See this answer for more info: https://stackoverflow.com/a/7043901/1473412
Using "End"
An unhandled runtime error
Editing code
Closing the workbook containing the VB project
Is it possible that the "enhancements to the program, far deeper in the code than the code under discussion", causes one of these things to happen, and so resets the global variables?
If you have to use global variables, you could store them safely in a worksheet. Or, everytime you try and use one, you could check that it is defined, and if not, redefine it?
That is a good question, Storaxs' answer should have fixed this though to my knowledge.
However when something like this happens I try to create a whole new workbook and paste all of this code into it (just for the sheet in question) and then copy all the cells data into the new sheets.
This has saved me once before and it may help you in this case as well.
I also recommend not deleting your old workbook in case you don't port everything over.
If this still doesn't work let us know and we will continue to look into this.
I have a bug in my excel sheet that appears on other computers I can't reproduce on my machine.
I made a sub that takes data from a database and create tables in Excel. In this case it's mining projects.
It picks the first cell, finds the first empty cell when going to the right, writes the header, makes a table with it then fill it with another sub.
When a coworker tries to use it, it extends the previous table then crashes while trying to make the new one, as two tables can't overlap.
Initial Layout:
What's supposed to happen:
What my coworkers get:
Public Sub creerTable(Nom As Variant)
Dim cellule As Range
' se placer
Set cellule = ActiveWorkbook.Worksheets("DATA").Range("A1").End(xlToRight).Offset(0, 1)
Do While cellule.Value <> "" Or Not IsEmpty(cellule)
Set cellule = cellule.Offset(0, 1)
Loop
'cr?er le header
cellule.Interior.Color = vbBlue
cellule.Value = Nom
'cr?er la table
ActiveSheet.ListObjects.Add(xlSrcRange, cellule, , xlYes).Name = Nom
End Sub
EDIT: After more testing on my coworkers' computers, the problem is likely linked to an Excel setting. When something is written to the right of a table, the table extends to cover it. Googling revealed this to be an auto-correct behavior. I guess I'll have to deactivate that option of auto-correct.
The answer was really dumb. The problem is an autocorrect setting in excel. All I had to do was add this line:
Application.autocorrect.AutoExpandListRange = False
It's not clear how this code could possibly work on your machine, but not your co-workers. I suspect that the inputs must somehow be different, but that is for you (having access to the inputs, which we do not) to work out on your own. Generally: inconsistencies cannot exist, so when one appears to exist, examine your inputs and you'll usually find there is a discrepancy in the input data which causes the divergent output.
I'll note that The End method of range objects may not be reliable, in particular I observed things like Range("A1").End(xlToRight).Address yields "B1" in the following scenario where column A, B and C are each separate ListObject tables:
And ALSO in this scenario:
It seems like you try to find the next empty cell/column (which may be between two or more non-empty cell/column). It should be trivial to do this, but we need to understand that next is relative to what existing thing on your worksheet?
Are you're trying to find the next empty cell after a ListObject named "Tâches" (or cell value = "Tâches")?
Something has changed in my VBA that is not allowing me to complete certain routines. I have listed a very simple example below. If anyone has experienced this I would be really appreciate any support in resolving this issue.
Simple example of issue:
When I use the following code it works fine.
Sheets("Sheet1").Select
Range("B3").Select
When I combine them I get a "1004" error
Sheets("Sheet1").Range("B3").Select
I checked the reference/document library and nothing appears to have changed in here. It has to be something simple but I just can't put my finger on it.
If you absolutely must do it in a single line of code then swap the Select for an Application.GoTo which accepts both worksheet and cell range.
application.goto range("Sheet1!B3")
However, it is almost never necessary (and most often counter-productive) to use the Range .Select method to reference a cell or cells to work on. See How to avoid using Select in Excel VBA macros for methods on getting away from relying on select and activate to accomplish your goals.
You already have your answer:
first Select the worksheet
the Select a range on that worksheet
Your code will work if you happen to be on Sheet1 when it is run, but will fail if you are not on Sheet1. In my opinion VBA is kind of dumb with regard to this issue.
I’m posting this in the hope that it might help someone else, as none of my searches revealed any information regarding this.
I ran into this while building a procedure that would copy an imbedded form shape, and paste it on the same sheet, then run a renaming scheme that would facilitate referencing either of these shapes
This should be simple enough, but I was running into an intermittent problem. Eventually I came to realize that Excel appears to “remember” the shape’s original name at the time of its creation, and keeps it flagged as being in use, releasing it only when the shape is deleted. So if you rename the shape, you can never return it to the original name. E.g., if you rename “Button 1” to “Btn1”, you can never change it back to “Button 1”. Interestingly, you can now reference the shape by either name, “Button 1” or “Btn1”.
In the macro below, assuming “Button 1” is the creation name, s.Name will end up as “Btn1”, even though it looks like it would return to “Button 1”.
Sub RenameShape()
Dim s As Shape
Dim nm As String
Set s = ActiveSheet.Shapes("Button 1")
nm = s.Name
s.Name = "Btn1"
s.Name = nm
End Sub
I have since come across a couple of links that talk about the shape’s “internal” and “external” names – I’m assuming the “internal” name is the inaccessible one that Excel won’t forget, while the “external” name is the exposed name that one normally sees.
I’d be interested to hear from anyone who can shed more insight into this.
As the main purpose of this post was to pass along information, I'm going to make this an answer so it can be closed.
I am writing a fairly lengthy macro in Excel VBA. I want to use named ranges instead of specifying it in the macro. This macro is intended for long-term use. What happens if the range shifts by another user? How can I adjust my code so my named ranges can accommodate for changing positions?
I (personally) hate named ranges. Especially, when you are copying or pasting sheets / ranges from one file to another you always end up with dead-references or copied over named ranges which do not work anymore or got renamed (because they existed already in that file).
My solution to this is one of the following two:
(1) I dedicate a certain part (or even module) in the VBA to declaring my ranges in global variables. This is very similar to the Dim of all variables at the beginning of each sub.
'*********************************************************
'** Declaring all ranges and where to find which data
'*********************************************************
Dim rngNamedRangeName As Range
Sub SetupAllGlobalVariables()
Set rngNamedRangeName = ThisWorkbook.Worksheets(1).Range("A1:C10")
End Sub
'*********************************************************
'** After that all your normal subs follow and whenever
'** necessary you can call the above to get your ranges
'*********************************************************
Sub ExampleCodeToFormatYourRanges()
Call SetupAllGlobalVariables
With rngNamedRangeName
.Interior.ColorIndex = 36
End With
End Sub
(2) Yet, my preferred second solution is to have a separate very hidden sheet where I reference / link all the ranges (which are important to me) again. So, basically, I have in this separate sheet all the "important" data again. This would be your named ranges. But nobody is allowed to touch this sheet (that's why its very hidden). If any of your ranges get shifted or changed then it is easy to re-link the ranges on this hidden sheet with the other sheets again. Yet, on the hidden sheet all data is still in the same spot and allows you to hard-code all ranges in your VBA (taken from the hidden sheet only).
Even non-VBA programmers can normally fix such things with the second method. With the first method you'll probably always need someone with VBA skills to fix it.
Note, the above is not the one and only solution nor might it be the best solution. But I can certainly say that this has proven to be a usable solution even for larger corporations.