I can’t really see anything on the screenshot. But it’s easy to understand why you have a gap.
Let’s make a simple example: you want to paint 2 columns 100 pixels wide. But your window is 205 pixels wide. You will get a gap of 5 pixels. You either need to make the second column 105 pixels or you need to distribute the 5 pixels to both columns.
Likely you’re seeing a gap because in the division of your Window width by 7, you’re probably getting a decimal portion as a result, e.g., 120.65. And the width or height of Xojo objects typically only accept Integer (whole number) values. Which means any decimal portion of the number is either truncated or rounded incorrectly. So when you add up the width of all the “DayBox” objects, the total is less than the actual width of the window. Thus, the gap.
Others may recommend solving this sort of issue using a different approach, but if this was me, I might try the following bit of code:
Var w As Int32 = Floor(Window.Width / 7) // round down to a whole number
DayBox1.Width = w
DayBox2.Width = w
DayBox3.Width = w
DayBox4.Width = w
DayBox5.Width = w
DayBox6.Width = w
DayBox7.Width = w + (Window.Width - (w * 7))
The width of the last DayBox will be slightly wider than it’s siblings, which should make up the gap you’re seeing. Of course you could add the left-over portion to a different DayBox, it doesn’t have to be the last one. That’s up to you.
Well, I think it does. But what you might find is that the use of Doubles with Graphic object dimensions and positioning may not align with the pixel density of your monitor. For example, if you’re using a non-retina display (Scale Factor 1.0), you can draw a line that is 1.5 pixels thick (but it won’t look like it). Which is why I usually round any graphic dimension to a whole number and treat the math as Integers to get a sharper look to things, even on a Retina display.
Edited: If you want to make your graphics ultra-sharp on a Retina display, you may need to use the current ScaleFactor in your math, so your output matches what the current display will produce.
That’s perfectly clear now, but also a notable peculiarity the fact that objects cannot directly “string” decimals.
If I’m not wrong a Xojo object can handle the decimal value but not in real time, using a Property as to store the “preference about grade of approximation” to be used along for ***next graphic operations.
Xojo doesnt work on decimals (yet) and you may wait a long time for it to happen.
I offer 3 further refinements to the solution above , however:
if you have 7 columns and the width of the window does not divide by 7 to integers:
1/ change the window size so that it does, or
2/ add a small border left and right to account for the extra pixels
3/ add a pixel to some of the columns, not just the one at the end. For example, if you have 4 spare pixels, make 4 of the columns 1 pixel wider, instead of the last one 4 pixels wider.
From a quick look at SimpleDraw 2018 it seemingly uses realbasic.rect which don’t support doubles. Xojo switched over to doubles for all drawing routines a while back (with the introduction of Rect) and it would seem that the SimpleDraw 2018 library you’re using is the issue here which will be causing the rounding issue you’re getting. As you will probably encounter numerous issues with scaled desktops in the future which rely on decimal placements you might want to refactor the library to use doubles throughout or switch away from that library.
Thank you Julian, that’s good to know, unfortunately SimpleDraw 2018 is the only version I’ve been able to get. If I just need to change the realbasic.rect to Rect I think I can just do it by myself, should be an easy work to modifying this few lines:
Dim NewRectangle As New Realbasic.Rect(Rectangle.Left, Rectangle.Top, Rectangle.Width, Rectangle.Height)
NewRectangle.Left = NewRectangle.Left + xDelta
NewRectangle.Top = NewRectangle.Top + yDelta
Return NewRectangle
However here my result, creating an ObjectClass for each 23 hours of 7 days, I don’t have implemented any Db fetch yet but still very slow.
The correct way to handle this is to spread the remainder out over the columns.
// Window Width is 1200 in this example
Var ColumnWidth As Integer = Floor(Self.Width / 7) // 171
Var Remainder As Integer = Self.Width - (ColumnWidth * 7) // 3
For ColumnNumber As Integer = 1 To 7
Var ActualColumnWidth As Integer = ColumnWidth
If ColumnNumber <= Remainder Then
ActualColumnWidth = ActualColumnWidth + 1 // 172 for columns 1-3. 171 for columns 4-7.
End If
Next ColumnNumber
There are ways you could compact the logic a little, such as using an inline if statement to compute the individual column widths. I made this code intentionally verbose for the same of demonstration.
This way every column looks exactly the same width to the eye, but they aren’t really.
Thank you Thom, your interest is really appreciated, I yet figured out such a kind of solution even if I think an automatic rounding system based on double values to >absolute destination values< should be considered to be implemented too.
