START /POS versus @WINPOS and @WINSIZE

[djspits]

I want to start a program and have its window cover exactly an existing window.

@WINPOS -> top,left,bottom,right
@WINSIZE -> width,height

Checked:
@WINSIZE width == @WINPOS right - @WINPOS left
@WINSIZE height == @WINPOS bottom - @WINPOS top

Using START /POS=left,right,width,height to start a program, the size of the new window is indeed identical, but the position is not: much higher and to the left.

EDIT: since I was using a console to test (which apparently does its own sizing) is not surprising that the sizes where identical.

Also, I have noticed that @WINPOS top and left, sometimes have negative values.

Please advice.

 

[AnrDaemon]

They base off different viewports.
@WINPOS shows coordinates relative to desktop area.
/POS switch specify coordinates relative to display viewport.
And yes, negative values are valid.

 

[djspits]

Thank you.

So,.. how do I calculate the position for the START command?

 

[AnrDaemon]

Run ACTIVATE with known /POS (f.e. 100,100), check @WINPOS and calculate your offset.

 

[djspits]

Sorry, I'm lost.

Different top,left yet @WinPos returns the same values?

 

[vefatica]

That's bizarre. I cannot reproduce it.

 

[djspits]

Tell me about it!
Let me try the same exact numbers you use.

 

[djspits]

The first STARTed window (I do not dare to use the word 'child' any more ) covers the second start command - you'll have to take my word for it.

But,... progress at last!

1) Apparently the width and height are being ignored, because consoles are always the default size. Hmmm. v.exe is not starting as expected either.
2) I finally noticed that my results are halved! And that reminded me that I have a microsoft-recommended 200% scaling of my desktop. That sounds hopeful,... if it wasn't for the previous point.

Do we realize just how much time is wasted on just figuring out the quirks?

Thanks, Vince.

 

[AnrDaemon]

Did you create the _pid variable by yourself at any point?

 

[AnrDaemon]

Apparently the width and height are being ignored, because consoles are always the default size

That's not entirely true. I was resizing Far manager window with TCC just fine.

 

[djspits]

That's not entirely true. I was resizing Far manager window with TCC just fine.

Then it is very well behaved. Good for him!
Apparently the same cannot be said for the TCC console.
I know, probably Rex is doing sums with rows, columns and font particulars.
However, V.EXE also has a mind of its own.
Hmmm. Notepad, then?
Nope.

 

[rconn]

TCC does not control its own size or position - that's done by Windows depending on the console registry settings. (If you specify custom values in the OPTION / Windows dialog, TCC will resize itself after starting up.)

Consoles are exceptionally tricky - the size settings are usually (not always, depending on some other factors) ignored by Windows / CreateProcess. You can subsequently (sometimes) resize the window, depending on the version of Windows and the console registry settings. The latest Win 10 versions allow more console window resizing.

Most Windows GUI apps will also ignore the CreateProcess size settings (set by START /POS) in favor of their own saved position / size settings. Again you'll have a lot more luck resizing / repositioning after the process is created.

 

[AnrDaemon]

Again you'll have a lot more luck resizing / repositioning after the process is created.

That's true. And in case of console, it may not resize even then in Win10.