> IIUC the problem I see can be described more easily as follows. > Evaluate in sequence the following expressions with emacs -Q: > > (modify-frame-parameters nil '((menu-bar-lines . 0) (height . 30))) > (modify-frame-parameters nil '((menu-bar-lines . 1) (height . 40))) > (frame-parameter nil 'height) > > Here the height reported by the last form is 41. Actually, the immediate cause of this problem goes as follows: When you specify both addition of the menu bar and the new frame height, ‘modify-frame-parameters’ will first issue a request to add the menu bar and then a request to calculate the new frame height as specified. However, Emacs does not immediately add the menu bar but delay this until prepare_menu_bars is run by the display engine. Till then, only the value stored in the external_menu_bar slot of the frame tells whether the frame shall have a menu bar or not. As a consequence, the request to set the frame height will be delivered first to the toolkit. The calculation of the new frame height on Windows is done by calling the function AdjustWindowRect. The third argument of that function has to specify whether a menu bar should be included in the calculation or not. Currently, this value is set to whatever the external_menu_bar slot stores. But if the frame does not have a menu bar so far but should get one in the future, the value stored there is inherently wrong for calculating the size of the frame height via AdjustWindowRect. I attach a patch against Emasc-25 which fixes this bug here. I also added a remark to the doc-string of ‘modify-frame-parameters’ in the sense that if you specify several parameters which might affect the size of the frame, Emacs cannot always guarantee for every toolkit that the final size will meet the expectations of the caller. Inherently this means, that the application programmer has to experiment with this function on each and every toolkit involved. I leave it to Eli to decide whether the patch should go into Emacs-25 or master/trunk. Thanks for your attention, martin