IBM's CheckBox Cop-Out
The fact that Domino's got a bug should be news to none of use. Most of them are fairly minor and easy to get round. However, there's one bug in particular that affects checkboxes, which I consider pretty major on the scales of things, and can not believe it has never been fixed. Today I found out it's because:
This issue was reported to Lotus Quality Engineering and has been determined to be a software limitation of web browsers.
This to me is a complete cop-out. I've spent most of this morning looking at the problem and possible solution and have come to the conslusion that the "limitation" is in fact with Domino. This blog was going to discuss the ins and outs of the whole subject but then I realised there's enough meat in it to warrant its own article. In it I will cover the issue, the background, why Domino is different to other web servers in this respect and, most importantly, a solution that's a little easier to digest than this one. Will try and get it out tonight at some point while it's still fresh in my mind. I'll try also to go easy on the whole Domino's crap rant.
Talking of crap. Patrick Read mailed to confirm my long-held suspicion that SearchDomino.com is "officially crap". In his daily mail of tips from them today he received what has to be the least useful Domino tip ever.
Thanks to Mark Davenport for his extremely generous gift from my wishlist. Which, he says, is for "making me seem much smarter than I am to the people I work for". Hope that doesn't burst your bubble Mark!
Skip to the 
You can subscribe to an individual
Did you noticed the rating of the "useful Domino tip"?
11 Nov 2002, Rating 4.57 (out of 5)...
Good tip... yeah right...
Clearly, the checkbox issue is domino's problem.
I've wasted some time on this problem (not to mention the 5.0.9 where you could *never* empty a field, checkbox or not, grr)
It is true that if no checkbox is checked, the field name will not be sent in the POST message (thx ethereal...), but the server should look for those missing records and assume that they are now empty...
I dont understand why domino does that with a @formula button and not with a submit(): the both post are 99% the same, i can only see the "__Click" changing (i may be wrong)...
anyway, my workaround was to add right after the field some HTML pass-through :
<input type="hidden" name="chkboxfieldname" value=" ">
this way domino knows that the field is to be updated...
Careful Jerome, you nearly stole the thunder from my article ;o)
You're spot on though in your analysis. I will try explain all later on. Although why it works in a formula button is a complere mystery and just adds weight to my argument that IBM's explanation is a total cop-out!
I agree that SearchDomino tips are useless. Just goes to show what happens when you overcommercialize a tech site to the point that it requires a full time Editor with a publishing/business background instead of technical skills.
Also CodeStore.Net was recently added to the Domino SuperSearch http://MartinScott.com/SuperSearch
Like Pat, I also get those tips daily and never read them. I think we should organise a campaign to have everyone rate that tip as a 0 on SearchDomino.
Well, it's better than Notes.net. There are less unintelligible posts on SD. I've personally had some good responses to my dumb questions, which have gone unanswered in Notes.net. But it was better as Lotus411.
Novice questions seem to be the biggest irritation in both places. There doesn't seem to be a forum without novices, which is fair enough as everyone has to start somewhere.
Apart from the newsgroups, is there a good forum out there?
Well, there's this one:
http://notes.bluedojo.com/
... there's a forum linked to from Rune's site:
http://www.dominozone.net
... and then there's this one which is new to me:
http://www.notesnet.com
I still think the LDD has the edge though, despite the newbie questions. I never really got on with SearchDomino, especially as half the code posted hasn't been proof-read (a bit like mine;-)
On the subject of bugs I've come over quite an annoying one.
It seems that if you do a greater then check on a number list then it doesn't work.
num := @AttachmentLengths / 3500;
@If( num > 60; "Yes"; "No")
If num contains 2 values say 21 and 78 and it goes through the if statement, the if statement will return "Yes" for both of them, if you change the > to a < the same thing happens!
I searched like mad in the knowledge base, and notes.net but I can't find anything that mentions it! Tell me I'm not crazy!
----------------------------
Oh and I also agree that SearchDomino is poo! - I couldn't believe it when Lotus411.com went! Mainly for the fact that I one two t-shirts off there, and they were of such high quality!!
I have come across a similar problem recently. There is a textarea field. The implementation is done in the usual domino style (computed for display field). When we edit the field it works fine. But when we delete all the contents of this textarea field (and make it blank), it wont delete the contents but keeps the original contents intact.
I have also encountered the checkbox problem several times...
The easiest workaround (as far as I know) is to add a regular "notes" button to the form (with some @Command formulas in it), give it an Id -- for example "hiddenSaveButton" and hide it with CSS(display:none).
In your validation script, use the ID to access the buttons "click" method:
for example:
document.getElementById("hiddenSaveButton").click();
or:
document.forms[x].hiddenSaveButton.click()
This works unless you have to use a form treated as HTML...
Ok, it's perhaps not the "easiest" solution... that would be to add the hidden field I believe... :)
For the number list comparison, try using the permuted comparison operator *> instead of just >.
Check out the "Operations on lists" section in Domino Designer. I think that'll fix it.
Cheers, Chris.
I can see at least one reason for the way Domino behaves with regard to checkboxes -- hidden fields/alternate forms. If Domino assumed a "cleared" state for a no-field return, then documents could be unintentionally altered. This isn't a problem on other platforms, since there is a divorce between the form qua form and the script that is invoked on submission. Domino is rather unique in that the form and the "CGI" are one and the same. Domino has no way, really, to inform the browser that the missing field acually exists, and that it should be returned in the mix, except through the _Click mess, and we get to the _Click through @Stuff. Does that solve the problem? No, but it at least explains why the problem exists in the first place.
Stan. I too can *almost* sympathise with Domino's predicament. Taking it to the extremes, let's say you have a form with 300 fields on it. Some hidden, some not. Only a handful are rendered to the web and so the browser only returns a few of the 300. How does Domino know which to blank when the browser doesn't return it.
Obviously the server has to see IF it sent any checkboxes with the form. If so and none are returned - hey presto - blank it out. It's as easy as that. The fact that it can work with an @Formula button proves it's possible...
The reason this bug does not occur with the @formula button is that the forms is generated by Domino and upon creation it sets some code to tell what fields it send to the browser and gets that when the form is posted.
If the server has to detect with javascript submit or type="submit" buttons what checkboxes were sent to the browser, it needs a hidden field that return the same kind of value. Is this actually something we want, Domino generating another hidden field that we cannot control?
A what to do with forms that threat contents as html, and inline forms like this one?
The server never sent any checkboxes to the browser, but how can it know this?
In my opinion it's too easy to just blame IBM's engineers for this bug. The problem is very complex and turn out to be a limitation caused by some of the options that makes Domino so powerful in other situations.
-Laurent
Sorry Laurent but I have to disagree with you on that one. The _Click field merely tells the server which button was pressed and *not* what fields were sent. To work out the fields that are *expected* when a POST submit is received all DOmino has to do is parse the form!
Now you tell me it was a bug?!
I only recently came across this problem & I thought I had done something wrong somewhere. I had to change 20+ fields that were check boxes to radio boxes.
I never reported this or told/talked to anyone about this - I assumed I had done something wrong ...
The one time I was forced to use a checkbox on the web, I didn't....
I simulated it by capturing an image of a check box in both states, and used js to hide/unhide it when clicked.
Nasty but reliable.
About SearchDomino :
I posted a Script tip about 2 days ago that was supposed to apply mail rules to the inbox (for use with mail coming from pop accounts). Well I coded a few lines but didn't really test it and I submitted the tip without it actually working ... and guess what : It was approved , untested and approved even if 30 mn after posting the tip I mailled them not to publish it (it lacked the search feature)... Well Searchdomino is not so great except for those amazing Ulrich Krauft (hmm wonder about the spelling) Lotusscript code snipplets... well that was just a thought :) Long life to Codestore :)