Posts Tagged ‘Operators’

Fix: jqGrid search operator menu items jumping around on hover

A colleague noticed earlier on today, that on the Chrome browser they were using, the search operator menu items of a jqGrid on a web app’s UI were jumping around on hover, making it practically impossible to select one.

image   image

Seems this had started occurring on that MVC web application, after a recent update to the latest jQuery-UI NuGet package.

Probably the issue wouldn’t occur if it wasn’t using the older free version of jqGrid. Will probably transition it eventually to free-jqGrid, the free fork (and quite evolved since forked) of the older free version of jqGrid, since jqGrid’s newer version is now commercial.

For the time being, I ended up adding this fix to Content/Site.css of the MVC webapp:

/* jqGrid search operator menu item hover (uses jQuey-UI) */

a.ui-corner-all.g-menu-item.ui-state-hover {
    border: 1px #cccccc !important; /* fix for Chrome: removed "solid" (was causing hovered items to resize and menu to relayout, making it too hard to select them */
    /*border: 1px solid #cccccc;*/ /* this is used by jQuery-UI for .ui-state-hover */

    color: blue; /* showing blue color for hovered over menu text, should show better than a hover border since selected item already has a border itself */

This also has the added extra that on hover it shows the hovered item’s text in blue:



Gotcha: use parentheses around ternary op conditional expressions

Just came across the following case in C# that puzzled me momentarily, especially since the strings involved were long enough and the expression was broken on multiple lines:

bool flag = true;
string test1 = flag? "xa" : "xb";
string test2 = "x" + (flag? "a" : "b");
string test3 = "x" + flag? "a" : "b";

The test3 case fails since the compiler tries to evaluate the "x" + flag expression at the left side of the operator ?, complaining that it cannot implicitly convert string to bool.

e.g I accidentally produced the following wrong code while I was trying to refactor some third-party code to make it more readable:

string test3 = “some long string here” +


                     “some other long string”


                     “some alternative long string”;

whereas the correct was:

string test3 = “some long string here” +

                     ( (someFlag)?

                     “some other long string”


                     “some alternative long string” );

The correct one needs the whole conditional expression enclosed in parentheses. In fact, the parentheses around (someFlag) can be skipped. In usually prefer them visually, even when I use just a boolean variable instead of a more complex boolean expression, but in case like this one the x + (someFlag)? a : b can be confusing to the reader of the code, not seeing x + (someFlag) will be treated as the conditional instead of someFlag.

Luckily the C# compiler is deterministic enough and not trying to imply meaning from one’s wrong syntax. Had it been some futuristic AI-based interpreter, well, it might have gotten confused there too.

To avoid this confusion in the first place, probably one could have designed a (bool)?x:y operator instead with parentheses being required around the boolean expression, but people coming from other languages (say C++) might then end up writing bool && (bool)?x:y and expect the condition to be bool && (bool) instead of just (bool), so even that syntax would be problematic.

Speaking of other languages, quoting from Wikipedia article on ternary operator:


Unlike in C, the precedence of the ?: operator in C++ is the same as that of the assignment operator (= or OP=), and it can return an lvalue. This means that expressions like q ? a : b = c and (q ? a : b) = c are both legal and are parsed differently, the former being equivalent to q ? a : (b = c).

So confusion even between languages that share a C-style syntax might not be avoided.

Suggestion: Introduce .= operator for C#

It would be nice if one could write in C# (and maybe in other .NET languages too):

s = s.SomeMethodOfS(…)…


s .= SomeMethodOfS(…)…

that is to have a .= operator, similar to += and other shorthand experession operators

see screenshot for an example usecase from the opensource project FoscamController


Ideally, usage of such operators should lead to compiling – whether is is via JIT (Just in Time) or AOT (Ahead of Time) compilation – into more optimized native code, but I’m not sure if C# compilers are exploting that optimization opportunity.

You can vote up this suggestion at:

Gotcha: no prefix increment/decrement operators, but get parsed

In C/C++ and C# one has useful prefix (++index) and postfix (index++) increment operators and corresponding decrement ones.

Although they have a single operant, they’re not working like functions as single + or – prefix would do, but instead they cause side-effects – they edit the variable passed to them. The prefix increment operator first increases a variable’s value, then returns it as result, while the postfix one first returns a variable’s value, then increases it.

Visual doesn’t have such operators (and they don’t seem to plan to add such from their response on related feedback at Microsoft Connect.

However, if you type-in

Dim x = ++y

the compiler won’t complain. In fact, it won’t complain even if you type

Dim x = +++++y

The reason is because it thinks this last crazy-looking expression is:

Dim x = +(+(+(+(+y))))

Similarly, it accepts expressions like

Dim x = –y


Dim x = —–y

So a programmer coming from C# or converting C# code to has to be extra careful when converting ++index expressions to use their own implementation as a function that takes a ByRef parameter

%d bloggers like this: