I"ve been thinking about this all weekend. :)
What you need is an implementation of the Model-View-Controller
architecture for your user interface. Don't panic: you don't need to go
whole hog and implement something tremendously sophisticated. Here is
what you shoud do, in a nutshell.
1. Separate your data—the list of images—from your user interface
handling logic. Make a separate class that holds your list of images
(and, logically, a class that holds information about each image).
Don't be concerned if, at the beginning, these classes seem pretty
thin. As you work through your design you will find various operations
that the classes should offer to your user interfaces (the main form
and the image viewer) that would make their jobs much, much easier. In
the end your "model" classes will probably be the biggest part of your
application.
2. Have your "model" (the list of images and the individual image
class) expose events that happen whenever something interesting happens
inside the model. So, for example, if your user changes the "current
image" in the main form, then it sets the "current" image in the image
list object, and that object then fires a CurrentImageChanged event.
3. Connect the events from the "model" classes to your screen controls.
There are two ways of doing this: simple-minded or sophisticated. For
now, I recomment simple-minded. It's more coding, but it's easier to
understand and easier to get working.
Simple-minded: Create event handlers in your forms that subscribe to
the events from your model. So, in your main form, whenever the model
fires a CurrentImageChanged event, maybe you highlight a different file
name (or maybe you do nothing, because it's already been taken care of
by the UI control). In your ImageViewer, whenever the model fires a
CurrentImageChanged event, change to display the new image. Then make
more event handlers in your forms to respond to user actions on the
screen controls (you probably already have those), and call method in
your "model" classes to take the action that the user wants done.
Sophisticated: You can do all of this with .NET's DataBinding classes,
which means you write much less code. Beware, though: DataBindings are
non-trivial and temperamental. That's why I recommend you start with
your own event handlers and hand-coding, for now.
This may seem like a lot of work, but the beauty of it becomes evident
when you consider this:
User clicks on main view, and clicks on a new image in the image list
in the main view. The event handler for the UI control picks up on the
mouse click, or SelectedIndexChanged, or whatever, and as a result sets
the models CurrentImage property. This causes the model to fire
CurrentImageChanged. Any other views you have open (probably just your
ImageViewer) are listening for this event, and their
...._CurrentImageChanged event handlers run. In the ImageViewer, this
causes the viewer to change the image that is currently showing.
You can expand this to as many views as you wish. From the user's point
of view, one action in one form can result in all of the views
changing, "like magic."
From a philosophical standpoint, what you're saying is this: all of my
forms (the main form and the image viewer) are just different views
into the same data: the list of images. So, I have classes that
represent that list of images, and represent individual images.
Whatever the UI needs to do to that list, it does by calling this
"model". Whatever the UI needs to show, it does by listening to the
"model" and responding to events coming from that "model". The UI
_never_ directly connects a button somewhere to a display changing
somewhere else. Buttons and user-modifiable controls _always_ do their
work by going through the model: user action → event handler →
method call / property set in the model → model event → event
handlers → changes to screen display. That way, all the visual stuff
on the screen is on the same footing, and responds in the same way to
changes in the data.
Often, model-view-controller is overkill for simple screens. However,
for your example, where you have two forms looking at the same data,
it's a natural fit. Read up on it (just search for "model view
controller") and give it a try!
