Take a look at the picture. I opened a new group window. Here's a picture of where EViews opened it. I haven't moved anything. A window shouldn't open with the title bar hidden under the command window.
Window position bug
Moderators: EViews Gareth, EViews Moderator
-
- EViews Developer
- Posts: 799
- Joined: Tue Sep 16, 2008 3:00 pm
- Location: Irvine, CA
Re: Window position bug
Is your command pane set to Autohide? Since your screenshot doesn't show the right pin icon of the command pane I can't tell. If so that's why the group window could appear there.
If not, is the window issue reproducible?
Sent from my iPad using Tapatalk
If not, is the window issue reproducible?
Sent from my iPad using Tapatalk
-
- EViews Developer
- Posts: 799
- Joined: Tue Sep 16, 2008 3:00 pm
- Location: Irvine, CA
Re: Window position bug
Actually now that I've taken a closer look at your command pane, it looks like it's in Float mode. Meaning you've undocked the pane and instead told the window to hover at that spot. If you grab the main EViews frame window and move it, the command window will stay put. You'll have to dock the command window or move it outside of EViews to prevent this overlap problem.
Sent from my iPad using Tapatalk
Sent from my iPad using Tapatalk
-
- Non-normality and collinearity are NOT problems!
- Posts: 3775
- Joined: Wed Sep 17, 2008 2:25 pm
Re: Window position bug
The fact that there's a solution doesn't explain why EViews chooses to initially display the window in a bad position.
-
- EViews Developer
- Posts: 799
- Joined: Tue Sep 16, 2008 3:00 pm
- Location: Irvine, CA
Re: Window position bug
When a window is floating, that means it's outside of the EViews frame window. And when it's outside, EViews doesn't consider it when it decides on placement of any child windows inside the main frame window, even if that window is floating on top of EViews. Also, our floating windows always appear on top of the main frame window, even if you click back into the frame area and move it around.
So technically, you could cover the entire main frame window with a floating command pane. In that case, it doesn't matter where a new child window appears since it'll never be viewable until the command pane is moved away or sized smaller.
Maybe we should consider letting you click in main frame window to bring it up above any floating panes? But then you could potentially lose sight of the command pane altogether as it drops behind.
Is there a reason why you don't have the command pane docked to the frame? When docked, it's inside the frame window and new child windows will appear away from it. Click the Window menu/Reset Window Layout to reset your windows to this default layout.
So technically, you could cover the entire main frame window with a floating command pane. In that case, it doesn't matter where a new child window appears since it'll never be viewable until the command pane is moved away or sized smaller.
Maybe we should consider letting you click in main frame window to bring it up above any floating panes? But then you could potentially lose sight of the command pane altogether as it drops behind.
Is there a reason why you don't have the command pane docked to the frame? When docked, it's inside the frame window and new child windows will appear away from it. Click the Window menu/Reset Window Layout to reset your windows to this default layout.
-
- Non-normality and collinearity are NOT problems!
- Posts: 3775
- Joined: Wed Sep 17, 2008 2:25 pm
Re: Window position bug
Let me remind you that
1. Good design prevents user "error."
2. There is a longstanding design goal in EViews to make sure that the design prevents my errors, taking me as the lower bound on users. (Ask G or G.)
1. Good design prevents user "error."
2. There is a longstanding design goal in EViews to make sure that the design prevents my errors, taking me as the lower bound on users. (Ask G or G.)
-
- EViews Developer
- Posts: 799
- Joined: Tue Sep 16, 2008 3:00 pm
- Location: Irvine, CA
Re: Window position bug
Hah, thanks for the reminder.
Honestly, if there's a solution you can think of that will work in all situations, I'd be happy to consider it -- and I realize that this "error" is exacerbated by the fact that we never had floating panes before. Right now, I can't think of one solution that wouldn't be just be for this particular situation. Like, if a floating pane is covering the frame window, but only a portion of it (say 50% overall? or just top 50%? right 30%?), then position new windows to appear in the uncovered portions of the frame (as long as there's enough room?), etc.
I wonder if we can make floating panes semi-transparent, at least the portion that is covering the main frame window. That could look weird though...
Or maybe we should just optionally make the floating panes act like normal windows so they can be hidden by the main frame. This would force users to keep them outside the frame window area.
Honestly, if there's a solution you can think of that will work in all situations, I'd be happy to consider it -- and I realize that this "error" is exacerbated by the fact that we never had floating panes before. Right now, I can't think of one solution that wouldn't be just be for this particular situation. Like, if a floating pane is covering the frame window, but only a portion of it (say 50% overall? or just top 50%? right 30%?), then position new windows to appear in the uncovered portions of the frame (as long as there's enough room?), etc.
I wonder if we can make floating panes semi-transparent, at least the portion that is covering the main frame window. That could look weird though...
Or maybe we should just optionally make the floating panes act like normal windows so they can be hidden by the main frame. This would force users to keep them outside the frame window area.
-
- Non-normality and collinearity are NOT problems!
- Posts: 3775
- Joined: Wed Sep 17, 2008 2:25 pm
Re: Window position bug
I can think of three partial fixes.
(1) A new window should always come out on top, even over floating windows. (Don't know if that's possible.) I guess that might in some cases just give the same problem with the floating window.
(2) Kludge things so that EViews tries real hard to have the title bar visible in a new window.
(3) Add a command to the Window menu that does "bring to front" and offers a drop-down of existing menus.
(1) A new window should always come out on top, even over floating windows. (Don't know if that's possible.) I guess that might in some cases just give the same problem with the floating window.
(2) Kludge things so that EViews tries real hard to have the title bar visible in a new window.
(3) Add a command to the Window menu that does "bring to front" and offers a drop-down of existing menus.
-
- Fe ddaethom, fe welon, fe amcangyfrifon
- Posts: 13319
- Joined: Tue Sep 16, 2008 5:38 pm
Re: Window position bug
Follow us on Twitter @IHSEViews
Who is online
Users browsing this forum: No registered users and 26 guests