added option for work-around for some FRC engines in regards to FRCFENs
[xboard.git] / winboard / winboard.c
index 7d8c272..fb317b7 100644 (file)
@@ -1244,6 +1244,8 @@ ArgDescriptor argDescriptors[] = {
   { "autoLogo", ArgBoolean, (LPVOID) &appData.autoLogo, TRUE },\r
   { "firstOptions", ArgString, (LPVOID) &appData.firstOptions, FALSE },\r
   { "secondOptions", ArgString, (LPVOID) &appData.secondOptions, FALSE },\r
+  { "firstNeedsNoncompliantFEN", ArgString, (LPVOID) &appData.fenOverride1, FALSE },\r
+  { "secondNeedsNoncompliantFEN", ArgString, (LPVOID) &appData.fenOverride2, FALSE },\r
 \r
 #ifdef ZIPPY\r
   { "zippyTalk", ArgBoolean, (LPVOID) &appData.zippyTalk, FALSE },\r
@@ -4481,7 +4483,14 @@ HDCDrawPosition(HDC hdc, BOOLEAN repaint, Board board)
       x2 = boardRect.left + animInfo.pos.x;\r
       y2 = boardRect.top + animInfo.pos.y;\r
       clips[num_clips++] = CreateRectRgn(MIN(x,x2), MIN(y,y2), MAX(x,x2)+squareSize, MAX(y,y2)+squareSize);\r
-      /* [HGM] old location of "slight kludge" below */\r
+      /* Slight kludge.  The real problem is that after AnimateMove is\r
+        done, the position on the screen does not match lastDrawn.\r
+        This currently causes trouble only on e.p. captures in\r
+        atomic, where the piece moves to an empty square and then\r
+        explodes.  The old and new positions both had an empty square\r
+        at the destination, but animation has drawn a piece there and\r
+        we have to remember to erase it. [HGM] moved until after setting lastDrawn */\r
+      lastDrawn[animInfo.to.y][animInfo.to.x] = animInfo.piece;\r
     }\r
   }\r
 \r
@@ -4558,14 +4567,6 @@ HDCDrawPosition(HDC hdc, BOOLEAN repaint, Board board)
     DrawPieceOnDC(hdcmem, animInfo.piece,\r
                  ((int) animInfo.piece < (int) BlackPawn),\r
                   (animInfo.from.y + animInfo.from.x) % 2, x, y, tmphdc);\r
-      /* Slight kludge.  The real problem is that after AnimateMove is\r
-        done, the position on the screen does not match lastDrawn.\r
-        This currently causes trouble only on e.p. captures in\r
-        atomic, where the piece moves to an empty square and then\r
-        explodes.  The old and new positions both had an empty square\r
-        at the destination, but animation has drawn a piece there and\r
-        we have to remember to erase it. [HGM] moved until after setting lastDrawn */\r
-      lastDrawn[animInfo.to.y][animInfo.to.x] = animInfo.piece;\r
   }\r
 \r
   /* Release the bufferBitmap by selecting in the old bitmap \r
@@ -6276,6 +6277,7 @@ WndProc(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)
 \r
   /* [AS] Also move "attached" child windows */\r
   case WM_WINDOWPOSCHANGING:\r
+\r
     if( hwnd == hwndMain && appData.useStickyWindows ) {\r
         LPWINDOWPOS lpwp = (LPWINDOWPOS) lParam;\r
 \r
@@ -6283,11 +6285,17 @@ WndProc(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)
             /* Window is moving */\r
             RECT rcMain;\r
 \r
-            GetWindowRect( hwnd, &rcMain );\r
+//            GetWindowRect( hwnd, &rcMain ); //[HGM] sticky: in XP this returned new position, not old\r
+           rcMain.left   = boardX;           //              replace by these 4 lines to reconstruct old rect\r
+           rcMain.right  = boardX + winWidth;\r
+           rcMain.top    = boardY;\r
+           rcMain.bottom = boardY + winHeight;\r
             \r
             ReattachAfterMove( &rcMain, lpwp->x, lpwp->y, moveHistoryDialog, &wpMoveHistory );\r
             ReattachAfterMove( &rcMain, lpwp->x, lpwp->y, evalGraphDialog, &wpEvalGraph );\r
             ReattachAfterMove( &rcMain, lpwp->x, lpwp->y, engineOutputDialog, &wpEngineOutput );\r
+           boardX = lpwp->x;\r
+            boardY = lpwp->y;\r
         }\r
     }\r
     break;\r