Community
Participate
Working Groups
I cannot provide a simple case of this, but I did have an easily reproducable case while developing the new emulated Tree, so I probably can still reproduce this if needed. Each TreeItem invokes GC.setClipping(int,int,int,int) when preparing to paint. In the problem case there was a negative width value being passed as an argument, and this would eventually lead to a GP. Negative values should probably be clamped to 0.
Fixed > 0107. Based on win32 behaviour, specifying a negative width and/or height is fine, it just means that the resulting rectangle will reside to the left and/or above the specified x,y corner. Some platforms were handling this fine (ie.- like win32) while others seemed to be clamping negative dimensions to 0 under the covers. So made all platforms consistently behave like win32 now.
Reopening report since this issue probably exists in other api as well. Should do a consistency pass.
GG do you want to take this one as part of consistency? I'm giving it to SSQ for now because he noticed this when browsing changes.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
