Descriptive Problem Summary:
Using winget(..., "window", "size") is reporting an incorrect size on windows just after maximizing or un-maximizing (via the maximize/un-maximize button). To be accurate, it is not updating the size whatsoever, and is reporting the size just before resizing.
I had another programmer help me out to confirm the bug, and he has not reported similar happenings to me. He says maximizing and checking reports the correct data.
He says he has 64-bit Windows 7 Home Premium. I have the 32-bit version. I have made three different projects and done the same actions over and over again, and I seriously cannot come to any conclusion other than a system issue.
Numbered Steps to Reproduce Problem:
1) Create interface.
2) Create verb that reports the size of the default window.
3) Run the project.
4) In DS, use the verb to report the size.
5) Resize the window manually.
6) Use the verb to report the size again. It reports the proper proportions.
7) Click maximize.
8) Use the verb to report the size again. It reports the proportions just before maximizing.
Step #4
Step #6
Step #8
Code Snippet (if applicable) to Reproduce Problem:
Here is a link to a project that has the interface I'm using and the verb.
Does the problem occur:
Every time? Or how often? On my system, every time. On his system, with the same code, never.
On other computers? In two test cases, it only occurs on mine. Need more to confirm.
I recall this method was used to determine the proportions of the user's screen, and I think I did it in the past to test it out. I was using XP then though.
I really have no idea what is causing this. If any information is needed, I'll provide it.
ID:106461
 Dec 30 2010, 9:52 pm (Edited on Dec 30 2010, 10:14 pm)
|
|||||||||||||
Not a bug
| |||||||||||||
|
Dec 31 2010, 2:59 am
|
|
Popisfizzy
 |
I can verify that I have the same issue when testing this.
|
I can also verify this issue.
| |
This is not a bug. The size parameter reports the window's non-maximized size by intention; if you maximize it it will not change.
If you want to get the window's maximized size, one common approach is to fill it with a child control anchored to the corners and get the size of that. | |
Lummox JR wrote:
This is not a bug. The size parameter reports the window's non-maximized size by intention; if you maximize it it will not change. What is the rationale behind this? | |
The rationale is this: if I am toggling a chat pane, I would set the size to 1000x480 to open it, and 640x480 to close it. If window.size is the maximized size rather than the actual size, than something as simple as this would be completely unachievable.
The real request would be to have variables tied to the client for screen resolution and available screen space. | |
Hiro the Dragon King wrote:
The rationale is this: if I am toggling a chat pane, I would set the size to 1000x480 to open it, and 640x480 to close it. If window.size is the maximized size rather than the actual size, than something as simple as this would be completely unachievable.Why would you do that? How would it lead to a chat pane being shown/hidden? And why would it be effected by size if you're just using those odd numbers anyway? Also, why are you bumping some year old topic? The real request would be to have variables tied to the client for screen resolution and available screen space.As Lummox mentioned, you can already find those values through a clunky workaround, but having them built in seems to make more sense. | |
Obviously, I would set the right half of a child to a pane, or make visible a hidden element in that portion of the window, as I do now. And I'm not purposely bumping it. I'm merely adding information to it because people are still wandering through here and bitching about this feature on Chatters.
| |