bug on maximized editor lazarus / 9-Editor ---------------------------------------------------------------------- x2nie · 2016-01-21 03:50 Is this a new (hidden) feature or a bug? try: Start Lazarus 1.6 or Trunk. open any other unit. So Now, we have at least 2 tabs on editor window. maximize the editor window. click other tab. (if the first unit is active, the second unit is then being activated). result: the editor window is moved a few pixels, but the state is still wmMaximized (has restore button on title bar). It happened once per-maximed. So when I click the first tab again, the editor window didn't move any more. It doesn't happen on non-maximized window. But when I restore and maximized again and click other tab, the editor window moved again. I am using Windows XP. It doesn't happened with Lazarus 1.4.4 ---------------------------------------------------------------------- x2nie · 2016-01-21 03:59 I found another bug that is may related to above bug: Now I am using Win XP with Luna Theme (the blue taskbar theme). When clicking other tab, the editor window was not moved, but flickering! it happen always for any click. When I click the third tab: flickering. Also click the first tab again: flickering. Is it known bug or a new bug or there is something I missed to configure Lazarus ? ---------------------------------------------------------------------- x2nie · 2016-01-21 04:05 possibly these are related to new feature ? : http://wiki.lazarus.freepascal.org/Lazarus_1.6.0_release_notes#IDE_Cha nges IDE ChangesEditorOption for multi-line notebook-tabs ---------------------------------------------------------------------- Martin_fr · 2016-01-21 14:48 I would say the movement is a bug, and you also get it when navigating using codetools (jump to implementation, ....) It MAY have something to do with the (questionable feature) that, if you move a (not maximized) source editor a few pixels out of the screen, and then perform any of those actions, the window gets moved back to the screen. IMHO/IIRC that was meant only to happen when the window was first shown (created + visible). In case session info was from a different setup (e.g. laptop with external screen) ---------------------------------------------------------------------- x2nie · 2016-01-21 16:12 @Martin_fr: I have a clue! The reasonable (feature?) of that moved is : avoiding the editor window of being "off screen". It is normal: move the window into correct screen area when that window has been out of screen area. MAYbe, the problem is about: how to detect whether a window is out of screen? checking the negativeness of top+left property will drive to this bug, because when a form is maximized/fullscreen, the top&left property will somehow be negative (in windows). Sure,  in this situation (negative top&left) is also indicate that the form is located outside the active screen. This detection is false positive, meaning wrong logic. If so, possible solution is to also check bottom&right property. Or, simply check if screen's area (TRect) was no longer overlapped with the form.boundsrect. ? Whenever screen area is still intersect with form area, the form is visible in active screen; otherwise, the form was completely out of screen. Anyway, I just guessing of possible/reasonable "feature" purpose. ---------------------------------------------------------------------- x2nie · 2016-01-21 16:23 attachment is perfect pixel placement of that bug. it seem that it just moved as far as form's border. so, yes. the editor form is moved from off-screen into visible screen, only by the form's top+left. Because the bottom+right property are got more off-screen than before. width and hight are not changed. ---------------------------------------------------------------------- Martin_fr · 2016-01-21 17:41 1) "negative" my desktop (vista) has coordinates ranging from (-1680, 0) to (1579, 1280). It is about the bounds of the correct screen. So even "half on one screen / half on the other will be an issue) 2) as I said: good feature when window is created, But if I then move it a few pixel out of screen (because I really do not need to see the border), then it should stay there. Actions such as codetool or tab change should not trigger this.