Asked  8 Months ago    Answers:  5   Viewed   25 times

I have an HTML form:

<form action='process.php' method='post'>
  <input type='checkbox' name='check_box_1' /> Check me!<br>
</form>

Here is a section from the PHP script process.php:

echo (isset($_POST['check_box_1']))?'Set':'Not set';

The output of the script when the checkbox is set is

Set

But when the checkbox is not set, the output is:

Not set

Why is this? This seems like a very poor design because my PHP script checks a number of $_POST variables to make sure they were passed along to the script. When the $_POST['check_box_1'] value is not set, then how do I know whether the script failed to pass along the value or the checkbox was just not set?

 Answers

41

If you want to overcome this design feature, try this:

<input type="hidden" name="check_box_1" value="0" />
<input type="checkbox" name="check_box_1" value="1" />

This way, you'll always have $_POST['check_box_1'] set in the callback page, and then you can just check its value to see whether they checked it or not. The two inputs have to be in that order though, since the later one will take precedence.

Wednesday, March 31, 2021
 
Arman
answered 8 Months ago
28

you can get all the selected check box values using following code this might be helpful for you

var myArray = [];
var id = "";
var oTable = $("#example").dataTable();
$(".class1:checked", oTable.fnGetNodes()).each(function() {
    if (id != "") {
        id = id + "," + $(this).val();
    } else {
        id = $(this).val();
    }
});
Wednesday, March 31, 2021
 
van_folmert
answered 8 Months ago
75

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
 
fhonics
answered 8 Months ago
26

I think the answer you are after is implied (if not stated) by Vinko's answer, though it is not spelled out simply. To distinguish whether VAR is set but empty or not set, you can use:

if [ -z "${VAR+xxx}" ]; then echo VAR is not set at all; fi
if [ -z "$VAR" ] && [ "${VAR+xxx}" = "xxx" ]; then echo VAR is set but empty; fi

You probably can combine the two tests on the second line into one with:

if [ -z "$VAR" -a "${VAR+xxx}" = "xxx" ]; then echo VAR is set but empty; fi

However, if you read the documentation for Autoconf, you'll find that they do not recommend combining terms with '-a' and do recommend using separate simple tests combined with &&. I've not encountered a system where there is a problem; that doesn't mean they didn't used to exist (but they are probably extremely rare these days, even if they weren't as rare in the distant past).

You can find the details of these, and other related shell parameter expansions, the test or [ command and conditional expressions in the Bash manual.


I was recently asked by email about this answer with the question:

You use two tests, and I understand the second one well, but not the first one. More precisely I don't understand the need for variable expansion

if [ -z "${VAR+xxx}" ]; then echo VAR is not set at all; fi

Wouldn't this accomplish the same?

if [ -z "${VAR}" ]; then echo VAR is not set at all; fi

Fair question - the answer is 'No, your simpler alternative does not do the same thing'.

Suppose I write this before your test:

VAR=

Your test will say "VAR is not set at all", but mine will say (by implication because it echoes nothing) "VAR is set but its value might be empty". Try this script:

(
unset VAR
if [ -z "${VAR+xxx}" ]; then echo JL:1 VAR is not set at all; fi
if [ -z "${VAR}" ];     then echo MP:1 VAR is not set at all; fi
VAR=
if [ -z "${VAR+xxx}" ]; then echo JL:2 VAR is not set at all; fi
if [ -z "${VAR}" ];     then echo MP:2 VAR is not set at all; fi
)

The output is:

JL:1 VAR is not set at all
MP:1 VAR is not set at all
MP:2 VAR is not set at all

In the second pair of tests, the variable is set, but it is set to the empty value. This is the distinction that the ${VAR=value} and ${VAR:=value} notations make. Ditto for ${VAR-value} and ${VAR:-value}, and ${VAR+value} and ${VAR:+value}, and so on.


As Gili points out in his answer, if you run bash with the set -o nounset option, then the basic answer above fails with unbound variable. It is easily remedied:

if [ -z "${VAR+xxx}" ]; then echo VAR is not set at all; fi
if [ -z "${VAR-}" ] && [ "${VAR+xxx}" = "xxx" ]; then echo VAR is set but empty; fi

Or you could cancel the set -o nounset option with set +u (set -u being equivalent to set -o nounset).

Sunday, June 27, 2021
 
seaders
answered 4 Months ago
36

You're right, the friend declaration is kind of like a forward declaration.

The following compiles:

class A;
class B
{
   friend A;
};

or

class B
{
   friend class A;
};

this does not:

class B
{
   friend A;
};

It's not actually the friend declaration that forward-declares class A, but the class keyword. That's why the second example doesn't work, because it doesn't know what A is. If you declare A beforehand, like in the first snippet, it can resolve A to a class declaration.

I stand corrected.

Friday, July 30, 2021
 
David
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 :
 
Share