Hacking A Fake Button
If you do any fooling around with CSS layouts you'll more than likely see terms like "an ugly brilliant hack". An oxymoron for sure but something we should be used to as Domino developers. Being a good Domino developer often means being able to second guess what will happen when you try things that they wouldn't teach you on any Lotus training course. For example, here's something Mike and I were playing with today. I won't bore you with why I was trying it but just show what the result was. Add a field to a form and call it "cfdButtonTest". In the Default Value property enter the following formula:
@If(@IsDocBeingEdited; @If(Status="Awaiting Approval"; "Approve"; "Submit for Approval"); "[<input name=\"cfdButtonTest\" value=\"Edit\" type=\"button\" onclick=\"location.search='?EditDocument'\">]")
In the HTML Attributes property for the field add:
"type=\"button\" onclick=\"" + @If(Status="Awaiting Approval"; "doApprove()"; "doSubmit()") + ";\""
What's the hell are you doing Jake? Good question. I'm hacking! What this does is fool a field into being a button. In read mode it will show the user an "Edit" button. In edit mode it will show two different buttons with a different label and a different function call that depends on the status of the document. Give it a go and you'll see what I mean. Note that the JavaScript function need to be added and scripted to whatever purpose you need them.
What's the point of that Jake? Another good question. Not much! All it does do is save the need for loads of buttons with different labels and loads of irritating hide-when formulae to maintain.
If nothing else it demonstrates what can be done when you think "outside the box" and start to realise that, as horrible as they are, hacks are sometimes a necessary evil in order to get what you want from Domino...
Skip to the 
You can subscribe to an individual
Shouldn't the field be editable instead of Computed for Display?
Computed fields do not have a HTML attribute property
You're right Laurent. Don't know why I wrote that ;o) Changed now. Cheers!
It seems like this would be a lot more maintainable if it were 3 buttons with hide-when formulas instead of mashing all the code into @If statements in a field. Why not just use a button to display a button?
Read it again Chris. Note the following terms "playing with", "what's the point", "not much" and "demonstrates what can be done"....
I wouldn't suggest actually using it.
Okay, so there's a huge flaw in the whole thing that renders it even more useless than I first thought. Oh well, food for thought I suppose. See if you can guess why it's useless beyond belief.
Smoke much weed jake?
For what it's worth I avoid hide-when formulas in situations like this by using a computed table with a row for each workflow state.
This has the advantage that you can click on each of the tabs to see the different combinations of buttons that will be available for each state.
As Chris said you can't have a computed field because the attribute won't be used, but if you use an editable field the formula becomes a default value formula and is only evaluated when the document is composed. In particular it won't be reevaluated when the document is opened in read mode.
You might get around this by using two computed for display fields, one for the button name (shown below as button_name_field) and one for the onclick event (shown below as click_event) and stringing them together with a bit of HTML like this:
[<input type=button value="button_name_field" onclick="click_field"/>]
Where, apart from the two fields, everything above, including the quotation marks, appears on the form as is.
Or you could wrap it all up into one field.