Lister Layouts won't open/save in correct position and size (Multiple monitors)

Help & Support
1

Windows 10. Latest DOpus (but issues existed in 10 and 11 as well). Four monitors. I want 3 lister layouts with equal sizes to fit a single monitor (1920x1080), noting that H=1050 is used to allow for taskbar, as follows:.

1 : x=0 y=0 w=640 h = 1050
2 : x=640 y=0 w=640 h = 1050
3 : x=1280 y=0 w=640 h = 1050

If I manually alter the .oll files (which I'm trying because saving lister layouts isn't working) to what I think should reflect those values as follows:

wp rc="0,0,639,1050,100" showcmd="1"
wp rc="640,0,1279,1050,100" showcmd="1"
wp rc="1280,0,1919,1050,100" showcmd="1"

I dunno where the pixel gets lost at 1919... but no big deal. :slight_smile:

They actually open up as follows:
1 : 7,0,631,1042
2 : 647,0,1271,1042
3 : 1287,0,1911,1042

It's difficult to be sure of those because there appears to be a fair amount of shading on the edges.

And while that's somewhat ok... because nothing is overlapping and they all fit on monitor. That's not what I want. And worse though, I have to manually alter the layout files to get that to happen. If I position them where I want them and save they, they're not so greatly positioned.

I know this has to do with windows 10 handling of windows, as I program stuff too, there should be a way for you to overcome this issue.

Is there a setting or something I'm missing?

It would be really nice too if DOpus has a way to quickly auto-size and position the windows on a screen. There's probably tool out there somewhere to do this with any window... I'll have to look. But, even if there is... those sizes/positions won't save in the layout file properly. So...

What to do?

Are the data files documented anywhere? What's the 100 mean in the rc variable? 100% is my guess.

2

You shouldn't be editing the config files by hand unless you really need to.

What's wrong with ssving a layout using the normal menus?

Windows in Windows 10 have huge transparent borders around them due to Microsoft's incompetence. You'll need to make the windows overlap if you want them to appear to touch each other.

3

The config files are just simple XML files, if you didn't want them edited, you wouldn't make them XML. :slight_smile:

The problem is that if I layout the 3 listers in the position and sizes that I mentioned, and save each lister... when I recall each of those they are not in the places/sizes they were when I saved them.

So, I tried editing them manually - cuz I really needed to. That shows the same problem. The listers have a mind of their own. I should be able to position them, overlapped or not, and have them recalled as they were when I saved. That does not happen.

I've tried using the dev Spy tools to determine windows info, but these also give weird values on Windows 10.

4

Just because you can edit something doesn't mean you should. :slight_smile: There are times when it's a good idea, but not when it isn't necessary.

Are you saving each lister individually, or saving all of them as a single layout?

Are any of them (partially) off-screen?

How are you loading the layout(s)?

5

I'd be surprised Leo, as technical as you are, if you didn't edit things you shouldn't too. I'm on to ya. Hehe

Saving each lister individually. Assigned each to a hotkey. So, I can use Ctrl-1, Ctrl-2, Ctrl-3, to bring all 3 up. But, I just tried via the tasbar icon to open it and same issue.

The actual edge of lister 1 and 3 I don't think are off screen. The anti-alias likely is.

If I position a lister at 0,0 on the main monitor and save it's layout... I get this

wp rc="-7,0,632,1050,100" showcmd="1"

I encounter this -7 in my own programming too. It's that weird Windows 10 thing.

Oh... I just figured out where the issue is... I was able to fix it, but not in a way I want.

When I save the lister, if I use the "Open this layout relative to the monitor the mouse is on", the problem occurs. But, if I turn that off, it opens where it should. So, the issue is in your calculating the position based on the monitor the mouse is on.

7

I received a Windows notification from Jon, about me complaining that the option is doing what it's supposed to.... unfortunately, once I saw the notification it went away... and it doesn't appear to be in here either, so not really sure... these Windows 10 notifications from support forums are very strange.... anyway...

Jon, maybe you realized your message was wrong and removed it, I dunno… but to be sure... the option is definitely not working right. If I have the option off, and have a lister positioned at 0,0... when I trigger the lister to open, it opens at 0,0. But, I turn on the option, it opens at 7,0, then obviously that setting is affecting the positioning. And yes, it supposed to affect the positioning with regards to displaying on another monitor, but it should also open at 0,0 on a different monitor (though I realize it's not really 0,0 it could be -1920,0 if the monitor is to the left). But, it doesn't. So, it's a bug with that option.

8

Sorry I had misinterpreted what you were saying, which is why I deleted my reply to you.

But having tried this, I'm not able to reproduce the issue. For me, one or more Listers on the same monitor saved to a layout re-open exactly where they were saved, whether or not the "monitor-relative" option is turned on.

9

That message I received was (only) the second notification I received like that in Windows. I’m not even sure how it happens… presumably your forum can link thru Microsoft to me…. It’s a little scary actually since my Windows isn’t logged into a Microsoft account… so not sure how that works exactly. Anyway, I was beginning to think I was dreaming these things. J

I don’t know if this matters or not but …. In my monitor setup, I have 4 monitors… positioned like this…

 1
4 2 3

#2 is my main monitor… so it’s upper left coordinate is (in theory) 0,0.

When I save a lister positioned at 0,0 though, the .oll file actually indicates

wp rc="-7,0...

And I think this has something to do with the issue. Note that, that -7 offset, I’ve seen in other things (my own windows forms stuff, and such). I also see in a Window Spy tool that it shows the window at -7,0.

If I move the window to 0,0 on the #4 monitor and save it…

wp rc="-1927,0...

What kind of calculation are you making when the “monitor-relative” option is active, vs when it isn’t?

10

The forum doesn't know anything about your Microsoft account. Notifications are a feature of Chrome.

You can turn off notifications in your user preferences here:

https://resource.dopus.com/my/preferences/notifications

You can also undo the recent change Google made to Chrome which moved all browser notifications into the OS notification system, where they probably are not wanted, and reverts back to Chrome's separate notification system:

chrome://flags/#enable-native-notifications

Re what the thread is about, I think what's happening is caused by us moving windows if they are off-screen. The purpose of that is to prevent layouts saved with one monitor size/layout from opening windows completely off-screen that you cannot see or access (without rather obscure tricks) because the coordinates they were saved at are no longer visible.

Since Windows 10 adds huge transparent borders around windows which are still technically part of those windows, a non-maximized window which looks like it's right at the edge of the screen will actually be partially off-screen, and causes our code to move it over slightly when the window is re-opened.

We might tweak that so it only moves the window if it's more than 50% off-screen or something, which seems more sensible to me.

Or we could add an explicit argument of Misc/Advanced setting to disable the on-screen check, but I think the check still makes sense, it just needs to be relaxed a little for situations like this. -- What do you think?

11

I don't use Chrome, so I'm not sure how the notifications end up into the OS notifications. Magic I suppose. Even weirder, the first reply you made came via notification, the second via email, and the third by notification again.

Anyway... a reminder that if the "Open this layout relative to the monitor the mouse is on" is turned OFF when saving the lister. It opens up where it was when saved (Regardless of being somewhat off-screen). So, I presume your off-screen check is only being done when it's ON? Or its doing it differently somehow in the two states of that option?

The off-screen test can be useful in a circumstance where I'm using one monitor, but perhaps saved a lister on a second monitor that isn't connected temporarily. And thus then I can't see it. So maybe relaxing it in that, if enough of the title bar is accessible so you can move it back on screen, then don't auto-move it. Or if it's only off screen (or overlapping the taskbar) by maybe 10 pixels then that's ok. I'm not sure if different settings in Windows causes the anti-alising or soft edges or whatever windows 10 is adding to be increased or not.

Also... I've mainly been talking about the upper left corner, but when it opens wrong, it also changes the width and height.

This might be irrelevant now.. but it occurs to me since you mentioned the off-screen test... that I used to have an issue where if I logged into the system (quad monitor) via Remote Desktop (single monitor), and opened a lister, it would seemingly ignore where I'd told it to display... al three of the positions I'd saved would open in the same wrong place. But, at some point, presumably after some update to DOpus 11, that it didn't do that anymore. So, there might have been a change to the off-screen logic at some point along the way too.

12

Firefox also does notifications but I'm not sure where they end up. Other browsers based on Chrome and FF probably do as well, and maybe others on top of that. Discourse also does push notifications to Android.

Notifications usually get sent if you have an idle browser tab open on the site and have them enabled. Otherwise, an email may get sent if those are enabled, unless you're active on the site already, in which case the email doesn't get sent as you've probably already seen what it's about.

Notifications usually cannot happen unless you opt in. Browsers prevent sites from doing them unless you click Allow at some point for a site.

13

In the next update Opus will take the size of the "shadow border" into account when deciding whether a window is off-screen or not.

14

We've made this change in the 12.10.2 Beta.

15

Almost perfect... you appear to be presuming the taskbar is full size though, limiting the height to 1050... but with "Use small taskbar buttons"... 1057 is possible. Otherwise, it's working great with 3 monitors side by side and 1 monitor offset above.

16

We query the system for the size of the taskbar.

17

It may be related to the shadow extension then... I can't get it to be the full height, it coincidentally stops exactly where the taskbar is when in large size.

18

Can you post a screenshot please?

19

Snipaste_181114_171118

This is when opened with these values...
<wp rc="-7,0,648,1057,100" showcmd="1" />

If I then save it, it gets these values...
<wp rc="-7,0,648,1050,100" showcmd="1" />

It's 7 pixels off, same as the X asis (-7) is. But the top/left/right side position properly now.

20

Ok, thanks. Should be able to fix that.

21

This is fixed in 12.10.3.