#3248 closed defect (invalid)
OMEdit enlarges vertically when switching into Modeling mode
| Reported by: | massimo ceraolo | Owned by: | Adeel Asghar |
|---|---|---|---|
| Priority: | normal | Milestone: | 1.9.4 |
| Component: | OMEdit | Version: | trunk |
| Keywords: | Cc: |
Description
The issue was tested on a win8 laptop, with the very common 1366x768 resolution, and OM r25117.
Steps to reproduce the issue:
1) go into plotting perspective
2) resize OMEdit so that it occupies vertically roughly 80% of the available vertical space (screen1.png)
3) click on "modeling" to change perspective
=> OMEdit has resized so that it vertically falls below the taskbar and more! (screen2.png)
This is especially annoying since it occurs many times, in normal usage.
In fact, when OMEdit is kept in a window, in normal usage one switches continuously between modeling and plotting perspectives, and therefore he has to continuously move and resize the OMEdit window to switch into plotting perspective. Unless he gives up the lowest part of OMEdit window.
Attachments (2)
Change History (15)
by , 10 years ago
| Attachment: | screen1.png added |
|---|
by , 10 years ago
| Attachment: | screen2.png added |
|---|
comment:1 by , 10 years ago
follow-up: 3 comment:2 by , 10 years ago
When it starts to happen, it happens continuously.
Yesterday I had that behavior on a new computer with a new resolution, and I thought that there was a connection with the resolution, but today on that PC I was not able to reproduce the issue.
I will make additional tests and in case I find something, I will add an additional comment to this ticket.
If I were in our position, I would also have a look at possible places in which the code changes the windows size without any user resizing action is made.
follow-up: 4 comment:3 by , 10 years ago
Replying to ceraolo:
When it starts to happen, it happens continuously.
Yesterday I had that behaviour on a new computer with a new resolution, and I thought that there was a connection with the resolution, but today on that PC initially I was not able to reproduce the issue. Then it happened again, but I could not find a repeatable procedure to reproduce it.
I will make additional tests and in case I find something that can be reproduced, I will add an additional comment to this ticket.
If I were in our position, I would also have a look at possible places in which the code changes the windows size and no user resizing action is made.
There is no code where window size is changed. The size of MainWindow is only set in MainWindow constructor i.e before even OMEdit is made visible to user for the first time.
comment:4 by , 10 years ago
There is no code where window size is changed. The size of MainWindow is only set in MainWindow constructor i.e before even OMEdit is made visible to user for the first time.
This means that this issue is very difficult to identify and solve since it may be caused by everything and happen only on some computers or some computer configurations.
I think that the only thing to do is to wait.
After all it may dissolve naturally, in case it depends on writing in other parts of code to an unallocated memory cell (and that part of code is independently modified). Or it could become clearer in case a combination of events that triggers it is found.
Fortunately it is a minor issue. We can live with it.
Thank you for spending time on it.
comment:6 by , 10 years ago
I was just thinking about this issue and I think it might be related to Windows Aero Snap. So it might be a feature instead of a bug. Could you try disabling it?
Go to Control Panel->Ease of Access->Ease of Access Center->Make the mouse easier to use and check Prevent windows from being automatically arranged when moved to the edge of the screen.
comment:7 by , 10 years ago
there's a special PC on which the issue is very frequent.
It is in the classroom in which I give lessons on Fridays.
So I will let you know on Friday evening.
comment:10 by , 9 years ago
It's not easy to check now since it appeared frequently on a classroom pc, last year.
I will held classes again with OM in that room next semester, but in the meanwhile PC has been changed.
I propose to close this ticket by now. In case I see again something similar, I can open an new one.
comment:11 by , 9 years ago
| Resolution: | → invalid |
|---|---|
| Status: | new → closed |
I tried like almost 100 times but was unable to reproduce the issue.
Does this happen always or just in some cases?
Does this happen when a particular model is opened?