Chrome Tip - Searching Every/All Source Files At Once

To search through every source file loaded by the currently viewed web page (e.g., the HTML, JavaScript and CSS) open Chrome Dev Tools. From the Sources tab right click topmost node in the tree then choose "Search in all files".

Given that it's accessed via an element in a tree one wonders if it can be used to search through all source files under a given node? A quick test confirms this!

The res:// Protocol And Phoning Home

Problem

An internal tool phones home.

Why does it phone home?

It’s a WPF app that defers most of the heavy lifting to a web app rendered through a Web Browser control.

Initial Approach

Easy enough – clone the website. But where to host it? The tool needs to run without network access.

Second step

Store the contents of the site in the executable itself. It’s a .NET WPF app and this seems like the sort of problem embedded resources were intended to solve.

Unfortunately the WPF web browser control, a light wrapper around IE’s ActiveX control, doesn’t know* how to read from managed resources. It *does* however, know how to read from native/win32/PE resources.

How do we store a native resource in a .NET executable?

.NET executables conform to the PE (Portable Executable) format that all windows executables use. Native resources (native is a retronym in this case, before .NET this was the only kind of resource) are defined as part of the PE spec.

It turns out that Visual Studio automatically creates a native/win32 resource for console projects. This resource stores the icon that the shell uses to represent the executable. And it allows you to specify this file, a compiled resource file (*.res), instead of having it automatically generated.

But how do we get a compiled resource file?

The resource related tooling in Visual Studio for .NET projects assumes use of .NET resources. These are a totally different kettle of fish than native/win32 resources. The MSDN article “About Resource Files” explains how to create compiled resource files (spoiler alert: there’s a resource compiler).

But HTML content assumes a directory structure

Native resources predate the WWW by several years. There’s no support for hierarchically arranged files. There are resource types (e.g., RT_BITMAP, RT_FONT, etc…) but other than resource type the structure is entirely flat. This necessitated some manual mapping/flattening of the HTML.

The cloned website included javascript, css and image content. Most of the image content was due to the ExtJS javascript library. Other than the image content there were very few links: each of these was manually converted to a res:// link.

CSS allows references to resources (e.g., background images) via its URL function. Modern CSS libraries make heavy use of the URL function. It turns out that there were several dozen files referenced this way. Fortunately URL accepts relative and absolute URLs. These were programmatically flattened, included in the compiled resource (.res) file and the referencing URL function updated with the res:// link.

All of the files, including images (*.png), javascript and style sheets, were included in the compiled resource file as type RT_HTML (#23) yielding internal URLs in the form res://MyExecutableName.exe/#23/MappedFileName.ext.

Custom AngularJS Validation With Inline Formatting

Getting a little further along the AngularJS learning curve. Angular has a built in validation framework (including support for async validators!) but to really take advantage of it angular directives need to be created.

The built in validation provides a very convenient way to conditionally display error messages. There's support for minlength, maxlength, regex patterns and several others new in the HTML5 standard.

Given the following snippet of HTML:

 1 <div ng-controller="ExampleController">
 2   <form name="form" class="css-form" novalidate>
 3     Name:
 4     <input type="text" ng-model="user.name" name="uName" required="" />
 5     <br />
 6     <div ng-show="form.$submitted || form.uName.$touched">
 7       <div ng-show="form.uName.$error.required">Tell us your name.</div>
 8     </div>
 9 
10     E-mail:
11     <input type="email" ng-model="user.email" name="uEmail" required="" />
12     <br />
13     <div ng-show="form.$submitted || form.uEmail.$touched">
14       <span ng-show="form.uEmail.$error.required">Tell us your email.</span>
15       <span ng-show="form.uEmail.$error.email">This is not a valid email.</span>
16     </div>

The error messages are conditionally shown based on the built in required and email validators.

I was looking for a way to use something similar, e.g., form.myField.$error.phoneNumber, as the ng-show/if conditional but with application specific validation.

To do this in angular, a directive has to be created. This plunkr demonstrates a custom phoneNumber validator (along with inline formatting, that is, the phone number is normalized upon successful validation). This directive can be applied to a textbox bound to a phone number as folows:

 1   <div>
 2     Phone Number1:
 3     <input 
 4       type="text" 
 5       ng-model="phoneNumber1" 
 6       ng-model-options="{ updateOn: 'blur' }"
 7       name="phoneNumber1"
 8       minlength="10" 
 9       maxlength="33"
10       phone-number /><br /> <!-- note: we set maxlength to 33 to allow e.g., 123-456-7890 extension 1234567890 -->
11     <span ng-show="form.phoneNumber1.$error.phoneNumber">The value is not a valid phone number!</span>
12     <span ng-show="form.phoneNumber1.$error.minlength || form.phoneNumber1.$error.maxlength">
13       There must be at least 10 digits in a phone number!</span>
14   </div>

In this snippet the error messages are condtioned on the custom validation supplied $error.phoneNumber. The textbox is decorated with the phone-number attribute which angular uses to apply the validator to this particular field.

Tables from the Web to the Desktop

Good design tends to spread from wherever it originates to wherever it can be gainfully applied.  HTML tables strike me as an example of this.  Way back in 1996, when the web we know today was but a wee lad, I remember the introduction of browser support for HTML tables.  They instantly became one of many excuses for me to "opt out" of going to class (I was marginally attending the Univ of Penn at the time).  Playing with cellpadding and cellspacing produced visually interesting results (and these turned out to be another instance of good design that were included in tables - control over internal and intra-cell margins) but it became obvious immediately that the big benefit was precise control over layout.

 

Eventually CSS would come to dominate the positioning game but you still find plenty of HTML tables out there on the web. 

 

Anyway, Windows Forms 2.0 introduced the TableLayoutPanel which behaves nearly identically to HTML tables.  Given that the overwhelming majority of display devices (and I include paper as a kind of display device) are 2 dimensional it makes sense that, over time, graphically oriented layout would coalesce around a few "good tricks".  IMHO the best "good tricks" are often rule-based (rule-based in the HTML table sense, not in the CSS 'create as many rules as you like' sense).  I'm a fan of CSS - it provided a much needed solutions to many design (and management) problems but that's a post for another day.

 

It is good to see good design migrating from one modality (the web) to another (the smart client/desktop/OS).