Leaderboard

This is a luxury school: one student, many teachers!

If you have one or two bits you may perform certain bitwise operations upon them. Not You may apply a not operation on one bit. This flips the bit so that zero becomes one and vice versa. For two bits your options increase to and, or, and xor. And To and two bits together is to say that if both bits are one and only one then the result will be one. Otherwise, if one or both bits are zero then the result will be zero. The truth table for and follows. | 0 1 ----------- 0 | 0 0 1 | 0 1 Or To or two bits is to say that if one or both bits are one then the result is one. | 0 1 ----------- 0 | 0 1 1 | 1 1 Xor To xor (exclusive or) two bits is to say that if one and only one bit is one then the result will be one, otherwise zero. | 0 1 ----------- 0 | 0 1 1 | 1 0

Why do you think it has to be a binary choice? I know several languages. I didn't have to abandon any to learn a newer one.

Thanks for the UDF! I found a problem while using the function _AccessRecordAdd. As far as I can tell it does not currently support adding blank/NULL data into a table field. I did some research, and according to MSDN (http://msdn.microsoft.com/en-us/library/ff845624.aspx) the DAO method Recordset.AddNew "sets the fields to default values, and if no default values are specified, it sets the fields to Null". By making the change below on line 1082 of the Access.au3 it should now support adding NULL by either explicitly setting the array element to "" or leaving it unset. It still errors correctly when the table field is set to "Required" in Access and you attempt to do this. ;From: $o_Rec.Fields($av_Fields[$nCnt][0]).Value = $av_Fields[$nCnt][1] ;To: If NOT ($av_Fields[$nCnt][1] == "") Then $o_Rec.Fields($av_Fields[$nCnt][0]).Value = $av_Fields[$nCnt][1] ;Note: I used If NOT ($av_Fields[$nCnt][1] == "") ;instead of If $av_Fields[$nCnt][1] <> "" ;because the later will detect 0 as "" and not allow you to add 0 to a field

For the OP if you need to ask what C++ is then you are a long way from the point of having to worry about writing a game. Hit the books, study hard and someday you too will be able to write "Hello World".

Take a look at my signature ?

The fact that you assume there are limits proves that the limit is you. /endthread

There are no limits. Apart from those described in the helpfile. But those are only limits until you work around them.

It may be a significant detail but it doesn't change anything. Spend 3 seconds thinking about the problem and a solution presents itself.

That's a pretty significant detail there. Do you see why I was saying what I was saying now?

ImNotVeryCleverOrICouldHaveThoughtUpThisOnMyOwn("This goes to stdout." & @CRLF) SetError(1) ; Force an error value. ImNotVeryCleverOrICouldHaveThoughtUpThisOnMyOwn("This goes to stderr." & @CRLF) Func ImNotVeryCleverOrICouldHaveThoughtUpThisOnMyOwn($sMsg, $iError = @error) If $iError Then ConsoleWriteError("STDERR: " & $sMsg) Else ConsoleWrite("STDOUT: " & $sMsg) EndIf EndFunc 30 seconds.

It's more logical not to do it.

Apart from it not making sense because of reasons mentioned a thousand times on these forums. How does it work?