Okay, I start to understand! As TRon mentioned ("The coordinates of a rectangle inside a scrollbox/image are absolute to that same scrollbox/image. So left/top coordinate 0,0 means either 0,0 of the scrollbox canvas or the image canvas. Any coordinate/pixel that does not fit onto the canvas will be clipped. So i suspect that your rectangle isn't visible because you draw it outside the visible area of your image/scrollbox canvas.")
Indeed and as pointed out by Handoko.
Things depend on how you implement them and for that it is advisable to use the road of the least resistance (you seem to ignore that road) :-)
Thus, whenever you use mouseevents such as OnMouseUp, OnMouseDown and/or OnMouseMove the x and y coordinates that are passed along those events are those coordinates that belong to the component which "fired" the event.
The same goes for OnMouseEnter and OnMouseLeve in that the events are fired when the corresponding component fires the event(s).
So the x and Y coordinates of a OnMouseClick for a TImage correspond to the x and y coordinates within that component, top-left corresponding to x,y of 0,0. At the same time when that event is fired you also know which image was clicked because the image that was clicked sens a pointer of itself by using the sender parameter.
Thus as long as you attach a handler to the OnMouseClick event you do not even have to check for mouse coordinates whether or not they belong to a particular Image component because you already know which image was clicked.
The same logic can be applied to TScrollbox. These mouseevents are only fired when the mouse event happens inside the scrollbox and also here the x/y coordinates correspond to the left top of the component itself, thus 0,0 being left top onside the scrollbox.
But, there is one small thing differs in comparison to other components and that is that it is a container with a scrollable
view. The x and y coordinates passed in these mouse events are those of the visible area of the scrollbox (the part of the scrollbox where you are looking at at that exact moment). The issue there is that the (left-top) coordinates of the components themselves that are placed inside the scrollbox are not corresponding to their real coordinates inside the scrollbox because the possibility arise that the current view is 'shifted' from the original 0,0 top left coordinates of the client-area of the scrollbox. Ergo you need to compensate for that using the scollbar range and only when you want to 'calculate' the placement of a particular component that is situated inside that scrollbox.
As you can see for yourself the latter only applies when you do not physically placed the components inside the scrollbox (whether done manually by using the visual designer or at runtime) but in case you only draw something to the surface (client area) of the scrollbox. Then there would be need to do manually check for mouse coordinates.
So I believe that you still do not fully grasp the concept because the last solution shown is doing all kinds of calculations and there is absolutely no need for any calculation whatsoever. The event happened, and it happened inside the clicked component thus as long as every timage placed on the client area of the scrollbox has that event assigned then it becomes easy.
This is also why I opted to create a small test project to tinker with because when a scrollbox is placed onto a form, and the visual designer is used to place several image components on the client area of the scrollbox, then assign a (single) mouse event to/for all these images then you can are able to come up with the same conclusion in about 2 seconds.
Just saying