|
Joined: Jul 2003
Posts: 40
Ameglian cow
|
OP
Ameglian cow
Joined: Jul 2003
Posts: 40 |
Hello, I'm a bit confused since I've found a bug in the command /window with the -f switch.
From the help file: "f = indicates that w h are the required width and height of the text display area as opposed to the window size"
That doesn't work very well.
;/winfbug <w> <h> alias winfbug { window -hpf @test -1 -1 $1 $$2 drawrect -f @test 2 1 0 0 $1- drawsave @test test.bmp window -c @test echo 2 -s /window -f bug: $1-2 -> $pic(test.bmp).width $pic(test.bmp).height }
I also add a DLL command to retrieve the size of the "drawing aera" after /window -f, and it is the same as the $pic()'s returned value, so it's not a bug of /drawsave. [DLL command: $cwnd(getClientRect,$cwnd(findWindowEx,$window(@test).hwnd > > Static))]
Some examples when the /window -f fails: /window -f bug: 60 60 -> 114 60 /window -f bug: 100 100 -> 114 100 /window -f bug: 200 30 -> 200 28
On the other hand, it works when the values are a bit highest: /window -f bug: 120 100 -> 120 100 /window -f bug: 300 300 -> 300 300 /window -f bug: 1024 768 -> 1024 768
edit: With mIRC 6.35 & Windows Vista
|
|
|
|
Joined: Oct 2003
Posts: 3,918
Hoopy frood
|
Hoopy frood
Joined: Oct 2003
Posts: 3,918 |
This is not the fault of mIRC, but rather how minimum/maximum window sizes work in Windows. When you make a window with min/max and close buttons in the titlebar, the minimum window size will be the width of the icon + the width of the buttons-- this ends up being something around ~114px wide.
If you need a smaller window, remove some of the titlebar buttons and/or remove the border entirely. For instance, using the "tool window" border-style allows a size of 60,60 to work:
//window -dpf +L @x -1 -1 60 60 | echo -s $window(@x).w
Will echo 76 for me (16px of which is the border size here, which I think is the default)-- you can see this is clearly lower than your reported values.
As a sidenote, this also has nothing to do with the -f switch. The same command as above without -f should also return the correct value (in this case, 60, since the specified size included the 16px border space). Note that without +L the window will be made to 124px, not 60. This shows quite clearly that the minimum size behaviour is not related to the -f switch.
- argv[0] on EFnet #mIRC - "Life is a pointer to an integer without a cast"
|
|
|
|
Joined: Jul 2003
Posts: 40
Ameglian cow
|
OP
Ameglian cow
Joined: Jul 2003
Posts: 40 |
"This is not the fault of mIRC, but rather how minimum/maximum window sizes work in Windows."
I likes mIRC too, but why always rejects the fault on the Windows API ?
the mIRC picture window client aera (Static), isn't a titlebar's window, it's a child window !
Since you can size a child window with 0 0 values, I'm afraid but it's not a windows api limitation.
I've fixed the bug by SetWindowPos() the Static child windows with good values.
Moreover, the window is hidden (-h switch, so at this point we don't care about titlebar or borders).
|
|
|
|
Joined: Apr 2004
Posts: 871
Hoopy frood
|
Hoopy frood
Joined: Apr 2004
Posts: 871 |
If the proper result can be achieved through the WinAPI fairly easily then that does sound like a bug (or better put, needless limitation). Does the problem only really show with /drawsave though? I for one would very much like to see (optional) x/y/w/h parameters for /drawsave which would solve this case as well as others..
Saturn, QuakeNet staff
|
|
|
|
Joined: Oct 2003
Posts: 3,918
Hoopy frood
|
Hoopy frood
Joined: Oct 2003
Posts: 3,918 |
You're missing the point. MDI child windows still have titlebars unless you specify otherwise-- and because you did not specify otherwise, they also have a minimum size limitation. This is not mIRC's doing, this is how Windows works. If you want a smaller window, you'll have to remove the titlebar buttons as shown in my original post. Is this not what you're seeing?: (40x60 without +L) (40x60 with +L) Try to resize the first Window and you'll see that you simply *cannot* make it any smaller. This is proof that it is a Windows issue, not mIRC. mIRC is indeed trying to make the window 40x60 and it is Windows that is not letting it- there's really nothing mIRC can do in this case. You as the scripter need to remove the window border. Hidden windows don't make a difference. Just because a window is hidden doesn't mean Windows does not allocate titlebar or borders to it. Hidden means not drawn on the screen, not "no borders or titlebar"-- a hidden window must still respect the boundary requirements of the window manager. See /help /window and specify the correct border type (maybe you want +b?) so that you can make the window the correct size.
- argv[0] on EFnet #mIRC - "Life is a pointer to an integer without a cast"
|
|
|
|
Joined: Jul 2003
Posts: 40
Ameglian cow
|
OP
Ameglian cow
Joined: Jul 2003
Posts: 40 |
I think you didn't understood. I wasn't talking about the $window(@lol).hwnd but about the Static child window of it ! Bellow here in red is the "mIRC picwin's aera". I resized it (w = h = 20). I'm aware that the @lol window itself cannot be resized to 20 20 because of the borders/etc.. but when the window is hidden, the window may be sized as I'v shown on the picture (because in this case, the user don't see the @window, and the size of picwin will be the same as the /drawsave -> $pic().width & $pic().height.. by the way the problem will be fixed with hidden windows).
|
|
|
|
Joined: Oct 2003
Posts: 3,918
Hoopy frood
|
Hoopy frood
Joined: Oct 2003
Posts: 3,918 |
The "Static child" is an implementation detail that should not concern you (you should really not even know it exists-- it should not even necessarily exist in the first place). I don't see how -f would be specifying the size of "the Static child window within the display area", so you should not be expecting -f to be setting the size of that control. Instead, I think the intention of the -f switch is to specify the size of the *display area* of the window (everything but the border), which is much larger than the 20x20 red box in your window screenshot. The fact that you can draw a 200x200 red box in a resized picwin that was created with -f 100 100 is proof that -f is specifying the (window size - border), *not* the canvas size to draw to. Because it's specifying (window size - border), you should expect the minimum size issue with *and* without -f.
Again, you can easily solve this by removing the border on the window.
- argv[0] on EFnet #mIRC - "Life is a pointer to an integer without a cast"
|
|
|
|
Joined: Jul 2003
Posts: 40
Ameglian cow
|
OP
Ameglian cow
Joined: Jul 2003
Posts: 40 |
Thanks you for your answers, seems to works good with +b switch ^^. alias winfbug {
window -pfh +b @test -1 -1 $1 $$2
drawrect -f @test 2 1 0 0 $1-
drawsave @test test.bmp
window -c @test
echo 2 -s /window -f !bug: $1-2 -> $pic(test.bmp).width $pic(test.bmp).height
}
But idealy, /window -f should be working in all situations. (An application should adapt itself to OS, not OS -> Application).
|
|
|
|
Joined: Jul 2003
Posts: 40
Ameglian cow
|
OP
Ameglian cow
Joined: Jul 2003
Posts: 40 |
Okay, I've get a mirc crash after testing the alias winfbug (see above). mIRC 6.35, no DLLs loadded. Just the winfbug alias.
Last edited by HadS; 29/05/09 01:08 AM.
|
|
|
|
Joined: Jul 2003
Posts: 40
Ameglian cow
|
OP
Ameglian cow
Joined: Jul 2003
Posts: 40 |
Same bug with a freshly installed mIRC 6.35 on Windows Xp.
|
|
|
|
Joined: Oct 2003
Posts: 3,918
Hoopy frood
|
Hoopy frood
Joined: Oct 2003
Posts: 3,918 |
An application should adapt itself to OS, not OS -> Application This is only partially true. When it comes to UI guidelines, the application should respect the OS and adapt to it. If Windows says that a display area can be no smaller than the width of the titlebar (if present), then any window created with a titlebar should respect those rules. Since you created a window with a titlebar, mIRC needs to respect the rules. Since -f specifies a window attribute which is directly related to window size, it must respect all window size UI guidelines. This means as a scripter or *ANY* for windows development, you should never expect a window with a titlebar to be smaller than the titlebar width. Although mIRC *can* work around this issue in the way you described, it should not be the expected behaviour given what was said above.
- argv[0] on EFnet #mIRC - "Life is a pointer to an integer without a cast"
|
|
|
|
Joined: Oct 2003
Posts: 3,918
Hoopy frood
|
Hoopy frood
Joined: Oct 2003
Posts: 3,918 |
I don't think these crashes are related to window -f, I think they might be to do with $pic and drawsave. This is probably enough information for Khaled to track down, but a minimal test case would be more helpful.
- argv[0] on EFnet #mIRC - "Life is a pointer to an integer without a cast"
|
|
|
|
Joined: Jul 2003
Posts: 40
Ameglian cow
|
OP
Ameglian cow
Joined: Jul 2003
Posts: 40 |
Yes you're right. But this "limitation" can be removed by creating custom MDI @picwin Windows without dealing with standard Windows API (so, create custom border, etc..).
I know it's a lot of work, but today lots of programs prefers have a custom window interface. (eg: Windows live messenger).
The help-file isn't very "detailed" and lots of extra-informations are missing.
"f = indicates that w h are the required width and height of the text display area as opposed to the window size" In this setence, nothing informs me that the functions fails if the w h paramaters are too small.
And I don't read in mIRC.chm that we must know "Windows API" before learning mIRC's Scripting. So in this case, my first questions wasn't stupid.
|
|
|
|
Joined: Oct 2003
Posts: 3,918
Hoopy frood
|
Hoopy frood
Joined: Oct 2003
Posts: 3,918 |
But this "limitation" can be removed by creating custom MDI @picwin Windows without dealing with standard Windows API The limitation would not be removed-- it would just be bypassed by treating the inner canvas "Static" control that you found as an inner part of the display area. The window itself (AND the display area) would still be limited by the OS, mIRC would just be able to draw to a smaller part of the display area. This would be a workaround that would lead to tons of inconsistencies. For instance, if mIRC resized the inner canvas to be smaller than the display area, $window(@mywindow).w/h would *still* return the entire display area, but you would not be able to draw to all of it because the canvas would be clipped. This would probably confuse scripters trying to incorrectly manipulate small windows. Most scripts I know base their drawing calculations on $window(@mywindow).w/h, so this would lead to problems. (so, create custom border, etc..). You can already create custom borders. The onus is on you to do it, otherwise you should expect default Windows behaviour. Again, see /help /window and make use of the switches available to you. lots of programs prefers have a custom window interface Custom window interfaces (at least the ones I know) do not use bordered windows. They create borderless windows and code their own titlebar logic-- you should do this too. And I don't read in mIRC.chm that we must know "Windows API" before learning mIRC's Scripting. This is exactly the point. You're the one coming in with assumptions about the Windows API-- you're the one who brought up API calls and implementation details about the window class. The point is this: API aside, to a layman, "display area" means the window size minus the border. This is what the help file talks about. For example, if you make a window with a *display area* that is 100x100 and then resize it to 200x200, you have a *display area* of 200x200, this goes for resizing downwards as well. If we can agree on that, then there is no issue here, because if the display area is just the non-border part of the window, it can never be smaller than the 114px you reported when a titlebar is present. If we count "display area" as the entire white background in that screenshot you posted, it is directly tied to the window size. However if we count "display area" as a subsection of the actual display area, we have to introduce concepts like "canvas size" which can be arbitrarily large as compared to the actual window and it gets confusing fast.
- argv[0] on EFnet #mIRC - "Life is a pointer to an integer without a cast"
|
|
|
|
Joined: Jul 2003
Posts: 40
Ameglian cow
|
OP
Ameglian cow
Joined: Jul 2003
Posts: 40 |
I was just reporting a bug with /window -f. Since it's the only way to /drawsave an image with a specific size.
We don't care about Windows limitations, thoses ones can be fixed easily.
I mentionned the "own windows" just to remove Windows Border/Titlebar's limitation. (Khaled can do it if he want). I know we can create own titlebar gui thanks to picwin, but you missunderstood I think.
|
|
|
|
Joined: Oct 2003
Posts: 3,918
Hoopy frood
|
Hoopy frood
Joined: Oct 2003
Posts: 3,918 |
I did not misunderstand. Khaled should not remove window borders for you. It's a switch that you should do set yourself.
- argv[0] on EFnet #mIRC - "Life is a pointer to an integer without a cast"
|
|
|
|
Joined: Jul 2003
Posts: 40
Ameglian cow
|
OP
Ameglian cow
Joined: Jul 2003
Posts: 40 |
There are several ways to fix the problem. As i'v shown on my first screenshot (in this way, /window -f @... 2 2 -> The window will be resized as the actual way (minimm windows's api size depending borders..) but the "Static" should be sized to 2x2 and center. It's a way (betwenn many others) to fix the problem.
I'v told you it's not impossible to fix the /window -f problem. I've just given some solutions.
You're probably a very helpful mIRC's user, but I don't need help on it, I use it since the 5.71's version.
I've tried with /window -ph +b, and unfortunetely I've get mIRC.exe crash. I hope this bug will be fixed (I'm working on /drawsave with very small images..)
Have a good day
|
|
|
|
|