Okay, after reading your updated question - forget what I wrote below, although some of the principles may come in handy...
It sounds a bit of a weird way to control a washing machine - having the user press buttons to trigger things manually. It's like using an old twin tub from the 70s. Pump water in, drop in soap powder, set the machine stirring. When it's finished try and get the clothes from the washer to the spinner without flooding the kitchen and so on.
Wouldn't it be better to model your washing machine's low level controls as a set of objects then link them together using various programs, the way an automatic washing machine does today ? For analogue control you might as well implement a hardware timer as well rather than relying on the computer - so instead of the computer saying "Okay, start...1, 2, 3, 4, 5... stop!" to the various devices it can just say: "Do your stuff for 5 seconds." This avoids the embarrassment of the computer crashing and the motor burning out as it wasn't meant to be on full spin for half an hour.
Anyway, sounds like the question could be more "here's a design for a control system, what's wrong with it?" more than one about windows programming.
 Oo, hang on, you are trying that. One cycle component per button, fired from the first one clicked rather than a triggered dial. The problems with doing it this way are:
- User clicks the start cycle button then for a laugh clicks the spin. The pumps going like crazy trying to force water in while the drum is rotating like mad.
- The computer's doing the timing. Windows is event driven and while on modern hardware I haven't seen this happen in 10 years it can delay timer messages. You'll have to use multimedia timers or some higher resolution ones.
PS: First reply...
Provided this is Win32 we're talking about and not some new fangled .Net malarkey and you mean form application in it's traditional sense then the way I'd go for this would be (using MFC and raw Win32)
1. Sort out where you're going to add code...
MFC: Derive a new class from CButton
Win32: Implement a window procedure that just forwards calls another window procedure
2. Sort out where you're going to store the object you want to forward messages to...
MFC: Implement a constructor that takes and saves a CWnd * as a parameter. This is the address of the CWnd object that you want to trigger a simulated button press on.
Win32: Write a function to add a property to a window called something like L"relay_to" which takes the HWND to the window you want to trigger a simulated button press on (using SetProp).
3. Sort out how you're going to handle the button click...
MFC: Override OnLButtonUp. The override sets a timer (using CWnd::SetTimer on itself) and add the function to the derived class's message map.
Win32: In your window procedure add a handler for WM_LBUTTONUP. In it call SetTimer.
4. Sort out how you're going to send a WM_LBUTTONUP to another button...
MFC: Override OnTimer. The override kills the timer (CWnd::KillTimer) and sends a WM_LBUTTONUP message to the window supplied to the constructor (CWnd::SendMessage). Add the function to the derived class's message map.
Win32: In your window procedure add a handler for WM_TIMER. In it do a KillTimer on the the window and send a WM_LBUTTONUP message to the HWND stored as a property (using SendMessage and GetProp).
5. Wire the whole unholy mess together starting with the buttons...
MFC: In your dialogue box's constructor make sure that button 1 has a pointer to button 2 which has a pointer to button 3 ad nauseum.
Win32: In WM_INITDIALOG of your dialogue box use the function you wrote in 2 to attach the window handle of button 2 to button 1 and so on.
6. ... then subclass the windows...
MFC: Use DDX_Control in your dialogues UpdateData to route windows messages through the MFC message map for your buttons. One call per button.
Win32: Use SubclassWindow to set the window procedure for the buttons to be the one you wrote earlier
7. Stand back, pull the chain and hope it all works.
There's going to be some bits I missed out of that lot (like where do you put the window procedure pointer you get when you subclass in win32) but it should give you an idea of what you're trying to do. And what a balls ache it is.
Interestingly the solution to this is about as complicated using MFC as it is using raw win32 - which just goes to show that MFC is possibly not as high level as most people would like it to be!
The other interesting bits here are all the ways you can simplify this lot and make it vaguely reusable (introduce an action interface in MFC and Win32 so you can dynamically change window's behaviour, add a jump table in Win32 to save needing big switch statements) but that's a whole 'nother topic.
Still want to do it?
If you do you'll come out of it knowing more about windows messaging than man was meant to know.