MiniWindow Window positions 5/9 don't center properly.

Posted by WillFa on Mon 22 Sep 2008 03:36 AM — 7 posts, 21,434 views.

WillFa USA Mon 22 Sep 2008 03:36 AM #0

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.

Nick Gammon Australia Forum Administrator Mon 22 Sep 2008 05:12 AM #1

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.

WillFa USA Mon 22 Sep 2008 05:40 AM #2

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

Nick Gammon Australia Forum Administrator Mon 22 Sep 2008 05:42 AM #3

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 Australia Forum Administrator Mon 22 Sep 2008 05:50 AM #4

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

WillFa USA Mon 22 Sep 2008 08:09 AM #5

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

Nick Gammon Australia Forum Administrator Mon 22 Sep 2008 08:48 AM #6

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.