|
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.
|
|
|
|
|
Been a while since I've made the computer hiccup, but last week had an interesting experience. A bug evidently caused everything to start paging to disk on Win7-64.
The short of it was in a window resizing routine the DC wasn't released correctly, so memory was being eaten quickly. Didn't realize it and continually resized for multi-seconds for fun. The computer started getting sluggish as heck. Opened up Resource Monitor and noted the memory increase upon resizing. But it was too late.
At bootup about 2 gigs is taken by all the background stuff I use. With the other progs, and the leak, my 4 Gigs main memory was exceeded. All well and good, but then the unexpected occurred: I watched the resource monitor show my memory opening up to the state where it only reported 560 MB or so being used! But none of the programs I had open closed at that point. They were VERY slow to respond, though!
A reboot fixed everything, and the bug was squashed in the next round. That's my tale. It fits the weird, but not the wonderful. For that you can have this piece of classic code I came upon in the project, which I just massively revised:
Rect() {
Rect(0, 0, 0, 0);
}
That initializer wasn't doing what the original author thought it was doing...
Or if you want another, this was the original author's assert macro:
#ifdef DEBUG
# define ASSERT (object) ((void)((object) || (AssertDebug(#object,__FILE__,__LINE__),1)))
#else
...
Used throughout the code like:
ASSERT(m_hWnd);
If it is expanded, Visual Studio throws a bunch of "103 IntelliSense: '#' not expected here" errors. I don't think they ever #defined DEBUG in their code, so the asserts were never even used. I guess they just liked typing... (Or maybe VS6 expanded macros differently?)
|
|
|
|
|
Thats how one of our developers with 18 years experience checks if guid is empty
public List<Comment> GetCommentIdsByUserQueryID_Paging(Guid userQueryID, out int total, int skipCount = 0, int itemsPerPage = 20)
{
.........
if (userQueryID.ToString().Length==0) return null;
..........
|
|
|
|
|
Ew. Yet, why check at all? And wouldn't an empty List be better than a null?
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
because no further actions cannot be done if something went wrong and queryid is empty guid. Empty list its bites in memory
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
