Functional Replacement for Line Control

This makes me curious as to why they removed the Line control. Does anyone know?

The line control was something so random, that the unique answer that comes to my mind would be a bit offensive to who wrote such component. I had some of them in the past in one app, that when compiled and built, the straight horizontal line got inexplicably diagonal at runtime, another build, it returned to get straight. :crazy_face: So I was forced to remove it from the code. It took ages without anyone trying to fix it, and I can’t imagine why such simple component would be considered something so hard to fix, but instead of fixing it, seems like they preferred just to remove it. :rofl:


I made a program in the past that was for a Rugby scoreboard. It mirrored the top left portion of the screen to a LED billboard. I used a combination of custom images on a canvas, and rectcontrol.DrawInto to create the screen that would display to the billboard. This even works to draw controls from an opened, but visible=false window. Hope this helps.

Thanks, Marcus. I needed to learn/be reminded of the Window Paint Event. The old Line Control made it easier to handle Window resizing and capturing mouse down events (this latter is not a common need). Designing by dragging controls around the IDE is a little easier but under many circumstances, this Marcus solution will do the job and you can write the code to handle resizing as you see fit. :+1:

you could also made some kind of connect point control with a id or control name.
and at runtime (iterate over them) hide it and just paint the lines in the window paint event.
you would have the benefit of designer and resize logic.

if you need a mouse line intersection i found this in web.

boolean linePoint(float x1, float y1, float x2, float y2, float px, float py) {
  float d1 = dist(px, py, x1, y1);
  float d2 = dist(px, py, x2, y2);
  float lineLen = dist(x1, y1, x2, y2);
  float buffer = 0.2;    // higher # = less accurate
  if (d1+d2 >= lineLen-buffer && d1+d2 <= lineLen+buffer) {
    return true;
  return false;

Maybe there’s something I haven’t thought of, but how about a custom class based on the canvas that simply draws a diagonal line across its top-left and bottom-right corners? You can have thickness and color properties. In the pain event, draw the line. Implement a close-to-line mouse click detection like Markus suggested. Then, you can simply use that class as a replacement of the line control: drop it on the window, create at runtime, resize, change color-thickness, etc. If you name the properties correctly, it’s almost a drop-in replacement for the line control.

I did a small test and it seems to work fine. You can have the properties shown in the IDE if you want to set default values for line color and thickness.

Here’s a quickie:

Class LineClass
Inherits Canvas
   Sub Paint(g As Graphics, areas() As REALbasic.Rect)
      g.PenSize = me.Thickness
      g.DrawingColor = me.LineColor
   End Sub

   LineColor As color = &C00000000
   Thickness As Integer = 1

you forgot that the ide have no preview at design time. instead of a line it will be much unhandy overlapping rectangles.

This is a killer lack of feature that inhibits people of creating great Visual Components. Things as preview or live datagrids, preview or live charts, etc.

A line does not have a “top-left” point, it has a starting point and an end point. It may start at a bottom-left place for example and going upwards. Click, start-point, move towards anywhere, release, end-point. You must save those coordinates with the component/object.

1 Like

@MarkusR You’re right about the lack of preview, but then again, neither will using a global canvas to draw lines. At least you see the rectangle where the line will be. Like Rick said, it would be awesome if we could have the ability to generate a preview to create our visual components, but for now we can’t.

@Rick_A The points I’m referring to are the corner of the canvas. With the old line control, when you place the control in a window, you had a rectangle and the line was drawn from top-left to bottom-right. If you wanted an horizontal line, you had to enter the same value for y1 and y2. So the subclass will mimic this same behaviour.
My idea was to have a drop-in replacement for the line control with the same properties and that could be dropped in place with minimal change to the code: juste replace every instance of the line control with the “canvasLine” control and leave the rest of the code intact. Place them at design time (with the lack of preview) or at run time. No need to redesign everything with a large canvas or anything.

So that was the design error of the control that made them to remove it. No one could draw a line from bottom-left to top-right.

That was the only way to draw a diagonal with the line control :slight_smile:

If you are correct, because I used it just once years ago, to draw simple horizontal lines, that’s a gross error, so no one could call it a line control. It was a straight to the right or to the bottom line control. And that’s why it was removed. It was a shameful wrong control.

And we could make the replacement a little better by having a property to determine how the line is drawn:

  • horizontal top of rectangle
  • horizontal bottom of rectangle
  • vertical left of rectangle
  • vertical right of rectangle
  • top-left to bottom-right
  • bottom-left to top-right
    And going wild, how about arrow ends, bullet ends, dashed lines? Even a line that has 2 segments like the OP has in his design with properties to determine at what point it breaks.

Everything could be done in pure Xojo. In fact, I think I’ll dig into it just for fun. @Robert_Livingston I’ll send you the code once done. If you have features you’d like to have, let me know.

But for most of the time when I used it (Was that back in REALStudio days or farther back to REALBasic<=5.5?? back when it was usable) I wanted either a horizontal or vertical line so it had WYSIWYG design value.

Thinking back now , IIRC, the last time the line control was usable was before the IDE was written in RB… once that happened it became difficult to use so I stopped using it. That is so long ago the details are a bit hazy… but I know back then I did use it and found it useful… But after that it became mostly useless after it was re-implemented.


You too, eh? I encountered this issue during my very first day of usage of Xojo back in 2014
Corruption Line

It had already been reported by then … and obviously has received no love since!

1 Like

As others have alluded to, the problem with creating one’s own line control using a Canvas is the lack of real transparency on Windows. As you can see in the image below, layering the line on a canvas with an image as the backdrop works:

But once you start adding more layers with drawing in the Paint event, it fails. Here I’ve just added another Canvas that draws from top-right to bottom-left:

As you can see, the second line’s canvas area completely obscures drawing of the first line that occurs within its area. That makes this a non-starter if you’re going to target Windows and layer controls. I would, as others have said above, recommend using a single canvas to draw all of the elements.


Other IDEs have no problems to compose whatever image the user desires using the Win32 APIs and transparency. So it’s not a Windows fault, just something with the Xojo image composition engine.

1 Like

I wasn’t saying that it’s a Windows issue. It’s a Xojo issue on Windows. Context.

1 Like

Ok, clarified.

Ah… you’re right. I tested on Mac. Windows target is a no-go.