Rick Strahl's FoxPro and Web Connection Web Log

Javascript and jQuery Intellisense in Web Control Pages

Mon, 13 Oct 2008 07:54:00 GMT

Visual Studio provides some fairly decent Intellisense support in Visual Studio and if you’re using Web Connection’s Web Control Framework you can take advantage of Intellisense quite easily.

Anytime you have <script> reference in a page VS.NET will provide Intellisense for the referenced script so:

<head>

<title>Web Connection Ajax Chat</title>

<script src="../scripts/jquery.js " type="text/javascript"></script>

</head>

<body>

Provides Intellisense for the referenced library in source code. This works for any HTML style pages including Web Control Framework pages.

Sometimes you may prefer using script inclusion in actual Javascript only files rather than HTML pages. So if I have a library like my ww.jquery.js file and I want to get Intellisense for jQuery I can do:

/// <reference path="jquery.js" />

this.HttpClient = function(opt) {…}

at the very top of the .js file to force Intellisense to be available. The path specified is relative from the current file or you can use ~/scripts/jquery.intellisense.js for a more explicit path.

jQuery Intellisense

By default jQuery doesn’t work very well with Visual Studio Intellisense, so you may be surprised to hear that you can get pretty good jQuery Intellisense support, although it requires a few tweaks to your source file. Apparently Microsoft will be updating Intellisense support for jQuery drastically now that jQuery will be officially included with .NET and Visual Studio.

Until that happens though there are two approaches you can take to get jQuery Intellisense.

Markup jQuery.js with Intellisense specific comments

I’ve used this route before and if you’re using a recent version of Web Connection you already have a copy of the basic comment markup in the jQuery.js file distributed in the /scripts folder of a new application. The idea is that by adding Intellisense comment syntax to jQuery and only marking up the jQuery function you get first level Intellisense on any jQuery selector operations:

var jQuery = window.jQuery = window.$ = function( selector, context ) {

/// <summary>The jQuery object is actually just the init constructor 'enhanced'</summary>

/// <param name="selector" type="var">Document selector.

/// (examples: "Element","#Id",".cssClass","#divMessage,#divError",DomElement,jQueryObject)

/// </param>

/// <param name="context" type="object">Object scope of any code executed with jQuery functions</param>

/// <returns type="jQuery" />

return new jQuery.fn.init( selector, context );

};

This alone will let you type $(). and get a list of all jQuery functions available, which provides a good baseline. However, unless you mark up all the wrapped set functions Intellisense is only 1 level deep: The above only works for $(). but not for $().append(). – the second level doesn’t provide anything because append() is not marked up.

The version of jQuery.js that ships with Web Conection is marked up with this by default so as long as jQuery.js is referenced you should get basic Intellisense 'out of the box'.

Using an Intellisense.js specific Temporary Include

The above works well enough but it’s intrusive as it changes the original file and requires changing it with each update of jQuery. An alternative is to use a separate file that includes only the Intellisense and is a design time only file and hidden at runtime.

The first thing that’s needed for this is the script file which you can find here:

http://www.infobasis.com/sandpit/jQuery-Intellisense/

Copy this content into a file and name it jQuery.intellisense.js and store it in the same folder as jQuery – in ~/scripts for Web Connection.

Then you can do the following to include it in your page:

<html>

<head>

<title>Repeaters and Editing</title>

<ww:wwWebLiteral ID="WwWebLiteral1" runat="server" Visible="false">

<script src="../scripts/jquery.intellisense.js" type="text/javascript"></script>

<script src="../scripts/ww.jquery.js" type="text/javascript"></script>

</ww:wwWebLiteral>

</head>

<body>

Notice that there are two sets of script references in the page: The actual scripts that will be used on the page and the scripts used for Intellisense which are stored inside of the Literal controls which is set to be invisible. The idea is that VS sees the scripts but at runtime the code is not rendered.

What this means is that you get Intellisense at design time, and only the embedded scripts at runtime.

The above trick with the Literal control also works if you have Web Connection automatically embed scripts into the page. For example, if you use wwAjaxMethodCallback control by default Web Connection will automatically embed scripts into the page so there are effectively no script embeds in the page. But you can add the literal control along with any scripts that you want Intellisense for which is great.

In fact, Web Connection now adds this literal to the default page template, but note that the scripts are NOT automatically added to the page – only when controls are used that rely on them and then only if you don’t override or remote the script auto loading.

Getting Intellisense with jQuery is very useful. Although jQuery’s feature set is small enough to be easy rememberable, there are still a host of functions I often forget about and Intellisense makes them easier to use. Both of these approaches can be a big productivity enhancement.

The downside of the jQuery.Intellisense.js file is that it won’t let you see other plug-ins. So if you’re using Web Connection I still recommend the former approach for now of referencing the marked up jquery.js file so you can see all the jQuery plug-ins that the Web Connection client library provides (in ww.jquery.js).

Watch out for SYS(2335) in non-COM Applications

Sat, 4 Oct 2008 12:29:00 GMT

Just ran into a nice inconsistency in VFP 9.0. I’ve been adding some functionality into Web Connection to allow easy configuration for unattended COM mode. VFP 8 and later has SYS(2335,0) which basically forces a COM server to throw exceptions on any blocking user interface operation. So if you bring up a MessageBox for example, rather than hanging the COM server, you get an error thrown. This behavior works both in DLL and EXE servers and can be quite handy.

Typically SYS(2335) is only used in COM applications, but it's not all that unusual to have SYS(2335) in code that might have to cooperate with non COM code like an application startup routine or a business object factory.

Supposedly SYS(2335,0) does not have any effect on a standalone non-COM application. However, I’ve run into an edge case where it does seem to affect standalong applications. Oddly the problem doesn’t show up in the IDE runtime of VFP, but only if I run the application as an EXE.

My scenario is in Web Connection where I’ve just added an lUnattendedComMode flag to the server object. When running in File mode, Web Connection throws up a Visual FoxPro desktop form with a timer that checks for request files. The form is kept alive with READ EVENTS handler. This has been working forever.

Now, if I set my lUnattendedComMode flag Web Connection is thrown into unattended mode. In file based mode in the IDE everything still works fine and that’s how I’ve been testing. However, today I actually built an exe and ran it. The server started up and – uncerimoniuosly disappeared immediately when run from Explorer. If I now go into the VFP IDE and run that same EXE the server runs and stays up and running.

In short the EXE starts and immediately exits. Lots of head scratching ensued...

Baffled I started looking at settings and sure enough it turns out it’s the unattended mode flag. When NOT running in COM mode and running a standalone EXE READ EVENTS doesn’t hold up.

The fix for Web Connection is easy enough. Internally an additional check is added for making sure the server is actually in COM mode:

IF THIS.lUnattendedComMode AND this.lComObject

SYS(2335,0)

ENDIF

In your own applications you can check _VFP.StartMode:

IF INLIST(_Vfp.STARTMODE,2,3,5)

*** Global Reference to goWCServer

THIS.lComObject = .T.

ENDIF

By the way, be aware that the _VFP and Application objects are COM objects that REQUIRE that the VFP runtimes have been registered on a machine. If you just copy runtime files to a machine or server and don’t register _VFP or Application will fail which can cause some really tricky failures in code.

Anyway – the moral of the story is: When using SYS(2335,0) you should always make sure you explicitly check for the operational mode before setting this flag or else you may have some unexpected side effects even though the documentation states that this function has no effect on non-COM applications.

Header Manipulation in the Web Control Framework

Mon, 22 Sep 2008 02:06:00 GMT

A question that comes up frequently on the forums is how to access and set the header in a Web Connection Web Control page. For example, how can you set the title dynamically from code in a simple layout like this:

</head>

The problem is that in the WCF the header is not an object so you can’t you can’t directly access the title as a property in any way. One really easy way to add dynamic functionality to the header is to add an eval expression to the header:

</head>

To make this work you’ll need to add a property to the page first. Once you’ve added the property you can set in code and assign whatever value suits you:

*****************************************************************

DEFINE CLASS AjaxMethodCallback_Page as WWC_WEBPAGE OF WWC_WEBPAGE_FILE

*****************************************************************

*** Your Implementation Page Class - put your code here

*** This class acts as base class to the generated page below

*****************************************************************

#IF .F.

*** This line provides Intellisense: Ensure your path includes this page's location

LOCAL this as AjaxMethodCallback_Page_WCSX of ajaxmethodcallback_page.prg

#ENDIF

PageTitle = "Hello World"

*****************************************************************

* OnLoad

****************************************

FUNCTION OnLoad()

this.PageTitle = "Hello" + Process.User.Username + ". " + TIME()

ENDFUNC

* Onload

The property is created to have somewhere to store the value that can then be assigned. When the page is rendered the eval expression picks up the title and renders it.

You can use a similar approach for anything else you want to embed. If you want to embed script at the top or bottom you might create a placeholder string that holds that literal content.

Header Manipulation – adding content to the header

In the next release of Web Connection there will be a new wwWebHead control that maps the header object to a control. This provides a little more control over header output by giving you the ability to write out header content directly through code. You can write content at the top or bottom of the header using literal strings or controls.

For example, if you wanted inject a script tag into the page in the header you could use:

this.Page.Header.AddControlAtTop([<script src="scripts/jquery.js" type="text/javascript"></script>])

AddControlAtTop injects at the very top of the Header. AddControl() injects at the bottom – this allows a little bit of control over placement that often is necessary especially when injecting things like script tags or css styles that have to respect a certain order.

Script Manipulation from Code

The main reason this change was made now is precisely because of the additional control it affords for script placement. The next major update to Web Connection will integrate more tightly with jQuery and also use a custom utility library. This update will replace the existing Ajax controls and the wwScriptLibrary with a jQuery based equivalent version.

Since jQuery is often used in combination with other plug-ins and libraries placement of the jQuery library is crucial – specifically it should be loaded before any plug-ins or utilities, so that if any manually added plug-ins run after jQuery is loaded. The new header options allow for this precise placement necessary so that the auto-loaded (optional) jQuery script can co-exist properly with any plug-ins that might also be used in combination.

Please note that as before – it’s completely possible to turn off the auto loading of any script libraries on each of the controls that use them. The default auto loads, but you can clear out the the script location to for any resource or explicitly point it at your own locations instead of using the defaults. The goal isn’t to limit you and force you to use a packaged version, but to make using components as easy as possible without requiring any additional setup.

The header manipulation functionality can be quite useful when you need and especially in control development scenarios where you want to get everything neatly wrapped up into a single self-contained package that doesn’t require configuration of other page components.