I am trying to run an AHK script to open/show/minimize teams depending on the state of the app. I currently have the same functionality work for the windows calculator, but when I copy/paste the same solution, AHK fails to run teams. Currently, this is what I am working with
F11::
If WinExist("Teams ahk_class ApplicationFrameWindow")
{
IfWinActive
WinMinimize
Else
{
WinGet, winState, MinMax
If (winState = -1)
{
WinRestore
WinActivate
}
}
}
Else
{
run ahk_exe Teams.exe
WinWait, Teams
WinActivate
}
return
however, it seems line 24 (run ahk_exe Teams.exe) is causing the issue. When I run windowSpy, I get the following:
When I replace ahk_exe Teams.exe with ahk_pid 6440 I get the same issues. Has anyone else had this issue and found a way around it?
I feel like some of these terms need to be cleared up a bit:
ahk_exe is the name of the executable file (i.e. .exe) that the process is associated with. Normally, just using the run command generically with the name of this file would do nothing, as AHK has no idea which folder this .exe is in. This just happened to work with the Windows Calculator app [calc.exe], since that was a program that Windows allows you to run anywhere you want. The solution is to tell ahk which folder the .exe is in so that it can run it.
If you want to test whether or not a specific program parameter for the run command will work properly, you can open up a command prompt window and try the command, replacing AHK's run with the Commandline's start [ex: run calc.exe becomes start calc.exe].
Additionally, ahk_pid is not a constant number that persistently associates with a program. In fact, every time you run a program, even if it is the same exact program, Windows will assign a new PID to it every time. Futhermore, because a new one is assigned after the program is launched, we cannot use it to initially launch a program.
Important!: This code immediately below is unsafe and can corrupt your installation of Teams. Please see Update 1 for more info and a better alternative.
Here is a solution that launches the Teams app (Teams.exe) from the default installation location in C:\Users\[YOUR USER NAME HERE]\appdata\local\Microsoft\Teams\current\Teams.exe
run "%LOCALAPPDATA%\Microsoft\Teams\current\Teams.exe"
Hope this was helpful. If you have any additional questions, please lmk
Update 1:
While looking back at my original solution, I found out that directly running the Teams.exe file was not a good solution, as it has the potential to corrupt the installation of Microsoft Teams (which happened to me). As such, in order to run Teams the way the developers intended it to, I am opting to run the Program's shortcut file (i.e. the "Microsoft Teams.lnk" file in the %AppData%\Microsoft\Windows\Start Menu\Programs\ folder). Upon inspecting this .lnk file, I found that it contained additional logic and calls to MS Teams' Update.exe file that help prevent these issues from occurring. So, the new Run code to start MS Teams would be
run "%AppData%\Microsoft\Windows\Start Menu\Programs\Microsoft Teams.lnk"
With that out of the way, we can now integrate this new run command back into OP's program. From what I could understand of the original code, these were the objectives OP was trying to code (if any of these are incorrect, please lmk and I can update):
If Teams is running and the currently active window, minimize it.
If Teams is running, but not the active window, make it the active window
If Teams is not running, run it and make the active window once it opens.
So, we can effectively boil down the logic to be something like this (in pseudocode):
If Teams is running
If Teams is the Active Window
Minimize Teams
Else (i.e. Teams is NOT the Active Window)
Make Teams the Active Window
Else (i.e. Teams is NOT running)
Run Teams
Wait until Teams is done opening
Make Teams the Active Window
Let's start with the code to detect if Teams is running. Currently, the source code uses this to try to detect is Teams is active: If WinExist("Teams ahk_class ApplicationFrameWindow"). Ignoring whether or not this syntax is correct (I've never seen both a WinTitle and ahk_class parameter used in the same "" block for WinExist), using the ahk_class, at least in this case, might not be the best option available. In the the Windows Spy screenshot that OP kindly provided, we can see the ahk_exe of Teams.exe would be much more specific than the ahk_class of Chrome_WidgetWin_1. As such, can use If WinExist("ahk_exe Teams.exe") instead for this program to detect if MS Teams is already running.
The next thing I want to touch on is that when Teams is "closed" i.e. by clicking the X button in the upper right corner of the screen or even when closed using the WinClose command, it's default behaviour actually minimizes it to the tray, from where the WinActivate command can be used maximize it, similar to how it would be if it was instead minimized to the taskbar by clicking the - button instead. As such, depending on personal preference, you can have Teams either minimize to the taskbar or minimize to the tray and still work the same functionally with the rest of the program. Although this was not a requested or mentioned feature by OP, I feel like this is still a useful behaviour to mention/ include in this response.
Next, the original code that the original script was using to Activate a non-active but still running MS Teams was as follows:
Else
{
WinGet, winState, MinMax
If (winState = -1)
{
WinRestore
WinActivate
}
}
While the additional checks and logic that OP implemented could be useful in some scenarios, I feel like it could effectively be shortened and replaced with just a simple
Else
WinActivate
The last change I made that deviated from the original script was just the bit that ran Teams if it was not already open. I feel like I've already discussed the changes enough above, but in summary: run ahk_exe Teams.exe was replaced with run "%AppData%\Microsoft\Windows\Start Menu\Programs\Microsoft Teams.lnk"
Final Code:
F11::
If WinExist("ahk_exe Teams.exe")
{
IfWinActive
WinMinimize ;Use this if you want to minimize Teams to the Taskbar
;WinClose ;Use this if you want to minimize Teams to the Tray
Else
WinActivate
}
Else
{
run "%AppData%\Microsoft\Windows\Start Menu\Programs\Microsoft Teams.lnk"
WinWait, Teams
WinActivate
}
return
This was a bit longer than usual, but I hope this was helpful. Once again, if you have any Questions/ Comments/ Concerns, or just want more clarification, feel free to ask.
Related
I am trying to automate an installation that starts out with an InstallShield setup.exe. That kicks off the installation of a MS Visual C++ redistributable. That leads to an error about Adobe Flash not being up to date. I have asked about how to deal with that here:
Error during automated software install using pywinauto
Once I click OK for the Adobe dialog(have to use pyautogui.click() for this for now) I see that there is an .msi being extracted. I have followed the install and it puts it into a new Temp folder under my Users\AppData directory.
How do you get pywinauto to find this new application? I have tried using
adobe = Application().connect(title_re="MyInstaller",class_name="#32770", visible_only=True)
And then try to print_control_identifiers() but get this error:
AttributeError: Neither GUI element (wrapper) nor wrapper method 'print_control_identifiers' were found (typo?)
I have checked Spy++ and Inspect and AutoIT to find the class which I can. I can't use the procid as it will always change.
Any thoughts on how to attach to the .msi process so I can then connect() to it?
Edit:
Is there a way to regex pywinauto to point to a path if I know where MyProgram.msi is? It seems to be in C:\Users\me\AppData\Local\Temp{xxx}\MyProgram.msi as I found several copies there. Thanks!
Add timeout=10 or whatever you need to connect() params. Current default timeout is zero, but it should be timings.Timings.window_find_timeout which is 5 sec by default.
Auto detection of spawned child process is planned for next major release (as well as default timeout fix).
For running an unpacked .msi file you need msiexec standard Windows command in method .start(). Play with it in cmd.exe manually first starting from msiexec /?.
Here is how I deal with the fact that InstallShield exe extracts to an .msi in (into my DownloadedInstallations folder). Yes, timeout is important, but also identifying the new msi window that opens is too. (Also, I found that wait_for_idle had to be FALSE but don't remember why. YMMV :) ).
exe = pywinauto.Application(backend="uia").start(exepath, wait_for_idle=False)
Now it's going to unzip the .exe into .msi installer and that could take a while, and since the .exe window might be named the same as the .msi window must be careful not to attach to the exe window too early and must wait for the .msi window to open!! So, add an appropriate timeout in seconds. The dialog window may not exist yet here, so it's CRITICAL to use class_name of MsiDialogCloseClass especially if the title of the exe and msi are the same. This will identify the .msi window specifically, whenever it arrives.
title = "Enter Title of your App - InstallShield Wizard"
msi = pywinauto.Application(backend="uia").connect(title=title,
class_name="MsiDialogCloseClass",timeout=120)
And for the final touch, in a line I always forget, must use the title again to get the dialog window (for reasons I don't yet understand)
dlg = msi[title]
EXTREMELY HELPFUL way to view all control identifiers at this point is:
print(dlg.print_control_identifiers())
This is what hours of trial and error yielded. To continue on, now you can click buttons, like this:
dlg.Next.wait("ready",timeout=2)
dlg.Next.click()
And to click on radio buttons, this works (there may be other ways that do, but I could never find how to get a handle on the buttons by name)
dlg['I &accept the terms in the License Agreement'].wait('enabled').click()
Then moving on
dlg.Next.click()
dlg.Install.wait("enabled",timeout=5)
dlg.Install.click()
I am developing a little app that works with excel books, when I run it, it opens a excel book, I ran this code in windows 7 and the excel app was shown in task manager but I ran it again in windows 10 and a it was not shown in task manager.
I want it to be shown in task manager because sometimes the code crashes so I need to close the app from the task manager. I think it is a problem related to SO.
Do you know how to solve it?
enter image description here
enter image description here
enter image description here
Open Powershell as admin and type get-process. Verify that the Excel process is running, and type stop-process -Name Excel and press enter.
Good to go.
I bet you're looking at the Applications tab, not going to the Processes tab.
Press Ctrl+Alt+Del . (an alternative is Ctrl+Shift+Esc on many systems.)
Click Start Task Manager
Click the Processes tab. (#1 in the image below)
Click the Row Heading Image Name (to sort the processes alphabetically) (#2 in image)
Scroll down (#3) the list of images until you get to the 'E' section.
If Excel is running, you will see at least one process named EXCEL.EXE (etc)
If you still can't find it, please take a screen shot of the Processes tab, and add it to your question, along with more of an explanation of why you think it should be showing.
Remember that the best way to remove all running processes and "refresh everything" is to reboot. Every computer should be rebooted at least once a day -- or much more often than that when troubleshooting buggy programs. Or in your case, Reboot every time Excel crashes.
More Info:
Task Manager (Windows)
Finally, I solved it, I just had to update the task manager by pressing the key F5 each time I run a new program, I think it is a bug.
Anyway, Thanks for your help.
Intermittent Failures with webdriver.js
I am creating some webdriver.js* scripts to automate some time consuming test setup activities. However, when I run the script and do other things with my keyboard and mouse, I come back and find that, intermittently, a particular element cannot be found. And it's a different element each time.
When I run the same scripts and just watch them run, the scripts execute correctly.
Also, when I researched this potential problem, I came up with lots of stuff on using the mouse in webdriver scripts and problems with the click method itself but couldn't find anything to do with my issue. So I'm wondering whether I'm just doing something wrong here.
So What's The Question?
My question is: Is webdriver.js not meant to run like this? (that is, run locally while the keyboard and mouse are doing other things)?
Webdriver.py?
I don't remember having these problems when I used webdriver.py a few years back. iirc, I was able to run the scripts while the workstation was locked (via Win + L) though my memory isn't what it used to be ;)
I would use webdriver.py, however, no one else in our team knows python so I thought I would go webdriver.js since we all know javascript :)
Params: IE11, Windows 10.
* Also, when I say "webdriver.js", I mean the webdriver that is installed after following the steps here
I found that if I replaced the .click() calls with an equivalent .sendKeys() call (e.g. webdriver.Key.ENTER / webdriver.Key.SPACE) , this would get around the problem. I could even lock my workstation and the scripts would run without any problems.
I feel like I have been coming the internet for days with absolutely no result.
I have taken some web programming classes, and would like to learn some python, just because programming is wicked interesting altogether, and have run into a fairly large hurdle given my experience.
the problem is this: Python.exe (or is is more properly pythonw.exe?) v3.3.3, running on windows 8.1 used to launch fine. Typed up a simple program to roll various sided die, worked out well. Then I changed the key bindings for 'Run Module' from 'ctrl+f5' to 'crtl+alt+spacebar.'
As soon as I did this IDLE crashed and so did the shell. Now the process will not run AT ALL. I cannot access it through the desktop icon to go back and revert the settings. I also attempted to look at the .def files and change it from there but could not find the 'run module' command. It looked like all the key bindings in the .def files were for the shell.
When I double click, nothing, when I run as admin, nothing. run from the start menu, nothing. I uninstalled and re-installed, rebooted, everything low tech I can think of. Now i'm out of my element and could use one of you brilliant social programmers!!
I've found information about checking with some tool called 'Windows Process Manager' some stuff about what to do with the CMD prompt (something about a path problem ...it intuitivly sounds like I very well could have created a 'path problem' but I'm not 100% I know what that is exactly).
I'm sorry for the lack of links, the pages were farther back in my browsing history than I expected. Hopefully i'm not asking an instant many down vote question here, most of the resources online are for either an older version of windows, Lunix, or an older version of python (which is actually where the path problem hint came from)
Thanks any and all greatly for any time spend reading/answering.
Immensely appreciated.
Find file HOME/.idlerc/config-keys.cfg, where on Win7 HOME would be 'C:/Users/yourloginname', and delete the key binding or, if there is nothing else in the file or nothing you want to keep, the whole file.
If you were to run Idle from a console with python -m idlelib, you would probably see an error message. (Yes, you were probably running with pythonw, as when using the start menu or icon. This works better in 3.4.2 and I am working or more improvements.)
I do not know the specific reason for your crash. I set Zoom-height to --space, restarted, and it works, no problem.
From what I can see on the web, this is a fairly common complaint, but answers seem to be rarer. The problem is this:
We have a number of Excel VBA apps which work perfectly on a number of users' machines. However on one machine they stop on certain lines of code. It is always the same lines, but those lines seem to have nothing in common with one another.
If you press F5 (run) after the halt, the app continues, so it's almost like a break point has been added. We've tried selecting 'remove all breaks' from the menu and even adding a break and removing it again.
We've had this issue with single apps before and we've 'bodged' it by cutting code out of modules, compiling and then pasting it back in etc.
The problem now seems to relate to Excel itself rather than a single .xls, so we're a little unsure how to manage this.
Any help would be gratefully received :)
Thanks,
Philip Whittington
I have found a 2nd solution.
Press "Debug" button in the popup.
Press Ctrl+Pause|Break twice.
Hit the play button to continue.
Save the file after completion.
One solution is here:
The solution for this problem is to add the line of code
“Application.EnableCancelKey = xlDisabled” in the first line of your
macro.. This will fix the problem and you will be able to execute the macro
successfully without getting the error message “Code execution has been interrupted”.
But, after I inserted this line of code, I was not able to use Ctrl+Break any more. So it works but not greatly.
This problem comes from a strange quirk within Office/Windows.
After developing the same piece of VBA code and running it hundreds of times (literally) over the last couple days I ran into this problem just now. The only thing that has been different is that just prior to experiencing this perplexing problem I accidentally ended the execution of the VBA code with an unorthodox method.
I cleaned out all temp files, rebooted, etc... When I ran the code again after all of this I still got the issue - before I entered the first loop. It makes sense that "press "Debug" button in the popup, then press twice [Ctrl+Break] and after this can continue without stops" because something in the combination of Office/Windows has not released the execution. It is stuck.
The redundant Ctrl+Break action probably resolves the lingering execution.
I found hitting ctrl+break while the macro wasn't running fixed the problem.
I would try the usual remedial things:
- Run Rob Bovey's VBA Code Cleaner on your VBA Code
- remove all addins on the users PC, particularly COM and .NET addins
- Delete all the users .EXD files (MSoft Update incompatibilities)
- Run Excel Detect & Repair on the users system
- check the size of the user's .xlb file (should be 20-30K)
- Reboot then delete all the users Temp files
I have came across this issue few times during the development of one complex Excel VBA app. Sometimes Excel started to break VBA object quite randomly. And the only remedy was to reboot machine. After reboot, Excel usually started to act normally.
Soon I have found out that possible solution to this issue is to hit CTRL+Break once when macro is NOT running. Maybe this can help to you too.
Thanks to everyone for their input. This problem got solved by choosing REPAIR in Control Panel. I guess this explicitly re-registers some of Office's native COM components and does stuff that REINSTALL doesn't. I expect the latter just goes through a checklist and sometimes accepts what's there if it's already installed, maybe. I then had a separate issue with registering my own .NET dll for COM interop on the user's machine (despite this also working on other machines) though I think this was my error rather than Microsoft. Thanks again, I really appreciate it.
I have had this problem also using excel 2007 with a foobar.xlsm (macro enabled ) workbook which would get the "Code execution has been interrupted" by simply trying to close the workbook on the red X in the right corner with no macros running at all, or any "initialize" form, workbook, or workheet macros either. The options I got were "End" or "Continue", Debug was always greyed out. I did as a previous poster suggested Control Panel->Programs and Features-> right click "Microsoft Office Proffesional 2007" (in my case) ->change->repair.
This resolved the problem for me.
I might add this happened soon after a MS update and I also found an addin in Excel called "Team Foundation" from Microsoft which I certainly didnt install voluntarily
I would like to add more details to Stan's answer #2 for below reasons:
I faced this issue myself more than dozen times and depending on project conditions, I chose between stan's voodoo magic answer #1 or #2. When I kept on facing it again, I become more inquistive that why it happens in first place.
I'd like to add answer for Mac users too.
There are limitations with both these possible answers:
if the code is protected (and you don't know password) then answer #1 won't help.
if the code is unprotected then answer #2 won't let you debug the code.
It may happen due to any of the below reasons:
Operating system not allocating system resources to the Excel process. (Solution: One needs to just start the operating system - success rate is very low but has known to work many times)
P-code is the intermediate code that was used in Visual Basic (before .NET) and hence it is still used in the VBA. It enabled a more compact executable at the expense of slower execution. Why I am talking about p-code? Because it gets corrupted sometimes between multiple executions and large files or just due to installation of the software (Excel) went corrupt somewhere. When p-code corrupts. the code execution keeps getting interrupted. Solution: In these cases, it is assumed that your code has started to corrupt and chances in future are that your Excel workbook also get corrupt giving you messages like "excel file corrupted and cannot be opened". Hence, as a quick solution, you can rely on answer #1 or answer #2 as per your requirements. However, never ignore the signs of corruption. It's better to copy your code modules in notepad, delete the modules, save & close the workbook, close the excel. Now, re-open the workbook and start creating new modules with the code copied earlier to notepad.
Mac users, try any of the below option and of them will definitely work depending on your system architecture i.e. OS and Office version
Ctrl + Pause
Ctrl + ScrLk
Esc + Esc (Press twice consecutively)
You will be put into break mode using the above key combinations as the macro suspends execution immediately finishing the current task. This is replacement of Step 2.
Solution: To overcome the limitation of using answer #1 and answer #2, I use xlErrorHandler along with Resume statement in the Error Handler if the error code is 18. Then, the interrupt is sent to the running procedure as an error, trappable by an error handler set up with an On Error GoTo statement. The trappable error code is 18. The current procedure is interrupted, and the user can debug or end the procedure. Microsoft gives caution that do not use this if your error handler has resume statement else your error handler always returns to the same statement. That's exactly we want in unwanted meaningless interruptions of code execution.
My current reputation does not yet allow to post this as a comment.
Stans solution to enter the debug mode, press twice Ctrl+Break, play on, save did solve my problem, but I have two unexpected twists:
My project struture is password protected, so in order to get into the Debug Mode I had to first enter Developer mode, click on the project structure and enter the password.
My project is a template file (.xmtl). I opened the file via double click which opens it as .xml with a "1" at the end of the previous file name. I fixed the bug as by Stans instruction and saved it as that ...1.xml file. When I then opened the template again, this time as template, and wanted to apply the same bug fix to that file, the bug was gone! I did not change this file and still no bug at executing the Macro. This means to me that the bug is not actually in the file, but in a (hidden) setting in Excel.
If it's a phantom breakpoint:
1 Delete the offending line of code
2 Run the code again
3 Repaste the line
I found this laughably simple solution after spending a couple days wading through all the answers here and elsewhere. I figured, if I link it to my original question it might help some other poor chap, since the question it's on is VBA break execution when there's no break key on keyboard and this is more applicable.
Link to original answer
I faced the same issue today. Resolved it with these steps.
Create a new module
Move the procedure that is causing the issue to this new module.
Save project
Run macro again.
This time, the code execution will run till completion without any intermediate stops.