capture window without border respective to location settings

[nnako]

Hi,

great tool!!!

I have problems fixing the capture screen at a desired location on a secondary monitor. My configuration looks like this with a ~17 inch internal laptop monitor and an external 55 inch monitor connected via dockingstation to the laptop:

                              x=0
                               |
                               |

     -  +----------------------+
     ^  |                      |
     |  |                      +----------------+ --- y=0
     |  |       55 inch        |     17 inch    |  ^
2160 |  |   secondary screen   |  main screen   |  |  1080
 px  |  |   external monitor   | laptop monitor |  v   px
     |  |                      +----------------+  -
     v  |                      |
     -  +----------------------+

        |<-------------------->|<-------------->|
                 3840 px             1280 px

Without any changes in configuration, the tool works very well when starting via npm start:

• the render window appears in the middle of the main screen (with 1280x720 size)
• the capture window appears in the middle of the main screen (on top of the render window)
• the thick red border of the capture window is visible
• draging and re-sizing the capture window works fine (e.g. drag to secondary screen)
• the render window stays always centered on the main screen. adjusting its size accordingly.
• the capture window is always on top of all other windows (e.g. on the secondary screen)

Now, I want to statically set the location of the capture screen to cover a certain area on the secondary screen (at startup of the tool). So, I adjust the following elements within src/index.js:

const initCapRect = {
  x: app.commandLine.hasSwitch("cx")
    ? parseInt(app.commandLine.getSwitchValue("cx"))
    : null,
  y: app.commandLine.hasSwitch("cy")
    ? parseInt(app.commandLine.getSwitchValue("cy"))
    : null,
  width: app.commandLine.hasSwitch("cw")
    ? parseInt(app.commandLine.getSwitchValue("cw"))
    : 1280,
  height: app.commandLine.hasSwitch("ch")
    ? parseInt(app.commandLine.getSwitchValue("ch"))
    : 720,
};
const initRenderRect = {
  x: app.commandLine.hasSwitch("rx")
    ? parseInt(app.commandLine.getSwitchValue("rx"))
    : null,
  y: app.commandLine.hasSwitch("ry")
    ? parseInt(app.commandLine.getSwitchValue("ry"))
    : null,
  width: app.commandLine.hasSwitch("rw")
    ? parseInt(app.commandLine.getSwitchValue("rw"))
    : 1280,
  height: app.commandLine.hasSwitch("rh")
    ? parseInt(app.commandLine.getSwitchValue("rh"))
    : 720,
};

The shown default elements for x, y, width and height for both windows (except for x and y of the render window, as they should be set automatically) are changed to:

for capture

• x=-2000 (in order to appear on the secondary screen)
• y=0
• width=1920
• height=1080

for render

• width=1920
• height=1080

After doing so, and restarting the tool via npm start, the following effect shows:

• the render window appears in the middle of the main screen (with 1920x1080 size)
• the capture window seems to be placed on the secondary monitor (on the secondary screen)
• NO thick red border of the capture window is visible
• NO draging and re-sizing of the capture window possible (as the border is missing)
• the render window still stays always centered on the main screen
• the capture window does not seem to stay on top of all other windows (border not visible)

question

Is there a way to locate the capture window on a defined position of the secondary screen with a size of 1920x1080 without loosing the border of the capture window?

[mPyKen]

I adjust the following elements within src/index.js

Have you tried adjusting the positions via command line options? i.e. ./screen-area-share.exe --cx=-2000 --cy=0 --cw=1920 --ch=1080 --rx=0 --ry=0 --rw=1920 --rh=1080 or with npm start -- -- --cx=-2000 --cy=0 --cw=1920 --ch=1080 --rx=0 --ry=0 --rw=1920 --rh=1080 Be sure not to add the --freeze option https://github.com/mPyKen/ScreenAreaShare?tab=readme-ov-file#command-line-parameters

EDIT: added missing --

[nnako]

Hi @mPyKen,

yes, I tried that but got the following result messages within the terminal:

npm start -- --cx=-2000 --cy=0 --cw=1920 --ch=1080 --rx=0 --ry=0 --rw=1920 --rh=1080

> screen-area-share@1.3.3 start
> electron-forge start --cx=-2000 --cy=0 --cw=1920 --ch=1080 --rx=0 --ry=0 --rw=1920 --rh=1080

√ Checking your system
error: unknown option '--cx'

I thought, I did something wrong by misunderstanding the required format using npm. So, I checked for the place in code where the parameters are evaluated and found src/index.js.

[mPyKen]

@nnako sorry, it must be npm start -- -- --cx=-2000 --cy=0 --cw=1920 --ch=1080 --rx=0 --ry=0 --rw=1920 --rh=1080 (note the additional -- which is required as electron-forge needs to pass these parameters down to the application)

[nnako]

@mPyKen thanks for the correction.

Unfortunately, the effect is exactly the same as documented in my first post (correct placement of the capture window, but NO red border to check and adjust the capture window location). So, providing startup parameters via npm start and directly changing the startup parameters in src/index.js seem to be equivalent.

I tried to splay around with the arguments a but and noticed that the red border vanishes as soon as I set --cx to negative values. Although the capture window gets located properly (even when partly covering areas on both screens), the red border (on top of every window) does not act as robust as expected.

As I am no native JavaScript'er and even don't know the Electron application framework at all, I would hardly be able to track down the effect, myself, without specific guidance. But I would be willing to further understand the application's structure and then try to contribute. As I already start to like this project very much ;-) .

Would you recommend any specific source of information for getting on track with Electron and your codebase?

[mPyKen]

Hmm interesting... 2 things I would try:

• Could it be that you are starting the application from the terminal application which is on the laptop screen? Could you move the terminal window to the other monitor and then start the application? My random guess is that the capture window is being placed only on the same screen as the one started from, even if it is outside its monitor area
• Could you test it with a setup such that there are no negative coordinates? i.e. coordinate (0, 0) would be on the top left?

I currently use only one monitor, being unable to test this myself

Would you recommend any specific source of information for getting on track with Electron and your codebase?

I am no expert on electron either, it's my first project with it:) But it's not a big application, it mainly consists of the 3 src/*.js files.

[nnako]

Hi @mPyKen ,

I've tried your suggestions.

Could it be that you are starting the application from the terminal application which is on the laptop screen? Could you move the terminal window to the other monitor and then start the application? My random guess is that the capture window is being placed only on the same screen as the one started from, even if it is outside its monitor area.

I create the terminal windows randomly here and there. But, in fact, mostly on the secondary (big) screen where I want the red border to appear together with the capture window. But, unfortunately it makes no change to the behaviour.

Could you test it with a setup such that there are no negative coordinates? i.e. coordinate (0, 0) would be on the top left?

This is, indeed, one thing I have observed (see my previous message). As soon as I insert a negative value for --cx, the red border vanishes.

Maybe, by changing the sequence of operation to something like this, concerning the capture window, would change the effect?:

• first create the window (using positive value for --cx)
• then do all the other stuff ...
• and at the end, move the capture window to the desired position (applying the negative value for --cx

It would be worth a try. Will try to do it as soon as I find the time...

[nnako]

I just saw that when creating the caption window on the secondary screen, the red border is not vanished but the following effects are visible:

• the caption window has, in fact, a red border, but
• the caption window stays behind all (or most) other windows so that on a crowded screen, it appears not to be visible
• by clicking around, it is not possible to get the caption screen permanently into the foreground, as each other window, once activated, seems to keep priority over the caption window
• the transfer of information from the caption window to the render window is still working, though

[mPyKen]

Could you test it with a setup such that there are no negative coordinates? i.e. coordinate (0, 0) would be on the top left?

This is, indeed, one thing I have observed (see my previous message). As soon as I insert a negative value for --cx, the red border vanishes.

What I initially thought was that maybe you could try rearranging your monitors such that the (0, 0) coordinate becomes the top left corner, like this: (that way, there are no negative values anymore)

       x=0
        |
        |

     -  +----------------------+                  --- y=0
     ^  |                      |
     |  |                      +----------------+
     |  |       55 inch        |     17 inch    |  ^
2160 |  |   secondary screen   |  main screen   |  |  1080
 px  |  |   external monitor   | laptop monitor |  v   px
     |  |                      +----------------+  -
     v  |                      |
     -  +----------------------+

        |<-------------------->|<-------------->|
                 3840 px             1280 px

This part sets the capture window always on top and unfocusable. Could you try it without these lines? Maybe they have something to do with the behavior you described.

[nnako]

What I initially thought was that maybe you could try rearranging your monitors such that the (0, 0) coordinate becomes the top left corner, like this: (that way, there are no negative values anymore)

I guess, the top-left corner of the main screen will always be regarded as (0,0). Changing my main screen to the secondary one had a positive effect, indeed. The red border and the stay-on-top feature of the capture window works now. But, unfortunately, this change main <-> secondary causes some issues regarding my personal workflow. So I could test it, but rather keep the structure as is.

This part sets the capture window always on top and unfocusable. Could you try it without these lines? Maybe they have something to do with the behavior you described.

I will try that later today...

[mPyKen]

Changing my main screen to the secondary one had a positive effect, indeed. The red border and the stay-on-top feature of the capture window works now

Interesting... If everything works as intended with positive numbers but not with negative ones, it sounds like some weird problem on electron / chromedriver to me. The electron version currently in use is not the latest one. You could give it a try by updating the dependencies

[nnako]

at least, there are old and relatively new posts about it being an electron issue:

• https://github.com/electron/electron/issues/3126
• https://current.workingdirectory.net/posts/2023/electron-doesnt-like-negative-numbers/

[nnako]

Please have a look at pull request #18 . This solves the issue concerning Electron's inability to handle negative capture window coordinates.

[mPyKen]

Thank you for taking the time to investigate and fixing this! Could it be that we need to do the same with the rendering window? I.e. starting at (0,0) and then moving it to the desired position. Even if it is not needed for the rendering window, could you still add it? I would like to have the same behavior in case there will be similar problems in future

[nnako]

yes I can do that. although this would not be necessarily applicable to the render window as it has no border and does not have to stay in forground. Will add a respective commit for that within the same pull request #18 .

[mPyKen]

Thank you for contributing!