Reference no: EM131363

1. Relative positioning of Objects in a Window

The program should draw a rectangle at the middle of the screen when started. The program could maintain a "relative" positioning of the object when resized.

For illustration, when the program is first executed, the figure is drawn at the center of the window, e.g., at 200, 200 with a 400 x 400 window. If the window is resized to, e.g., 600 x 600, the figure should remain at the center ( ½ x and ½ y ), now, 300 x 300. That is, the figure's position have to be relative to the area displayed by the window. A figure positioned at the center of a window will remain at the center of the window (rather than at the same x, y coordinates), even when the window is resized, and, hence, the client area size changes. Similarly, a figure at, e.g., x center and ¼ of the y size when the window size is changed will remain at those relative positions with any size windows, e.g., at 150, 100 with a 300 x 400 window will be 75, 50 when resized to 150 x 200. Note that resizing typically will not be symmetric for x and y change, which is fine, just have the same relative positions for the fig-ure's x and y.

2. Clicking and Dragging

The user should be able to "drag" the figure (object) anywhere on the screen by "mousing down", i.e., depressing and holding down the left mouse button, in the object and then moving the mouse.

The object in essence "follows" the cursor, as long as the left button is pressed down. This is accomplished by re-peatedly drawing and erasing the object as the mouse position moves. Erase only the object, vs. the entire client area. Again, when the object is dragged, feedback about its position is to be given to the user, i.e., it is repeatedly repositioned as the mouse cursor moves. Also, when it is selected and being dragged, feedback to the user is to be given to the user that is has been selected, by changing the solid outline of the figure to a dashed outline.

When the user releases the left mouse button, dragging is over, and the object has a new position. Recall that resiz-ing of the window should result in the relative positioning of the object (at its new location) in the window.

3. Animated Repositioning by Clicking

Provide functionality to allow the user to reposition the figure at a point indicated by "clicking", i.e., pressing and releasing, the right mouse button. When the right mouse button is clicked, the movement of the object should be animated in its movement to the new location, i.e., the figure should move in a straight line from its old position to its new position.

4. Enhancement: Differing Animation Speeds

Use the timer (as described in Petzold and which we'll talk about later, or any other method) to vary the speed at which the figure is repositioned using the right button, such that the figure initially moves slowly toward its new position when the button is released, speeds up toward the middle, and slows down at the end, using, say 1/3's of distance to define start, middle, and end.

Implementation notes:

As noted in class, programming complex API's can be, well, complex. One way to handle the complexity is to pro-gram "incrementally" by making a series of fairly small (often 1 line) modifications, testing each thoroughly (e.g., MessageBox's for variable values and to slow it all down, MessageBeeps to see what's executing), and proceeding iteratively until all functionality is implemented in your program. Though I'm in general glad to help in any way, it is in practice quite a challenge to go beyond a function call or two in finding any problems, and the best help I might give would be when the question is quite narrow. The debugger with breakpoints and single stepping can be a very valuable, and perhaps necessary, tool in Windows API programming. If you've not mastered it by now, it's time.

Detecting when button presses occur in particular areas of the screen is hit testing, as discussed in class. Doing it simply and transparently is likely preferable for your first programs to using the several Windows API functions that are available to do similar things. As a general note on Windows API programming for this course, as with any pro-gramming, there are certainly many ways to do things! What happens as one begins to explore the wide range of functions not discussed in class or in Petzold is that "subtleties" of usage arise, plenty of which have no real docu-mentation, and then you're pretty much on your own to figure things out - which is fine, just heads up! The presentations in class to date have been designed to introduce you to the rudiments of event driven programming and have focused on transparency of control flow and functionality. These pedagogic examples are also pretty easy to debug. Similarly for the Petzold examples, despite some elements of advanced C programming, those ex-amples are about as straightforward as can be. They were designed to be that way. The class presentations have also focused on "unpacking" those programs and have been selected to provide code examples useful in your as-signments.

For the relative positioning with window resize, etc., recall that the event handling function is repeatedly called, so use of static variables for figure location.

The animation can be accomplished with a simple loop at this point that does not relinquish processor control. Bad form later, but ok for now. We'll eventually learn about the timer. If you've had a course in graphics, Bresenham's algorithm would be perfect to determine the successive x and y locations for drawing the animated figure. If you're not familiar with Bresenham's algorithm for line drawing, fine, just use real values from the old y=mx+b equation (what's a microsecond more or less). There are lots of ways to do the animation that are inelegant, but work, and they are fine.