Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.

Due to spam on this forum, all posts now need moderator approval.

 Entire forum ➜ MUSHclient ➜ Bug reports ➜ MiniWindow Window positions 5/9 don't center properly.
MiniWindow Window positions 5/9 don't center properly.

It is now over 60 days since the last post. This thread is closed.     Refresh page

Posted by WillFa   USA  (525 posts)  Bio
Date Mon 22 Sep 2008 03:36 AM (UTC)

Amended on Mon 22 Sep 2008 08:45 AM (UTC) by WillFa

Message
Code to Reproduce:

for i =1,8 do 
 WindowCreate(tostring(i), 0,0, GetInfo(281)/3,GetInfo(280)/3, i+3, 0, 0x1a0000 * i) ; 
 WindowRectOp(i, 1, 10,10, -10,-10, 0, 0 ) ; 
 WindowShow(i) 
end


The Window at #9 behaves as if there's no window in the #10 (SW corner) position.



Also,
for i =1,8 do 
local pos = 5 ; 
if i > 2 then pos = 7 end 
WindowCreate(tostring(i), 0,0, GetInfo(281)/3,GetInfo(280)/5, pos, 0, 0x1a0000 * i) ;
 WindowRectOp(i, 1, 10,10, -10,-10, 0, 0 ) ;
 WindowShow(i)
 end


The Window in the #5 position is centered along the remaining portion of the X-axis (shared by windows at 4,5 or 6), and Windows at #7 are centered along the Y-axis, but #5 is overlapped.


Top
Posted by Nick Gammon   Australia  (23,169 posts)  Bio   Forum Administrator
Date Reply #1 on Mon 22 Sep 2008 05:12 AM (UTC)
Message
They are both the result of a single bug in copy and paste when I did that code.

The fix is in bold:


Index: mushview.cpp
===================================================================
RCS file: /cvs/mushclient/mushview.cpp,v
retrieving revision 1.116
diff -c -r1.116 mushview.cpp
*** mushview.cpp	18 Sep 2008 23:22:38 -0000	1.116
--- mushview.cpp	22 Sep 2008 05:10:56 -0000
***************
*** 6580,6586 ****
  
        case 10 :  // on left, at bottom
           mw->m_rect = CRect (0, clientrect.bottom - iHeight, iWidth, iHeight);
!          pt_bottomleft.x = max (pt_bottomleft.x, mw->m_rect.left);     // shrinks available
           pt_bottomleft.y = min (pt_bottomleft.y, mw->m_rect.top);
           break;
  
--- 6580,6586 ----
  
        case 10 :  // on left, at bottom
           mw->m_rect = CRect (0, clientrect.bottom - iHeight, iWidth, iHeight);
!          pt_bottomleft.x = max (pt_bottomleft.x, mw->m_rect.right);     // shrinks available
           pt_bottomleft.y = min (pt_bottomleft.y, mw->m_rect.top);
           break;


This will be fixed in version 4.38.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by WillFa   USA  (525 posts)  Bio
Date Reply #2 on Mon 22 Sep 2008 05:40 AM (UTC)
Message
Thanks for the quick response, Nick. :)

Quick question tho, how does a fix in case 10 affect how cases 5 and 7 share the space normally occupied by case 6? I don't see how it would affect the second code sample. :(
Top
Posted by Nick Gammon   Australia  (23,169 posts)  Bio   Forum Administrator
Date Reply #3 on Mon 22 Sep 2008 05:42 AM (UTC)

Amended on Mon 22 Sep 2008 05:56 AM (UTC) by Nick Gammon

Message
If you are desperate to have this working right now, download this file (109 bytes):

http://www.gammon.com.au/files/mushclient/mushclient_438.dif

Then download "JojoDiff - diff utility for binary files" from:

http://jojodiff.sourceforge.net/

Then using a command window apply the patch as follows (ie. in your MUSHclient directory, and assuming you put jpatch-w32.exe there or somewhere in your path):


jpatch-w32.exe MUSHclient.exe mushclient_438.dif MUSHclient_438.exe


That will apply the patch to your existing MUSHclient.exe (the 4.37 version) - just the .exe not the installer - and give you a new file which is version 4.38 with the patch applied.

Note this may be an interim version of 4.38 - so far it only has this one fix in it.

The md5sum for the dif file is:


af3b904366ec7b9c6bee2a138779a2f7


- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Nick Gammon   Australia  (23,169 posts)  Bio   Forum Administrator
Date Reply #4 on Mon 22 Sep 2008 05:50 AM (UTC)
Message

This is what I see with the patched version - where do you see a problem?

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by WillFa   USA  (525 posts)  Bio
Date Reply #5 on Mon 22 Sep 2008 08:09 AM (UTC)

Amended on Mon 22 Sep 2008 08:45 AM (UTC) by WillFa

Message
Thank you for that fix. :)

I sent you an e-mail with a screen shot attached. I don't know if my live.com address will get caught in your spam filter.

There's a version of the screenshot on http://willfa1974.spaces.live.com/photos -- pic 7.


The problem that I just saw was in my second sample code above, where I goofed on the copy/paste.


Thanks again. :)
Top
Posted by Nick Gammon   Australia  (23,169 posts)  Bio   Forum Administrator
Date Reply #6 on Mon 22 Sep 2008 08:48 AM (UTC)
Message
Yes, I see.

Well, technically that is not a bug, it is by design. :-)

When I was doing the centering code my mind melt a bit trying to work out what was multiple simultaneous equations. I was aware that you might technically set up a situation like you have, where the centering top-bottom collided with the centering left-right (as in your example).

In your example, what would you consider the "correct" behaviour? If there isn't room for the left-right windows, which should take precedence? The up-down ones or the left-right ones? Whatever you answer, someone else may consider a different answer to be correct.

I simplified my calculations somewhat by considering the various cases independently - basically the left-right windows are centered between the corners (if any), and the up-down ones between their corners. It becomes recursive and somewhat difficult to predict if you the reconsider the results based on whether, as a result of centering up-down, the left-right ones have to be recalculated (or vice-versa).

You can make the code "fail" in various ways, for example, if you have various windows centered top-down, and then resize horizontally to be very small (ie. a long thin window in the Y direction) then the windows will overlap.

If anyone can look at my C++ code and suggest a better algorithm, that would fairly universally be considered correct, then they are welcome to suggest it. Already the relevant function (Calculate_MiniWindow_Rectangles) is fairly complex.

The fallback position for you is to go for "absolute positioning" and come up with an algorithm to position the various windows that satisifies your criteria, for this particular case. That is why I left absolute positioning in as an option to fall back on.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

19,114 views.

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum

[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

Home