Miesiąc: styczeń 2010

Maintain selected tab position upon postback (jQuery UI Tabs)

Hello,

jQuery UI is a very nice add-on to the standard jQuery library. It provides us with out-of-the-box interactions and client side effects for a rich web application experience. One of the interesting effects are the jQuery tabs. They’re used to split the content into sections and be able to switch between them without having a postback, and also to spare some space within our web page.

The interaction is purely on the client side, so after reloading the page the tab which we selected as last isn’t maintained. What if we have, for example, a file upload control within one of our tab sections? After uploading a file (postback), we lose the focus on the tab in which we were previously.

But the developers of jQuery UI provide us with a couple of methods and events, which we can use to do some kind of workaround for this issue.

We need to have a document element which could store the selected tab index. We can use an input hidden field, value of which would be posted together with other data during page postback. So, let’s put it into our page, setting it’s value declaratively to 0 (the index of the first tab – default selection):

<input type="hidden" value="0" id="theHiddenTabIndex" />

Having the ID of the element, we can set its value from the client side script. Using the show event of the jQuery Tabs (fired when the tab is changed), we can do this at runtime:

$('#tabElmtId').tabs( {
  show: function() {
    var newIdx = $('#tabElmtId').tabs('option','selected');
    $('#theHiddenTabIndex').val(newIdx);
  }
 });

As you can see, when the event is triggered, the currently selected index of our tabs is being stored in a variable (line 3), then assigned as a value of the hidden input field. Now the postback can be performed but the next question is how to tell the tabs control to start from another tab index than the default 0.

First, on the server side, we can use the language which we prefer in order to fetch the value of the submitted hidden input field. For example, in ASP.net, it could look like this:

String hiddenFieldValue = Request.Form["theHiddenTabIndex"] ?? "0";

Now we can put javascript into our page’s source in order to tell have this variable also available for client side scripts:

   1: StringBuilder js = new StringBuilder();
   2: js.Append("<script type='text/javascript'>");
   3: js.Append("var previouslySelectedTab = ");
   4: js.Append(hiddenFieldValue);
   5: js.Append(";</script>");
   6: this.Header.Controls.Add(new LiteralControl(js.ToString()));

The one thing important about this is that it should be injected before the jQuery Tabs are initialised. Now the remaining task is to tell jQuery to use the javascript variable in order to set the selected tab upon loading the controls after postback. We can use the selected option of jQuery UI Tabs in order to assign this value:

   1: $('#tabElmtId').tabs( {
   2:     show: function() {
   3:         var newIdx = $('#tabElmtId').tabs('option','selected');
   4:         $('#theHiddenTabIndex').val(newIdx);
   5:     },
   6:     selected: previouslySelectedTab
   7: });

The only thing that changed from the previous Tabs initialisation is the line 6, where we assign the javascript variable to the selected option.
Now the tabs position should be postback-proof.

Happy jQuerying!

Use command prompt to control remote desktop connections on Windows Server

Hello,

while working on Sharepoint applications running on Windows Server machines, we often need to connect to the server via Remote Desktop (e.g. in order to perform debugging). Those who work this way often are probably familiar with the standard limitations of Windows Server systems: only two concurrent remote desktop connections at a time. If you’re working alone, this shouldn’t be a problem, however, in teams, it may sometimes happen that you’re denied logging in onto the system with the warning:

„The terminal server has exceeded the maximum number of allowed connections.”

This may happen not only when your work mates are busy doing their job, but sometimes also you are the one who is occupying one or two sessions, without actually being working on the server. Such situations occur, for example, if your local remote desktop connection window doesn’t get closed properly, or due to instable local operating system.

What then? We are not physically on the server and we cannot log on. If you are one of the “blocked” server’s administrators, the command prompt comes to rescue.

First of all, we can check who is logged on on the server. To do this, first we have to perform authentication in order for the server to allow us actually do this. The simple solution is to map a share on the server: either via accessing the share in Windows Explorer ( \servernameshare ) and entering your username and password, or, the same but using command line:

net use /user:MyUsername \servernameshare

After successful authentication, we can now check who is actually logged on with the query session command:

query session /server:MyServerName

The server name can be replaced by the IP address of the machine. The output of this command could look like this:

command_terminal

Seeing such list, we now know who is logged on, so we can contact the proper person. But what if we ourselves are the ones who occupy the sessions? Then we can disconnect the sessions remotely, too. Having noted the ID of the session which we received via previous method, we can use it in the reset session command:

reset session 1 /server:MyServerName

Now the session is free and we can log on to the machine again.

“Could not find default endpoint element that references contract”

Hello,

recently, while developing a web application which uses quite a lot of ASP.Net web services, I ran across a following problem.

The application uses also a few C# class libraries, and I wanted one of those libraries to retrieve some data from a web service (let’s call it service A). So, within the class library, I added web reference to the desired web service, downloaded all needed definitions and wrote a method in order to check whether the connection to the web service was working. I also checked whether the app.config file of the class library has been modified. Positive – the Service Model section has been added, the binding has been configured. So far, so good. I compiled the assembly, and wanted to use it in another web service (service B), which serves some specific information to the presentation layer of my web application.

However, the instantiation of the SOAP client method threw the following exception:

Could not find default endpoint element that references contract ‘Client.ClientSoap’ in the ServiceModel client configuration section. This might be because no configuration file was found for your application, or because no endpoint element matching this contract could be found in the client element.

The reason for the exception was quite simple: the web service B (which invoked the class library method that retrieved the data from service A), hasn’t been configured for usage of web service A. In other words, the Service Model section in the web.config file was missing.

Solution? Put the Service Model section generated in the app.config of the class library (as mentioned earlier) into the web.config file of the web service project.

Happy programming!