I have a bunch of VB script in Excel that ultimately opens up a new Word document and places a bunch of information in it. Everything works well, but I am having one annoyance. The annoyance is that sometimes the Word document will open in front of everything else and sometimes it will open behind everything else.
I have tried duplicating the results and it appears to be random. Sometimes I think there is something consistent as to why it does it and then something happens so my theory doesn’t hold true. I must have generated the Word document over 100 times trying different stuff and can’t seem to figure it out.
I do have three monitors, running Office 2010, and Windows 7. I am not sure if the three monitors would have any affect as to why it isn’t consistent.
What I want is for it to be visible in front of everything when it opens.
This is the code I am using to make it visible and I tried it at the end, the beginning, and then at both the end and beginning of where it creates the document:
wrdApp.Activate
wrdApp.Visible = True
Anybody have any suggestions?
What I want is for it to be visible in front of everything when it opens.
No need for APIs for this.
Instead of this
wrdApp.Activate
wrdApp.Visible = True
Use this
wrdApp.Visible = True
wrdApp.Activate
You can't really activate it if it is not visible. Also ensure that the last line in your macro before you destroy the object is wrdApp.Activate. You wouldn't want the wrdApp to loose focus because of any other code...
Related
When I run a series of macros eventually excel loses focus and stops updating the screen this can occur looking at the screen or especially minimizing and doing something else on the computer. It can only be fixed by double clicking somewhere scrolling around maximizing and minimizing... but I can't seem to accomplish it in VBA I would hate to have to make an external macro to click into excel just to make the screen refresh.
Are you asking to see everything happen or do you want to just let it run and come back to it? You can use the code Application.ScreenUpdating = False to prevent the crazy jumping excel does and just come back as normal.
Every once in a while, I will find that somehow the Application.EnableEvents property gets set to false, requiring me to manually set it back to true in the VBE's Immediate window. The mystery to me is that it is set to false without a VBA error being thrown. Had an error been thrown, I wouldn't have questioned it as much.
Can any of you help me out with possible causes to this? For now, I have no leads.
Contextual information:
I have not been able to reproduce the error
Nowhere in my code am I changing Application.EnableEvents
All of my code relies exclusively on events, I don't have any UDFs that I call within worksheet cells
From what I remember, the VBE was open every time, so I was probably actively developing at the time of the failure.
Thanks,
Add a watch on Application.EnableEvents, ensure it is global so set Procedure to (All Procedures) and Module (All Modules) . Change the Watch Type to Break When Value Changes
Make sure your code is unlocked. Then run your applciation, the code should should stop on each line when the value changes. This way, you can double check your code acts as intended.
Incidentally, you an use the RAII design pattern to manage these Application settings. The code here uses a RAII design pattern to manage the status bar Essentially the RAII pattern uses a class and utilizes the destructor to reset a setting.
This setting should never change on its own. I would check to see if you have another workbook open that is modifying the setting.
To do this Open the VBA editor (Alt-F11) and see what workbooks are open by looking at the project explorer on the left hand side. Look inside each project for code that is disabling the events.
Also, when you do a search on your project and any other open project, make sure to choose "Current Project" in the find window and search on "EnableEvents" The current project is not selected by default and you may be missing some code in your search you didn't know about like the workbook startup event.
I can't get the name of the workbook when I use a add-in.
I'm trying to develop a add-in that runs each time you open Excel and reads the filename of the open file.
If the file name is XCFIL.SKV then do something...
This code should do it, but it doesn't. What am I missing?
The code stops and if I debug and press F8 it works fine, but it won't run on it's own.
Private Sub Workbook_Open()
If ThisWorkbook.Name = "XCFIL.SKV" Then
MsgBox "y"
End If
End Sub
Background:
Based in this statement The code stops and if I debug and press F8 it works fine, but it won't run on it's own. I assume the problem relies on the speed of the processor that is not sync with the code (own experience).
Solution:
Since it is Excel and the problem seems to rely only in the opening of the instance itself, you may use Application wait or any of the other functions for this matter.
Further thoughts:
Life cycle comes to my mind in these kind of scenarios. This web page has a neat Lifecycle diagram of excel instance (attached since I will try to explain the scenario)
As you may see "Application" is the first cycle of the Excel application, followed by "Open" and after that "Workbook" object, it may happen that in this life cycle "worbook" has not been created when "Open" comes to play,hence, you need to wait until excel solves this.
I have been chasing my tail for weeks, with more hours "Googling around than I want to admit.
I have a large, complex analytical app within an Excel 2016 spreadsheet that captures SQL table data, queries email data and does a lot of stuff that I think is pretty cool. Users see sales force automation performance metrics and charts. All is well except for one thing. I cannot stop the "save data?" dialog box from appearing no matter what I do.
As a workaround I've put the spreadsheet on on a network ride and given users a shortcut that runs a VBscript to copy this spreadsheet to a hidden drive on the local PC and runs it. So if they save it, there's no worries as they aren't working with the original data. But as one would easily imagine, the load time is necessarily longer than it need be and users are confused by a message when I am telling them they can't save the data.
Net of a lot of different experiments, it seems like I've uncovered a bug in Excel (yeah, I know, this sounds lame even to me) as I cannot make the Application.DisplayAlerts = False. It just will not take.
See image here:
enter image description here
The image above (or at the above link as I haven't submitted enough question yet to embed images) is obviously taken from the Immediate Window when I was running the app. I entered the steps in the exact order shown. Note that I set Application.DisplayAlerts = False and then checked the value immediately afterwords and it was True.
Very weird. Is this a bug?
One last aside that is probably irrelevant; I was using .XLSB format because of the smaller footprint, much shorter load time and to get around PC setup issues with macros. But I've switched back to .XLSX to simplify the experiment.
To clarify: the code temporarily halts after each single-step in the debugger, resulting in Excel setting it back to True while idle. Here’s a way to verify this behavior:
In the VBE code-development window, open the Immediate window (Ctrl-G).
Temporarily insert the following code somewhere in your routine:
Debug.Print "..."
Application.DisplayAlerts = False
Debug.Print "Application.DisplayAlerts: " & Application.DisplayAlerts
Stop
Using the “Set Next Statement” tool (or Ctrl-F9), set the Debug.Print "..." statement to be the next one to execute.
Run the code form there by pressing F5 (Continue).
You should see this displayed on the Immediate window:
...
Application.DisplayAlerts: False
Now, with the code stopped at the Stop statement, type “?Application.DisplayAlerts” in the Immediate window, and press the [Enter] key. You will get:
?Application.DisplayAlerts
True
because Excel has reset it to True while the code is suspended.
Remove the experimental code.
I have a VBA form that when I click on it, performs some long calculations (a few seconds to several seconds long) and then displays the results on frames in the form. However, once every so often, the form hides on me and I need to click around to the VBA editor and back to the sheet to make it display again
I have
Me.Repaint
at the end of the calculations on the form
but it still doesn't help
I also tried disabling the "EnableCalculation" attribute of the main sheet, but still no use
Anyone ever run into something like this? Do I need to load the form in some special way?
I have had the same problem. When saving an Excel workbook by clicking on a command button on a modeless Userform, the form disappears as the code completes.
I read that the problem was due to some inter-compatible changes that Microsoft has made and found some very elaborate solutions involving a lot of complex code that I was unable to integrate into my project. However, I did find a very quick workaround.
In my case the Userform only disappeared when the code executed the End Sub command of the command button's code. I simply added an Exit Sub immediately before it and the Userform no longer disappears.
Have you tried turning off and on screen updating so Excel is not redrawing the screen with each change.
sub doSomthing()
Application.ScreenUpdating = False
'do something
Application.ScreenUpdating = True
end sub
The form disappears because Microsoft has changed the model by which forms are owned by a 'superior' process (Excel in your case). I have the same problem and also cannot overcome it.
Just sit tight until Microsoft decides that it is worth their effort to fix yet another introduced and untested problem by making changes to something that already worked.
The problem is a side effect of the SDI (Single Document Interface) that was introduced with Excel 2013. The various suggestions that invoke DoEvents, ScreenUpdating, etc. may help in certain scenarios, but they do not cure the behavior.
There is a full solution posted here: Keeping Userforms on top of SDI windows in Excel 2013 and up
If that is too involved for your needs, a quick-and-dirty solution is to minimize and restore the active window, which forces the userform back on top of the stack.
'Do long-winded process first, then:
Application.ScreenUpdating = False
ActiveWindow.WindowState = xlMinimized
ActiveWindow.WindowState = xlNormal
Application.ScreenUpdating = True
This doesn't prevent the form from disappearing, but it makes it reappear the end of the process.
Try experimenting with the following two lines of code instead of the repaint.
Me.Show
And/Or:
Me.SetFocus
Hopefully, one of these will work for you!
In my case I had to use all these to make it happen. (frmGUI is my form)
DoEvents
frmGUI.Repaint
frmGUI.Show
With Office 2013 and Windows 7, simply adding DoEvents right before the end of the sub (where the form disappeared) kept the form open. Nothing else needed....for my situation.