DisplayFusion = HOW TO: Perform Windows Modifications (immediately) BEFORE Window Created?

WARNING: You currently have Javascript disabled!
This website will not function correctly without Javascript enabled.

Zardoz2293

36 discussion posts

I'm getting behavior which is not desired at all. I have split 1.1 and 1.2 and I have many apps which when used I always need maximized to 1.0 (full screen, ignore splits). With DF not running I get this native Windows functionality as expected. With DF running it seems to select one or the other split and never allows for full screen (1.0). If I create a Trigger, Event > Window Created > Run Function: "Maximize Windows (ignore monitor spits)" it DF always crams the app into one of the splits and then moves it to the full monitor.

1. Frankly, this is a concern on 100% of the displaying of any Window/Dialog. I always want to move, resize, maximize, etc. BEFORE the Window is Created. I don't want the flashing and moving of windows after the fact.

HOW CAN THIS BE ACHIEVED?

2. How can an Window/App (or see #3 below) be allowed to use use its Windows Native screen location and sizing AND 'ignore monitor splits' (default behavior)?

3. How to apply a script to provide a list (1..N) of apps which I want the "ignore monitor splits"?

4. There's a problem when you using the 'ignore monitor splits' in this example.
(a) Initially displayed maximized within the split (not desired)
(b) A second or two maximized to full screen (desired, except delay, and app movement)
(c) Click on restore and you get the app back into the split (I'd expect the split didn't apply to the app until and unless the app was explicity moved into the split and DF behavior would be everything except as if the splits didn't exist.

Thanks

Jul 2, 2017 (modified Jul 2, 2017) • #1

We used to set the window's new location and size before the window was created, but it caused to many problems with various applications. Waiting until the window is visible is much more compatible.

It sounds like maybe we should add a "Ignore monitor splits (this application)" option to the Compatibility rules in DisplayFusion. I've put that on our feature request list.

Thanks!

Jul 4, 2017 • #2

Zardoz2293

36 discussion posts

Quote:

We used to set the window's new location and size before the window was created, but it caused to many problems with various applications. Waiting until the window is visible is much more compatible.

Have you attempted to keep the "new window" hidden/invisible until the location and sizing has been performed, and then change to your location/size and display?

Jul 14, 2017 • #3

Yep, that's how we used to do it but it was too unreliable.

Jul 18, 2017 • #4

Zardoz2293

36 discussion posts

Quote:

Yep, that's how we used to do it but it was too unreliable.

Different WindowClasses need to be handled in different ways, at least that was my experience when I was doing these things.

Jul 27, 2017 • #5

Zardoz2293

36 discussion posts

Quote:

Sounds like someone was retaining a local variable for location/size and not using the window's properties. Have you considered the ability to use this method and then provide either by you or the end-user a method to black-list (or white-list) troubled apps/windows? Would rather see it working on some rather than none.

Jul 27, 2017 • #6

It is possible to hook the window creation, and modify the window creation parameters to force a specific size. The issue we ran into was performance, and stability of certain apps. Some apps don't like having their window creation params messed with. So we were left with either blacklisting apps as they caused problems, or maintaining a whitelist of apps that worked. Either option was a compatibility nightmare so we decided to go with the less attractive but more reliable method that we use today.

Aug 2, 2017 • #7