Asked  7 Months ago    Answers:  5   Viewed   37 times

I noticed that PHP seems to return only values of checked checkboxes. I would like to see a list of checkboxes, not just values of checked checkboxes. Is there a way to detect variables of unchecked boxes?

I asked because I want to be able to update settings. For example, I have a few options that are already checked but if an user decides to uncheck an option, I need to know that unchecked value so I can update the option to be disabled.



I just ran into this problem myself. I solved it by adding a duplicate hidden field with the same name. When the browser sends this information, the second field overrides the first (so ensure that the hidden field comes first).

<input type="hidden" name="foo" value="">
<input type="checkbox" name="foo" value="bar">

If the checkbox is not checked you get:

$_REQUEST[ 'foo' ] == ""

If the checkbox is checked you get:

$_REQUEST[ 'foo' ] == "bar"
Wednesday, March 31, 2021
answered 7 Months ago

Change this:

<td><input type="checkbox" name="all_sizes" value="All">All<br></td>

to this (add the keyword 'checked'):

<td><input type="checkbox" name="all_sizes" value="All" checked>All<br></td>
Wednesday, March 31, 2021
answered 7 Months ago


<input type="checkbox" name="txtCheck" value="<?php echo $_POST['txtCheck'];?>"  /><br />


<input type="checkbox" name="txtCheck" value="your value" <?php if(isset($_POST['txtCheck'])) echo "checked='checked'"; ?>  /><br />

this will keep checkbox checked..

Wednesday, June 9, 2021
answered 5 Months ago

Try printf. e.g.:

> import Text.Printf
> printf "%dn" (23::Int)
> printf "%s %sn" "Hello" "World"
Hello World
> printf "%.2fn" pi
Thursday, August 5, 2021
answered 3 Months ago

This appears to be warning 67 and can thus be suppressed with:

#pragma warning disable 67

Don't forget to restore it as soon as possible (after the event declaration) with:

#pragma warning restore 67

However, I'd check again and make sure you're raising the event somewhere, not just subscribing to it. The fact that the compiler spits out 20 warnings and not 20 errors when you comment out the event is also suspicious...

There's also an interesting article about this warning and specifically how it applies to interfaces; there's a good suggestion on how to deal with "unused" events. The important parts are:

The right answer is to be explicit about what you expect from the event, which in this case, is nothing:

public event EventHandler Unimportant
    add { }
    remove { }

This will cleanly suppress the warning, as well as the extra compiler-generated implementation of a normal event. And as another added benefit, it prompts one to think about whether this do-nothing implementation is really the best implementation. For instance, if the event isn't so much unimportant as it is unsupported, such that clients that do rely on the functionality are likely to fail without it, it might be better to explicitly indicate the lack of support and fail fast by throwing an exception:

public event EventHandler Unsupported
    add { throw new NotSupportedException(); }
    remove { }

Of course, an interface that can be usefully implemented without some parts of its functionality is sometimes an indication that the interface is not optimally cohesive and should be split into separate interfaces.

Sunday, August 8, 2021
answered 3 Months ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :