 Corin 2 discussion posts
|
I'm trying to set up triggers for "message" windows in Outlook, meaning when I open a specific message as a new window or reply/create a message. Due to the way Outlook re-uses windows handles, I'm struggling to get the behavior I want.
Ideally I would like to set it up (in concept) as a "Window Created" trigger to then set the size and location, therefore when a new message window appears it will put it in my specified location but if I choose to move it somewhere else that particular window will stay where I put it. Opening another message would then put the new message in the specified trigger location, but leave the previously opened message where I had moved it. I will often open 2 or 3 different message windows and move them around to see contents all at the same time. I've reviewed these other discussions that have a lot of great info in them: Focus Event Trigger not just top level Open Outlook on specific monitor How to force app child windows (modal/modeless) to open in the same display It seems that setting my trigger to "Window Focused" and Frequency "Always" manages to overcome the issue with Outlook re-using window handles, however if I move a message to a different location manually, then flip back and forth between windows, that message snaps back to the trigger location. If I switch the Frequency to any of the other settings (Process ID, Process Name, or Once-Per-Window) it rarely ever activates the trigger since, I assume, the same handles are being re-used over and over. Has anyone found a decent work-around to this issue?
May 8, 2020
• #1
|
|
|
I had a thought on this last night, that this could be done with a Scripted Function that polls for new Outlook message windows.
Window Created triggers don't work because they're not actually newly created windows, but we can tell if they're visible windows or not. I've written a script that polls every second for visible Outlook message windows, and moves them if it sees them. It keeps a list of visible windows that it's already seen and moved, so that they won't get re-moved if you have dragged them somewhere else. If a window is closed, on the next script run it will remove it from the list of already seen windows. That way, if you close a window, it gets removed from the list, then the next one you open gets seen as a "new" window. Could you try this out?
Note, this moves to monitor 2 and maximizes the window. If you want to specify a size and location instead, change line 40 from: BFS.Window.MoveToMonitorMaximized(targetMonitor, window); to: BFS.Window.SetSizeAndLocation(window, 200, 200, 800, 600); Hopefully this works for you!
May 12, 2020
• #2
|
|
Corin 2 discussion posts
|
Ooo, that's awesome, seems to be working quite well for my initial testing. This gives me a framework to tweak it for a lot of things as well, appreciate this response very much! Not only did you solve my problem, but you provided a very well laid out script and pointed out options to modify myself. Since I have a C# background, this just opened a whole new world for me, now I'm sure to get myself in trouble...
Also, special kudos for the detailed comments in the script. As a fellow developer, having well-commented code is icing on the cake!
May 16, 2020
• #3
|
|
|
Glad to hear it, thanks for the kind words!
May 20, 2020
• #4
|
 David Son 1 discussion post
|
I enabled a trigger for Outlook focused windows that centers the focused window on the monitor. That works fine. I would also like the ability to move these focused windows without having them snap back to the center of the monitor. However, I don't want the new windows maximized to monitor 2 as described in the above script. I just want them centered as in the trigger. Is this possible?
Another issue I see is that if I click a button in the focused Outlook window header (e.g. "Move"), the drop-down menu also gets centered on the monitor. Is that unavoidable? |
|
|
Hi David,
In the script Keith mentioned earlier, you can adjust line 33 to "BFS.Window.MoveToCentreMonitor(window);" which will center the window on the current monitor, rather then move it. You can also attach that script to a "DisplayFusion Starts" event, rather then a "Window focused", and it should prevent those other issues you mentioned. Hope that helps!
Jun 22, 2021
• #6
|
 Travis Manzer 5 discussion posts
|
This helped, thank you.
20 days ago
• #7
|
| Was this helpful? | |
