Jan 12
Be careful of the JavaScript parseInt() function. It treats numbers that start with "0" as octal and "0x" as hexadecimal, which may not be what you want if the user entered a month of "09". Furthermore, parseInt() will not throw an exception if the parameter is bogus (as "09" is) — it will return NaN.
Therefore, consider using the optional radix option to parseInt() and always check for NaN with isNaN().
I have some thoughts about the use of exceptions vs. return values to indicate errors that I may get to in a future post.
Jan 12
Modal dialogs in Internet Explorer are a somewhat curious creature. Here are some of the problems that I have encountered and their workarounds:
| Problem |
Solution / Workaround |
|
Postback of a form within a modal dialog causes a new window to open
|
Use one of the following:
- Add a
<base target="_self"> fragment in the <head> element of your page
- Put all of the dialog’s content within an
iframe
|
|
Navigation to a new page within a modal dialog causes a new window to open
|
Put all of the dialog’s content within an iframe
|
|
The DISPID_NEWWINDOW2 event fired by the Internet Explorer COM component (often abstracted by the WebBrowser control) is not fired for modal dialogs, which means that applications that host Internet Explorer cannot capture the creation of modal dialogs to add their own window decorations or object model to window.external
|
No solution is known to actually capture the event.
As for accessing window.external within modal dialogs, it can be passed as an argument to the window.showModalDialog() method and access can be abstracted through a function such as this:
function getExternalOM()
{
// For IE windows, window.external will exist but will not have any
// methods. <starwars>This isn't the window.external we are looking
// for.</starwars>
if ("foo" in window.external) {
return window.external;
}
if (window.dialogArguments != null &&
window.dialogArguments.externalOM != null) {
return window.dialogArguments.externalOM;
}
return null;
}
|
Jan 12
The classes which are generated from an XML schema with xsd.exe do not implement every restriction of the original schema. No exceptions or warnings will be given if an XML document is serialized but the serialized document does not conform to the original schema.
This is especially common when using XML Schema restriction elements on simple types, as the generated C# classes will not enforce the same restrictions. For example, consider the schema fragment:
<xs:simpleType name="positiveLong">
<xs:restriction base="xs:long">
<xs:minExclusive value="0" />
</xs:restriction>
</xs:simpleType>
Any schema elements which use this type will result, when compiled using xsd.exe, in an object which uses the standard C# long type, which will happily accept negative numbers. Furthermore, the Serialize() method will quietly write out the negative number.
Therefore, it is recommended that any document generated using XmlSerializer should be revalidated against the original XML schema.
Jan 12
The .NET Framework 1.0 has a bug when serializing extremely small and extremely large decimals using XmlSerializer: the resulting values do not conform to the XML Schema decimal data type. Specifically, the serializer occasionally outputs the decimal in scientific notation. This also affects the decimal.ToString() method. This bug was fixed with the .NET Framework 1.1.
For example:
.NET Framework 1.0: Console.WriteLine(0.00000000000000000001M.ToString()) prints out 1E-20.
.NET Framework 1.1: Console.WriteLine(0.00000000000000000001M.ToString()) prints out 0.00000000000000000001.
To require the use of the 1.1 Framework, add the following stanza to your app.config:
<startup>
<supportedRuntime version="v1.1.4322" />
<requiredRuntime version="v1.1.4322" />
</startup>
This bug can be somewhat tricky to find, as the vast majority of the time decimals will be serialized correctly.
Recent Comments