Duwamish Books, Phase 4: Fixes in Service Pack 1
by Mark McCulley October 1, 1999 Summary: Provides information about bugs fixed in Service Pack 1 for Phase 4 of the Duwamish Books sample application. (5 printed pages). Download and install the Service Pack. The primary reason we wanted to do a service pack upgrade for Duwamish Books, Phase 4 was to fix several bugs, some of which were related to running the sample on Microsoft® Windows® 2000. The following list summarizes the bugs fixed in Service Pack 1:
Bug: Unable to Create Cache Component with Windows 2000This was probably the most serious bug present in the initial Phase 4 release. The symptom was an error after clicking on the Categories button when the application was first started (after an operating system reboot or a restart of IIS). Here's how the error was reported when running Client 3 (for Internet Explorer 5): Line: 269 Char: 3 Error: Object required: XMLCatSchDoc.documentElement Code: 0 URL: http://localhost/D4_3 It initially looked like this error was somehow related to XML, but the information in the error message turned out to be misleading. Running Client 1 (for HTML 3.2 Browsers) produced an entirely different error message: Error Type: Application object, ASP 0197 (0x80004005) Disallowed object use Cannot add object with apartment model behavior to the application intrinsic object. /D4_1/global.asa, line5 What was happening was we were not being allowed to create the cache component under IIS 5.0, the Web server that ships with Windows 2000. The reason is IIS 5.0 strictly requires that objects created with application scope support the free-threaded marshaler. Although we had properly marked the ThreadingModel registry entry for the cache component as supporting both the single-threaded and multi-threaded models, we did not aggregate the free-threaded marshaler. The fix for this bug was to add a few lines of code to the class declaration in the Ccache.h source file to aggregate the free-threaded marshaler. The following code fragment shows the code added to the class declaration for the CCache class in Ccache.h (the new lines are in blue type). DECLARE_PROTECT_FINAL_CONSTRUCT() DECLARE_GET_CONTROLLING_UNKNOWN() BEGIN_COM_MAP(CCache) COM_INTERFACE_ENTRY(ICache) COM_INTERFACE_ENTRY(IDispatch) COM_INTERFACE_ENTRY(ISupportErrorInfo) COM_INTERFACE_ENTRY(IConnectionPointContainer) COM_INTERFACE_ENTRY_IMPL(IConnectionPointContainer) COM_INTERFACE_ENTRY_AGGREGATE(IID_IMarshal, m_pUnkMarshaler.p) END_COM_MAP() BEGIN_CONNECTION_POINT_MAP(CCache) CONNECTION_POINT_ENTRY(DIID__ICacheEvents) END_CONNECTION_POINT_MAP() // IID_IMarshal aggregation HRESULT FinalConstruct() { return CoCreateFreeThreadedMarshaler(GetControllingUnknown(), &m_pUnkMarshaler.p ); } void FinalRelease() { m_pUnkMarshaler.Release(); } CComPtr<IUnknown> m_pUnkMarshaler; For a complete discussion of threading issues with Active Server Pages (ASP) components, see the article "Agility in Server Components" in the MSDN Online Web Workshop. Bug: Disappearing Order Details with Windows 2000This was another bug that appeared only when Duwamish Books was run on Windows 2000. The symptom was that the order details failed to appear on the order summary page. We traced the source of this bug to some subtle differences in how record pointers operate in nested recordsets in MDAC 2.5, the version of Microsoft Data Access Components that ships with Windows 2000. The fix for the bug was simple: Swap the order of the two XMLOut calls in the GetSaleByTrackingID procedure in the Wflow.cls file, the class file for the Workflow Layer. Bug: Wrong Cursor Over "Add To Shopping Cart" ButtonThe symptom of this bug was that an I-beam cursor appeared when the mouse pointer was over the Add To Shopping Cart button. The cursor that should appear is the hand cursor. This bug only appeared when running Client 3, the client that operates directly on XML and XSL data. This bug was fixed by explicitly specifying the hand cursor in the style attribute for the SPAN element in the Det.xsl file for Client 3. The following fragment shows the new code in blue type: <span> <xsl:attribute name="Id">tbAddItem</xsl:attribute> <xsl:attribute name="OnClick">AddItem()</xsl:attribute> <xsl:attribute name="style"> color:white;text-decoration:none;cursor:hand; </xsl:attribute> Add to Shopping Cart </span> Bug: Incorrect Error Handling in VB ComponentsThis is a potentially nasty little bug that one of our engineers uncovered while using the Data Access Layer component in another unrelated development project. Take a look at the following error-handling code that was used in many of the transaction-based procedures in the Data Access Layer and Business Logic Layer components: ErrHandler: 'store incoming values lErrNo = Err.Number sErrDesc = Err.Description 'allow resume next after error Resume NextLine NextLine: 'signal failure to MTS and clean up GetObjectContext.SetAbort On Error Resume Next Set rsDetails = Nothing Set m_oDal = Nothing On Error GoTo 0 'raise error Err.Raise lErrNo, OBJNAME, sErrDesc Pay particular attention to the two lines in blue type. What happens in this code if the GetObjectContext.SetAbort call fails? You reenter the error handler and end up in an infinite loop! What the author of this code meant to do was put the On Error Resume Next line before the call to SetAbort. In Service Pack 1, we made this change in several class modules for the Data Access Layer and Business Logic Layer components. Bug: Incorrect Formatting On Some Currency ValuesA bug in formatting currency values caused the application to drop the two digits to the right of the decimal point when the digits are zeros in some currency values. This problem appeared on the order summary and order details sections on several pages of the application. A fix was applied to the GetSaleByTrackingID function in the Workflow Layer and to the ValidateShoppingCart function in the D4WFL1A.INC script include file. Bug: Use Response.Write to Send UTF-8 StringsTo allow Chinese, Korean, and Japanese text on the same page with English text, Duwamish Books sends Unicode-encoded text strings to clients. In the initial Phase 4 release, this was accomplished with the following ASP code fragment: Response.BinaryWrite(Chrw(&HFEFF) & text) This code prepends the text string with a Unicode byte-order mark and then uses Response.BinaryWrite to send the text to the browser. Although this approach worked well, there is another way to do this that is slightly more elegant and a bit more efficient. In Service Pack 1, the ASP code was changed to set the codepage to UTF-8 and use Response.Write to send text to browsers. With this approach, IIS does the encoding and it is not necessary to prepend the string with a byte-order mark. To support this change, a new script include file, D4UTIL.INC, was added to the COMMON subdirectory. D4UTIL.INC includes one subroutine, WriteUTF8: <% ' Routine to convert text to UTF-8 encoding and write to browser Sub WriteUTF8(ByRef Text) Session.CodePage = 65001 Response.Write(Text) End Sub %> The WriteUTF8 utility routine sets the codepage to 65001, the value for UTF-8 encoding, and calls Response.Write to encode the text and send it to the browser. An added benefit of using this approach versus using Response.BinaryWrite is that text encoded with UTF-8 is about half the size of text encoded with Unicode plain text. Note If you change the GetContext and PutContext functions in D4CTX1S.INC to use a mechanism other than Session objects to hold context, you should add a call to Session.Abandon to the WriteUTF8 subroutine. This will still allow the codepage to be set, but will release session resources when all of the script for a page has executed.
|
||
© 1999 Microsoft Corporation. All rights reserved. Terms of Use. |