|
There were about 30 pictures perhaps. If you only allowed a few tries before it locked up, it would be pretty secure, I suppose. (I'm not an expert) But nothing is 100% secure of course.
|
|
|
|
|
I thought this forum consisted of only experts!  (then I ask myself why would I be here then!)
|
|
|
|
|
If you display a lot of pictures at once, then the system becomes just as annoying to users as a captcha.
Also, you'd have to maintain a large and constantly-changing database of pictures to keep the bot from memorizing which pictures are the vehicles.
In any case, defeating the bots is a much bigger task than people realize. If bot writers are willing to create advanced algorithms capable of deciphering a captcha, then they are willing to go to great lengths to defeat other security features, too.
|
|
|
|
|
I've seen that with "Kittens" and "Puppies" as well - very damn annoying!
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
For something I'm working on, I want to test a given XmlElement with a provided XPath predicate to determine whether or not it's the droid node I'm looking for.
public static bool
IsMatch
(
this System.Xml.XmlElement Element
,
string Predicate
)
{
return ( Element.SelectSingleNode ( "self::node()[" + Predicate + "]" ) != null ) ;
}
I wasted an hour trying to get .[predicate] to work.
System.Xml.XmlDocument doc = new System.Xml.XmlDocument() ;
doc.LoadXml ( "<Foo Bar='Baz' />" ) ;
System.Console.WriteLine ( doc.DocumentElement.SelectSingleNode ( "." ).OuterXml ) ;
System.Console.WriteLine ( doc.DocumentElement.SelectSingleNode ( "self::node()[@Bar='Baz']" ).OuterXml ) ;
System.Console.WriteLine ( doc.DocumentElement.SelectSingleNode ( "self::*[@Bar='Baz']" ).OuterXml ) ;
System.Console.WriteLine ( doc.DocumentElement.SelectSingleNode ( ".[@Bar='Baz']" ).OuterXml ) ;
<Foo Bar="Baz" />
<Foo Bar="Baz" />
<Foo Bar="Baz" />
System.Xml.XPath.XPathException: '.[@Bar='Baz']' has an invalid token.
The book I have says . is equivalent to self::node(), but that's not true,
. returns a node, whereas self::node() returns a node-set, and you can only apply a predicate to a node-set. 
Of course, if you know of a way to test a node that uses neither SelectSingleNode nor SelectNodes, I'd be glad to see it.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
PIEBALDconsult wrote: Of course, if you know of a way to test a node that uses neither SelectSingleNode nor SelectNodes, I'd be glad to see it.
How about this?
public static bool IsMatch(this System.Xml.XmlElement element, string predicate)
{
return element.CreateNavigator().Matches("*[" + predicate + "]");
}
If you're going to be re-using the same predicate for a lot of elements, you might want to pre-compile it[^]:
public static bool IsMatch(this System.Xml.XmlElement element, XPathExpression compiledPredicate)
{
return element.CreateNavigator().Matches(compiledPredicate);
}
...
var compiledPredicate = XPathExpression.Compile("*[" + predicate + "]");
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Thanks, I'll try that too and maybe do some performance comparisons. Performance really isn't an issue with my current usage -- about forty elements being checked with a predicate provided on the command-line.
Your second implementation might make for the basis of an enumerator. 
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
Found an interesting feature in Microsoft Dynamics Ax 2012 R2:
static void Job40(Args _args)
{
smmBusRelTable bus;
int i;
select count(RecId) from bus where
bus.BusRelAccount == bus.TopLevelAccount
;
info(strFmt("From count: %1", bus.RecId));
i = 0;
while select bus where
bus.BusRelAccount == bus.TopLevelAccount
{
i++;
}
info(strFmt("bus.BusRelAccount == bus.TopLevelAccount: %1", i));
i = 0;
while select bus where
bus.TopLevelAccount == bus.BusRelAccount
{
i++;
}
info(strFmt("bus.TopLevelAccount == bus.BusRelAccount: %1", i));
}
Running the job results in this output:
From count: 31597
bus.BusRelAccount == bus.TopLevelAccount: 1
bus.TopLevelAccount == bus.BusRelAccount: 31597
"God doesn't play dice" - Albert Einstein
"God not only plays dice, He sometimes throws the dices where they cannot be seen" - Niels Bohr
|
|
|
|
|
A badly designed operator override? At least fun to see that (bus.BusRelAccount == bus.TopLevelAccount) != (bus.TopLevelAccount == bus.BusRelAccount)
|
|
|
|
|
I wish it was that easy. But X++ does not have overrides, the Dynamics Ax VM creates SQL statements from this code.
By tracing statements in the SQL Server I may be able to see the different statements created, but the bottom line is, that this should be a very very simple comparison, and having a failure here, gives me the creeps.
"God doesn't play dice" - Albert Einstein
"God not only plays dice, He sometimes throws the dices where they cannot be seen" - Niels Bohr
|
|
|
|
|
Ah, I see. Reminds me of an old "obfuscted" Access database, where
SELECT * FROM A, B where A.ID=B.A_ID
was different from
SELECT * FROM A JOIN B ON A.ID=B.A_ID
The trick was that in one case padding with spaces was relevant, in the other case not.
|
|
|
|
|
Ha!
I found the problem. DAX uses a caching mechanism to avoid too many roundtrips to the SQL Server.
If you're using the primary key in a query, then DAX will search an in-memory cache to retrieve a single record.
Apparently, DAX gets confused when I use the primary key field busRelAccount on the left hand side of the comparison. Using bus.disableCache(true) fixes this problem.
I hope they get rid of this bug soon, I really don't like to think of all the places I could have trusted this to just work.
"God doesn't play dice" - Albert Einstein
"God not only plays dice, He sometimes throws the dices where they cannot be seen" - Niels Bohr
|
|
|
|
|
Because there is no other way to compare OrderNumber to 0 
Private Function IsNew(ByVal OrderNumber As Long) As Boolean
Return IIf(OrderNumber = 0, True, False)
End Function
It's not horrible, but it's pretty representative for the code as a whole.
A lot of redundancy, a lot of global variables, no null values (but still NullReferenceExceptions...), Forms with 1000+ lines of code, etc.
VB is not the problem, it's the programmers that code it.
It's an OO world.
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
}
|
|
|
|
|
Where do you see the problem behind that code that justifies it to be posted in the Weird and Wonderful?
Well, that IsNew function should better be a function of the Order class and not need a parameter (because OrderNumber could be expected to be a Property).
But otherwise? Does VB.Net have the ternary operator like C# (return OrderNumber = 0 ? true : false;)? I don't know.
Or did you want to tell us that it's better to do the comparison of OrderNumber to 0 whenever that IsNew function is used? Oh no! That would deserve to be posted here! IsNew clearly tells you the intention of the code, while If(OrderNumber=0) does not.
|
|
|
|
|
It is a function on the Order class, but it still takes a parameter (it just gets mOrderNumber given to it every time).
VB does not have a ternary operator.
I'm saying the function could look like this:
Return OrderNumber = 0
There is no need for an IIF anywhere in the code. As I said, it's not truly horrible, but it's an 'interesting' way to return if OrderNumber = 0 
It's an OO world.
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
}
|
|
|
|
|
Ah, thanks. That explains it. It really deserves this place.
|
|
|
|
|
Don't worry, we all have our off-days 
It's an OO world.
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
}
|
|
|
|
|
I guess it was an unhandled ConfusedByVBException...
|
|
|
|
|
It's an OO world.
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
}
|
|
|
|
|
Sander Rossel wrote: VB does not have a ternary operator.
It does, it's the IIf function/method/whateva
|
|
|
|
|
Is that an operator or a function? 
I wouldn't know the difference, but I believe there is one. Something like an operator is a function, but a function is not an operator.
It's an OO world.
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
}
|
|
|
|
|
Not quite. IIf is a function[^], and as such it evaluates both arguments before checking the condition. So while this works in C#:
someObject == null ? "Null" : someObject.ToString()
the equivalent using IIf will throw a NullReferenceException:
IIf(someObject Is Nothing, "Null", someObject.ToString())
The real ternary operator for VB.NET is the If operator[^], which was added in .NET 3.5:
If(someObject Is Nothing, "Null", someObject.ToString())
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
I don't know VB and was just wondering ... if
Return OrderNumber = 0
does a comparison and returns the result then how would you set the value of OrderNumber to 0 and then return OrderNumber?
In C#, the first is
return OrderNumber == 0;
and the second is
return OrderNumber = 0;
|
|
|
|
|
PaulLinton wrote: I don't know VB
Obviously
VB doesn't know the == operator. Instead = can be either assignment or comparison, dependent on context.
In this case it's a comparison, but no assignment.
So
Return OrderNumber = 0 Would be
return OrderNumber == 0; in C#.
Your second C# example isn't possible in VB (as far as I know, but I didn't know it was possible in C# either )
It's an OO world.
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
}
|
|
|
|
|
The second one would be:
Return (Ordernumber = 0)
<edit>Or like this:
Return 0 = Ordernumber </edit>
modified 6-Jul-14 2:15am.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
