Save up to 50% off any of our desktop apps in our 2021 spring sale, including
DisplayFusion, ClipboardFusion, FileSeek, LogFusion, TrayStatus, and VoiceBot!




<< DiscussionsReply

Automatically run Window Position Profile on application start

7 discussion posts
I have a Window Position Profile (wpp) already setup with a hotkey and it works as expected when using the key after opening the app.

I'd like the profile to run when I start the app, which opens a default document with 3 separate windows. A huge bonus for it to run whenever I open an additional file in the app, which opens an additional set of 3 windows.

FYI, and for search engines, I'm using Propellerhead Reason 11 which does a beyond terrible job of following Window 10 conventions about window positioning.

[edit] After some experimentation, I've edited the post.
Nov 2, 2020 (modified Nov 2, 2020)  • #1
Owen Muhlethaler (BFS)'s profile on

If you head to the Triggers tab in Display Fusion, you should be able to do this. You can use the "Window Created" event, select the application, and then run the function to load the window position profile.

If you need any help setting it up, just let us know.

Nov 3, 2020  • #2
7 discussion posts
Doh I missed `Edit Trigger` window > `Add` > `Run Function` > `Load Window Position Profile`.

And the window names in the WPP were quoted and very specific, so it wasn't triggering on subsequent loads.

Working On It. . . standby.
Nov 3, 2020 (modified Nov 3, 2020)  • #3
7 discussion posts
Alright, after fiddling with it, I now have a trigger

It runs the Window Position Profile after the application has been started

It does not trigger on application start, only when loading additional documents.

I have duplicated the trigger with the following attempts

* using the same trigger text (same window)
* different trigger text
* very specific trigger text ("Document 1" is the default document name, which worked before, but not on loading documents)
* setting a high `Delay` (10000ms which is well beyond completion time)
* triggering on `Process Created` with high `Delay`.

Thoughts on getting this?

Thanks in advance.
Nov 3, 2020 (modified Nov 3, 2020)  • #4
Owen Muhlethaler (BFS)'s profile on

So it's working with additional windows, but not the main window on bootup? Have you tried settings the application to "All Applications (*.*)", and then setting the window text, to the text of the main window?

Let me know how that works!
Nov 3, 2020  • #5
7 discussion posts
That's not quite right. Here's the full deal. . .

Each Reason document (music program) has 3 windows:

* Sequencer (Title: `filename.reason`)
* Mixer (`filename.reason (Mixer)`)
* Instrument rack (`filename.reason (Rack)`)

default document

some other document

All document titles, default or otherwise, are as the bullet points above.

Here's the WPP that I have a trigger for a `Process Created` trigger with a 10s delay. (app takes 6-7s before it's ready)

It runs on start but the windows are not in the right place. Same when I use the hotkey.

Just to see what it's doing, I then did Window Position Profile > New Profile and it shows this. (this is just an example profile, unsaved)

As you can see in the first pic, the Mixer is not selected to be maximized, yet it's doing it anyway.

Here's the WPP I had that was working (past tense) with subsequently opened documents after the app had been started.

Final result:

Using the "Startup" WPP hotkey performs the action with the default document, but the windows are wrong as stated above, even tho the window coordinates match the "document" WPP.

The "document" WPP does not trigger when opening a subsequent document, with a 3s delay after the last window opens (this used to work). The hotkey for this WPP works with subsequent documents, but does nothing with the default document, even tho the window name filter matches?... Should match?
Nov 3, 2020 (modified Nov 3, 2020)  • #6
7 discussion posts
After that post:

I created a new WPP based on the wonky startup result and modified the boxes and coords to be correct. This new profile also puts the window in the wrong place.

I added a new trigger, using the new profile, setting it to "Any Application" and to call the new WPP based on the wonky startup. The result was the same.

Default documents continue to ignore the 'document' hotkey. The hotkey I added to the 'wonky' WPP activates, but gives the same wonky result.
Nov 3, 2020  • #7
7 discussion posts
Alright I did this:

I changed the default document name text filter to be a bit more broken up.

I was thinking that perhaps the Mixer window was being caught somehow by the Main window action. So I created a 2nd WPP specifically for the mixer, and then put both in the trigger. The result was that the Mixer window did it's full screen thing again, AND THEN popped to it's right position.


That's when I broke everything out to that pic. And now it works.

I fumbled around with the trigger for subsequent docs. At some point earlier today (but after it was working y'day) I set it to `Stop processing triggers`. In case it matched the default doc, I didn't want it to run again. Since I have the default doc profile so specific, I turned that off.

At that point, the WPP for subsequent docs worked, but if there were multiple docs open (x3 windows), some other documents windows would be brought to the front. If I then used the hotkey, it would bring the one I wanted to the front. With the 2nd WPP profile action in the trigger, the trigger brings the wrong set to the front then the right set. It's wonky, but it works.

End result:

When starting the program, the default document opens and then all the windows move to their desired position.

When opening a subsequent document, the trigger runs the WPP profile twice with all windows in their desired positions.

Woohoo I'm smart.
Nov 3, 2020  • #8
Owen Muhlethaler (BFS)'s profile on

What a rollercoaster to read! Glad to hear it's working now! If you have any other questions, feel free to reach out to us.

Nov 4, 2020  • #9
Was this helpful?    
<< DiscussionsReply