A Simple Discrete-Event Simulation: Part 84

Today I implemented the ability to select graphic elements using a mouse click. This involves sensing the mouse click event and its location, variations of which we’ve already visited, and identifying the graphic element on that part of the screen. For the first pass the code only allows the user to select or deselect one or more items, and the only effect is to change an item’s color scheme. The standard neutral, ready, and waiting colors for components and paths are yellow (#FFFF22), green (#22FF22), and red (#FF2222), and selecting an element simply changes the blue values from 22 to FF (e.g., #FFFFFF, #22FFFF, #FF22FF). Deselecting an item, which is only selecting an item that has already been selected, returns the item to its original state and colors.

The first thing we have to do is sense the (left) mouse click and the location:

Now for the actual scan of components. This code ignores components that do not have graphic representations and stops searching when it finds the first match. In cases where a selection could plausibly select more than one item it assumes that the user will change the display order of the items to make a different item come first in the component list. Visio and other drawing programs do this with the “Send to Back” and “Bring to Front” operations, neither of which have been implemented in this code (yet).

The key is obviously how the components’ graphic representations perform the required hit testing:

There’s a lot to say about this code. The main test is the two lines near the middle and everything else is a special case of sorts.

Note that this checks against rectangles defined both up and down and left and right, and not just down and to the right. The simpler test might work for most rectangular area components but would fail for Path components that run in directions other than down and right. This test performs a naive check to see if the click falls within a rectangular area (that has not been rotated). If the component is not a Path then the test is true and the work is done. If the component is a Path then the process is a little more complicated. The code first figures out the point-slope formula for the path in the form:

    y = mx + b


    y = y coordinate, dependent variable
    m = slope of line, (y2 – y1) / (x2 – x1)
    x = x coordinate, independent variable
    b = y-intercept of line (y value when x = 0)

The code then constructs another line perpendicular to the first line, which has a slope of -1/m. Here it’s important to ensure that we don’t run this code on paths that are vertical, or have infinite slope, and you can see that lines that are close to being horizontal or vertical are handled separately.

I then substitute the second equation into the first, eliminating the y and ending up with

    m1x1 + b1 = m2x2 + b2

    m1x1 – m2x2 = b2 – b1

    x(m1 – m2) = b2 – b1


    x = (b2 – b1) / (m1 – m2)

Once we have the common x-coordinate we solve for the common y, and then we can use the Pythagorean Theorem to determine the shortest straight line distance from the click location to the line of interest. If the click point isn’t close enough (the setting is currently 5 pixels) then the routine returns false and the search through the component list continues.

If lines are nearly horizontal or vertical the code simplifies things a bit. It basically tests to see whether the click point is within five pixels of the midpoint of a horizontal or vertical line that is close to perpendicular to the Path or interest. This is not limited to purely vertical or horizontal lines in order to ensure that the hit testing area is a bit larger than it might be if we were only to test within the rectangle defined by the endpoints. A purely horizontal or vertical line would yield a test rectangle of zero width and lines that are nearly horizontal or vertical would be almost as bad. Who wants to limit the user in such a way?

Finally, the innode and outnode subcomponents of Bags are handled down at the bottom.

A few improvements are needed here. The testing for the size of the innode and outnode subcomponents of Bags needs to be parameterized. The test for rectangular components needs to be able to test for elements that have been rotated. I’ve written code for this previously and there are a couple of ways to do it. The entire process needs to be modified to handle different levels of zooming and magnification. I’ll be working through all of these processes over time.

The last bit of code has to do with highlighting and unhighlighting the components’ graphic representations, which is pretty straigthtforward:

The value for this.highlighted is initialized to false above this. This can all be more generalized.

Once an item is selected we can start to interact with it in various ways. We’ll do that and more going forward. In the meantime, feel free to click on the different components and see what it takes to get each of them highlighted and unhighlighted. This all works whether the simulation is running or not, for now. I chose a fairly simple set of color changes and something with a higher contrast would probably be better, but what I’ve done serves the purposes for demonstration.

I have not yet implemented a way to select moving entities, but that process would be even simpler than selecting components, at least for circular ones. More complicated entity shapes and orientations are obviously possible.

This entry was posted in Software and tagged , , , . Bookmark the permalink.

Leave a Reply