I can't draw a vertical line at the left-most column of pixels. Likewise, I can't draw a horizontal line at the top-most column. (This is using WindowLine - I'm not sure how many other functions are unintentionally affected.)
I personally assume it is due to the following shortcuts being used but by design locking out the first column and row of pixels from being used for their proper purpose.
Quote:
Rectangle coordinates
In many functions described below you specify the rectangle in which the shapes is to appear (including ellipses, circles, etc.). As a shorthand you can specify a negative number, or zero, for the bottom or right side. This is taken to be offset from the bottom or right edge of the containing miniwindow. For example:
Rectangle: 0,0,0,0 - the whole miniwindow
Rectangle: 2,2,-2,-2 - a rectangle offset by 2 from each edge
Rectangle: 20,40,0,0 - a rectangle starting 20 from the left, 40 from the top, and continuing the the right and bottom edges.
Source: http://www.gammon.com.au/mushclient/mw_shapes.htm
This conflicts with the following:
Quote:
The top-left corner of the miniwindow is 0,0 and then increases horizontally in the "x" direction and vertically in the "y" direction, as per this diagram:
Source: http://www.gammon.com.au/mushclient/mw_creation.htm
A better way to describe the issue is to say that I can't seem to use coordinates that involve a x=0 or y=0 equation.
For the time being, I am using the following workaround:
-- Draw a line on x=0 (topleft to bottomleft of mw)
WindowLine(win, 0, 0, -mw.width, mw.height, 0x0000FF, 0, 1)
-- instead of the more natural (but bugged):
WindowLine(win, 0, 0, 0, mw.height, 0x0000FF, 0, 1)
The above code could 'utilize' the special interpretation of zero to replace mw.height, but that would only clutter the example in my opinion. Or any code, for that matter.
This seems like a bug that should be rectified prior to 5.0 in my opinion. How about using -1 to denote the right-most/bottom-most pixel? I think that is how other libraries handle similar features.
While this is a useful feature in concept, the way I see it the current implementation will cause odd quirks to find that might even need working around on if values are calculated. Using -1 and lower for this purpose would not take away any options, but it would prevent people plenty of debugging problems later on. (I know I spent 30 minutes trying to figure out why my simple line was bugging out like it was.) |
![[Go to top]](/images/gototop.gif){kind=small}
top