Search Results

Search found 3 results on 1 pages for 'patridge'.

Page 1/1 | 1 

• CompliationLock throws HttpException when registering areas for ASP.NET MVC unit tests

  - by patridge

  The moment I added a unit test to my ASP.NET MVC application to test some of the area routing, I got an HttpException coming out of the System.Web.Complication.CompilationLock type initializer with the following stack trace. System.Web.HttpException : The type initializer for 'System.Web.Compilation.CompilationLock' threw an exception. ----> System.TypeInitializationException : The type initializer for 'System.Web.Compilation.CompilationLock' threw an exception. ----> System.NullReferenceException : Object reference not set to an instance of an object. at System.Web.Compilation.BuildManager.ReportTopLevelCompilationException() at System.Web.Compilation.BuildManager.EnsureTopLevelFilesCompiled() at System.Web.Compilation.BuildManager.GetReferencedAssemblies() at System.Web.Mvc.BuildManagerWrapper.System.Web.Mvc.IBuildManager.GetReferencedAssemblies() at System.Web.Mvc.TypeCacheUtil.FilterTypesInAssemblies(IBuildManager buildManager, Predicate`1 predicate) at System.Web.Mvc.TypeCacheUtil.GetFilteredTypesFromAssemblies(String cacheName, Predicate`1 predicate, IBuildManager buildManager) at System.Web.Mvc.AreaRegistration.RegisterAllAreas(RouteCollection routes, IBuildManager buildManager, Object state) at System.Web.Mvc.AreaRegistration.RegisterAllAreas(Object state) at System.Web.Mvc.AreaRegistration.RegisterAllAreas() at StpWeb.MvcApplication.RegisterRoutes(RouteCollection routes) in Global.asax.cs: line 16 at StpWeb.Tests.RoutesTest.TestFixtureSetUp() in RoutesTest.cs: line 11 --TypeInitializationException at System.Web.Compilation.CompilationLock.GetLock(ref Boolean gotLock) at System.Web.Compilation.BuildManager.EnsureTopLevelFilesCompiled() --NullReferenceException at System.Web.Compilation.CompilationLock..cctor()

  Read the article

• Using label tags in a validation summary error list?

  - by patridge

  I was thinking about making use of <label> tags in my validation error summary on a failed form submit and I can't figure out if it is going to get me in trouble down the line. Can anyone think of a good reason to avoid this approach? Usability, functionality, design, or other issues are all helpful. I really like the idea of clicking a line item in the error list and being jumped to the offending input element, especially in a mobile HTML scenario where vertical orientation is more common and scrolling is a pain. So far the only problem I can find is that labels don't navigate for radio buttons or checkboxes without individual IDs (Clicking a label for a single ID-tagged radio/checkbox element alters its selection). It doesn't make it any worse than no label, though. Here is a stripped down HTML test sample of this idea (CSS omitted for simplicity). <div class="validation-errors"> <p>There was a problem saving your form.</p> <ul> <li><label for="select1">Select 1 is invalid.</label></li> <li><label for="text1">Text 1 is invalid.</label></li> <li><label for="textarea1">TextArea 1 is invalid.</label></li> <li><label for="radio1">Radio 1 is invalid.</label></li> <li><label for="checkbox1">Checkbox 1 is invalid.</label></li> </ul> </div> <form action="/somewhere"> <fieldset><legend>Some Form</legend> <ol> <li><label for="select1">select1</label> <select id="select1" name="select1"> <option value="value1">Value 1</option> <option value="value2">Value 2</option> <option selected="selected" value="value3">Value 3</option> </select></li> <li><label for="text1">text1</label> <input id="text1" name="text1" type="text" value="sometext" /></li> <li><label for="textarea1">textarea1</label> <textarea id="textarea1" name="textarea1" rows="5" cols="25">sometext</textarea></li> <li><ul> <li><label><input type="radio" name="radio1" value="value1" />Value 1</label></li> <li><label><input type="radio" name="radio1" value="value2" checked="checked" />Value 2</label></li> <li><label><input type="radio" name="radio1" value="value3" />Value 3</label></li> </ul></li> <li><ul> <li><label><input type="checkbox" name="checkbox1" value="value1" checked="checked" />Value 1</label></li> <li><label><input type="checkbox" name="checkbox1" value="value2" />Value 2</label></li> <li><label><input type="checkbox" name="checkbox1" value="value3" checked="checked" />Value 3</label></li> </ul></li> <li><input type="submit" value="Save &amp; Continue" /></li> </ol> </fieldset> </form> The only thing I have added to make the click-capable behavior more obvious is to add a CSS rule for the labels. .validation-errors label { text-decoration: underline; cursor: pointer; }

  Read the article

• Using jQuery with Windows 8 Metro JavaScript App causes security error

  - by patridge

  Since it sounded like jQuery was an option for Metro JavaScript apps, I was starting to look forward to Windows 8 dev. I installed Visual Studio 2012 Express RC and started a new project (both empty and grid templates have the same problem). I made a local copy of jQuery 1.7.2 and added it as a script reference. <!-- SomeTestApp references --> <link href="/css/default.css" rel="stylesheet" /> <script src="/js/jquery-1.7.2.js"></script> <script src="/js/default.js"></script> Unfortunately, as soon as I ran the resulting app it tosses out a console error: HTML1701: Unable to add dynamic content ' a' A script attempted to inject dynamic content, or elements previously modified dynamically, that might be unsafe. For example, using the innerHTML property to add script or malformed HTML will generate this exception. Use the toStaticHTML method to filter dynamic content, or explicitly create elements and attributes with a method such as createElement. For more information, see http://go.microsoft.com/fwlink/?LinkID=247104. I slapped a breakpoint in a non-minified version of jQuery and found the offending line: div.innerHTML = " <link/><table></table><a href='/a' style='top:1px;float:left;opacity:.55;'>a</a><input type='checkbox'/>"; Apparently, the security model for Metro apps forbids creating elements this way. This error doesn't cause any immediate issues for the user, but given its location, I am worried it will cause capability-discovery tests in jQuery to fail that shouldn't. I definitely want jQuery $.Deferred for making just about everything easier. I would prefer to be able to use the selector engine and event handling systems, but I would live without them if I had to. How does one get the latest jQuery to play nicely with Metro development?

  Read the article

1