mIRC Home    About    Download    Register    News    Help

Print Thread
Joined: Dec 2002
Posts: 252
T
Talon Offline OP
Fjord artisan
OP Offline
Fjord artisan
T
Joined: Dec 2002
Posts: 252
in my mirc (v7.15) my windows are always maximized so an @window shows up maximized too

I did /window -pz @lag

in a status i did //echo -a $window(@lag).w $window(@lag).h

output: 520 403

in that same status i replaced @lag with $active
output: 643 579

this is kinda annoying when you want to draw on the picwin based on the size it is and have no clue what it would be in a maximized state. I needed to draw a line across the window from the center on the y axis from 0 to w on the x axis, and found this out when the line wasn't center, nor did it span the whole @window

I thought i could cheat since the $window(@window) functions were messing up so I decided to use $window(-3)

doing the following lines:

var %h = $window(-3).dh / 2 , %w = $window(-3).dw / 2
drawline @lag 1 1 0 %h $window(-3).dw %h
drawline @lag 1 1 %w 0 %w $window(-3).dh

I discovered that the window drawing area was actually locked to what $window(@lag) was telling me GRR!!!

screenshot:

Last edited by Talon; 25/11/10 07:34 AM.
Joined: Apr 2010
Posts: 969
F
Hoopy frood
Offline
Hoopy frood
F
Joined: Apr 2010
Posts: 969
did u try $window(@lag).dw/dh?

Last edited by FroggieDaFrog; 25/11/10 04:03 PM.

I am SReject
My Stuff
Joined: Dec 2002
Posts: 252
T
Talon Offline OP
Fjord artisan
OP Offline
Fjord artisan
T
Joined: Dec 2002
Posts: 252
are you serious? did you even read the whole post and understand whats happening before you blindingly posted that?

Joined: Apr 2010
Posts: 969
F
Hoopy frood
Offline
Hoopy frood
F
Joined: Apr 2010
Posts: 969
Yes i did. but no where mentioned did u try using $window(@lag).dw/dh . even when maximized, those *should* return correctly due to them returning the text display area, though I could be mistaken.


I am SReject
My Stuff
Joined: Dec 2002
Posts: 252
T
Talon Offline OP
Fjord artisan
OP Offline
Fjord artisan
T
Joined: Dec 2002
Posts: 252
window .w and .h supposedly return the whole size of the window rather than just usable display area, if w and h are returning too small of a number than .dw and .dh will yeild an EVEN SMALLER number.. just to not be an ass i tried it, for the sake of argument, and my assumption is correct. its an even smaller number.

also the fact that using -3 which should be the same for an @picwin without an editbox and using the correct numbers fail to draw across the entire surface should significantly tell you something isn't right.

Joined: Dec 2002
Posts: 252
T
Talon Offline OP
Fjord artisan
OP Offline
Fjord artisan
T
Joined: Dec 2002
Posts: 252
further testing, even tho it started maximized $window(@lag).state still returns normal not maximized, i figured on my update routines i could log its said size and if maximized, do

window -f @lag -1 -1 $window(-3).dw $window(-3).dh

and if it isn't it could be restored to its original size
anyways it seems more $window() stuff has problems relating to if they were opened with windows already maximized.

either way, this does fix my surface drawing issue but now leaves another question, how to determine if its maximized since .state is lying smirk

Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
This is due to the way MDI windows work. If you maximize an MDI window and then make another MDI window active, Windows unmaximizes the non-active window. mIRC is returning the state and size of the non-active MDI window as provided by Windows. One way to get around this is to check if the active MDI window is zoomed. If it is, use its size instead, since that will be the size of any MDI window that is made active.

Joined: Dec 2002
Posts: 252
T
Talon Offline OP
Fjord artisan
OP Offline
Fjord artisan
T
Joined: Dec 2002
Posts: 252
what about the drawing surface itself without specifying a size and it starting maximized. is that normal behavior too? I thought if it was visible, it was part of the surface, it appears to be clipping drawing commands to the size of the window determined by init and not actually by whats visible in a maximized state which is what my original post and screenshot was about.

Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
If you are using a picture window you can use the .bw and .bh properties to return the size of the drawing bitmap in the window. The size of the bitmap is not necessarily related to the window size (I think this was discussed in another thread some time ago). mIRC tracks where you have drawn in the bitmap and expands it automatically if necessary.

Joined: Dec 2002
Posts: 252
T
Talon Offline OP
Fjord artisan
OP Offline
Fjord artisan
T
Joined: Dec 2002
Posts: 252
well since -3 is larger than the actual window .dw or .w or .bw for that matter, telling it to draw a line that exceeds the bitmap area should theoretically expand the bitmap then, which is not happening, hence the screenshot. I've tested as far back as I have copies (6.0) and the behavior seems identical on 7.15 and below to 6.0, I don't have any of the 5.x versions to see if those do it too. Besides resizing the window with another /window command, what justifies mirc automatically expanding the bitmap?

Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
That sounds right. If you want to expand the bitmap, you must make the window larger and then draw to the maximum point you want the bitmap to be. At that point mIRC will remember the size of the bitmap and will not shrink it, even if the window is sized smaller.


Link Copied to Clipboard