capture window without border respective to location settings about screenareashare HOT 15 CLOSED

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 .

from screenareashare.

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 --

from screenareashare.

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.

from screenareashare.

@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)

from screenareashare.

@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?

from screenareashare.

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.

from screenareashare.

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...

from screenareashare.

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

from screenareashare.

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.

from screenareashare.

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...

from screenareashare.

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

from screenareashare.

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

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

from screenareashare.

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

from screenareashare.

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

from screenareashare.

Thank you for contributing!

from screenareashare.