This Readme file contains updated information for the
entire Microsoft Visual Studio suite of developer tools. If you downloaded a
Core service pack from the Internet, not all sections of this file apply to the
updates you received. The fixed issues appropriate for the Core downloads are
those listed in the Visual Studio section plus the sections for the products
updated by your Core download.
The Microsoft Visual Studio 6.0
Service Pack 3 Readme contains the following sections:
Overview and Installation
PART 2: Visual Studio
PART 4: Visual C++
PART 5: Visual
PART 6: Visual InterDev
PART 7: Visual J++
PART 8: Visual SourceSafe
PART 9: File Versions
latest product information, see the Visual Studio Web site at:
Some features of Visual J++ 6.0 relating to debugging Microsoft
Transaction Server (MTS) require Windows NT 4.0 Service Pack 4 (SP4). Windows
NT 4.0 SP4 is available from the Microsoft Windows Update Web page.
In response to the automation issues noted in Automation, the
Microsoft virtual machine (Microsoft VM) files have been updated, beginning
with Service Pack 2. The Microsoft VM version included in this service pack is
listed in the Visual J++ section of the file list in Part 9 of this readme.
This change will be applied both on the machine where Microsoft Visual J++ is
installed and also to the Visual J++ redistributable folder, so Visual J++
applications that are distributed will also include the updated Automation
To switch between retail and debug versions of the Microsoft
VM system classes, run classd.exe or classr.exe.
This service pack contains the required Visual J++ files needed to comply with the preliminary ruling issued by Federal District Court Judge Ronald H. Whyte. These changes were also included in Service Pack 2.
Compiler, Debugger, ActiveX, and IDE Fixes
In this service pack release, the following issues in the general
programming environment have been resolved:
The onCOMRegister method was not being invoked from a Java/COM-packaged DLL,
causing problems in registering DLLs.
A general protection fault occurred involving the Pdm.dll
file after running script that transformed XML data.
A particular sequence of spaces, line feeds, and carriage
returns caused the Visual J++ code editor and debugger to fall out of sync when
stepping through code.
Controls created using Visual J++ were marked as using the
default-threading model Both. This default setting creates several problems. First, user
interface controls are bound to the thread that owns the control's window
handle, which prevents the control from working properly in a multithreaded
apartment thread. In service pack 3, the default-threading model for ActiveX
controls has been changed to Apartment.
Exiting Internet Explorer 5 on a computer with the Visual J++ debugger installed may terminate abnormally. This problem is dependent on the type of content viewed in
Internet Explorer 5 and the speed of your machine. This has been corrected in
Visual Studio Service Pack 3.
IDE crashed when doing a Save As of a utility project. This has been fixed in this service pack.
If users opened the Break Point Properties dialog box several times while debugging in break mode, Visual
J++ had trouble handling these multiple instances.
JVC would not correctly compile against com.ms.fx.IFxLocaleFormatting.class or com.ms.fx.FxFormattedText.class.
Problem Debugging Scripted Behaviors. Internet Explorer 5 scripted behaviors (.htc) were not accessible
via the debugger and, therefore, were not able to be debugged. This has been
corrected in Visual Studio 6.0 Service Pack 3.
Run-time Errors handled by Visual Studio even if Script Debugger was present. Run-time errors would be handled by Visual Studio 6.0 even if the
Script Debugger were installed. Users were unable to choose the Script Debugger
as the application to use in this situation. Either Visual Studio or the Script
Debugger can now handle run-time errors.
Service Pack 3 contains a debugger update that enables the
user to set design-time breakpoints in .js and .vbs files.
The behavior of a form that included a single-threaded
ActiveX control varied, depending on the environment in which the application
was run. For example, if you created a single-threaded edit control, included
that control on a form, and compiled the form into an executable file, the edit
control would be unable to process keystrokes. However, if you did not compile
the form to an executable file and ran your application through JView, the edit
control behaved as expected. This service pack includes an update that enables
single-threaded ActiveX controls embedded in a WFC form to behave as expected,
regardless of the environment in which they are run.
When adding a DHTML Edit control for Internet Explorer 5, Visual J++ started to generate
the appropriate wrappers and compile them, but it would freeze. This has been
fixed in the Jactivex.exe included in this service pack.
When debugging Visual J++ 6.0 on Windows NT, the Machine
Debug Manager previously retrieved a process's file name by querying the
performance data registry. This approach to retrieving process information
caused crashes. Consequently, the Machine Debug Manager has been modified to
first attempt to use the Process Status API to retrieve process data. If this
attempt fails, the Machine Debug Manager queries the performance data
Microsoft Windows Foundation Classes Fixes
The following items have been fixed in the 188.8.131.5243 release of
the Windows Foundation Classes. This release is installed with the Microsoft VM
included with Service Pack 3.
ActiveXHost doesn't handle license with certain ActiveX controls. When hosting certain ActiveX controls, such as DB Grid 6.0, that
require a license on a computer other than the one where the form was
originally authored, a warning or error dialog box would appear stating the
license would expire in n days. This would happen even if the computer where
the application was deployed had a valid copy of the license. This is now
fixed, and the warning will not appear unless the control is
DhDocument.setTitle does not work from initForm. Calling DhDocument.setTitle(string title) had no effect on the document's title. Calling setTitle in onDocumentLoad would work around this problem. DhDocument.setTitle now works correctly from both initForm and onDocumentLoad.
When <BODY> tags are not capitalized, JDHTML controls can't be added to a bound template. When doing server-side code behind-HTML and the <BODY> tags
in the HTML template document were not in uppercase (<BODY>), the
code-behind module could not properly bind to the document, and DhElements
could not be added to the page. The search for <BODY> tags is now case
WinIOException when calling DhDocument.dumpDHTML and DhDocument.dumpHTML.DhDocument.dumpHTML and DhDocument.dumpDHTML are unsupported methods. They have been marked as @deprecated, and the compiler will issue a warning if they are
DhCell.resetTextAlign does not set the cells text alignment to that of its containing row.DhCell.resetTextAlign now resets the alignment of the text in the cell to match that of
the DhRow in which the cell is contained.
After removing a header row or footer row, DhTable.removeAll throws an exception. In the released WFC, an ArrayIndexOutOfBounds exception was thrown when removing a header or footer. This is no
longer the case.
DhStyleBase is missing setBackgroundImage. There was no way to directly set the background image style for
DhStyleBase-derived elements without programming through the Internet Explorer
Document Object Model. DhStyleBase now has a new method: setBackgroundImage(String imageURL) where imageURL is the path (fully qualified or relative) to the image.
Event-Handler Support for WFC.UI controls in Code-Behind HTML Scenario. In a code-behind HTML project in Visual J++ 6.0, users will find
when wfc.ui controls are added to an HTML page, they do not support event
handlers for the onEnter and onLeave events. However, the onMouseEnter and onMouseLeave events will still run properly. The onEnter and onLeave run only when a control is placed on a wfc.ui.Form.
Binding to a DhInlineFrame stops onDocumentLoad from being called. Binding a DhInlineFrame to an <IFRAME> tag in initForm with DhDocument.setBoundElements(DhElement elements) would throw an exception that was silently handled by the
framework. As a result, onDocumentLoad was never called for a document. This bug is now fixed. The
framework now correctly binds a DhInlineFrame to the <IFRAME> tag, and
onDocumentLoad is called as expected.
Binding to a DIV element that has text which is not enclosed in SPAN tags causes an exception. Binding to elements that were heavily nested sometimes caused an
element not found exception to be thrown. The workaround was to enclose raw
HTML text in <span> tags. This problem has been fixed, and the workaround
is no longer necessary.
Calling and Binding Methods on WFC Controls in a Code-Behind Scenario. Users can add com.ms.wfc.ui controls to an HTML page and have them participate in a
code-behind scenario. To achieve the proper behavior, users should either call
the DhBaseContainer.add( com.ms.wfc.ui.Control c) method or use DhComponentWrapper. Creating a DhComponentWrapper, setting its Control property (or
specifying the control in the constructor), and adding it to a container is
equivalent to calling the DhBaseContainer.add method. For more information, see DhComponentWrapper and DhBaseContainer.
Calling DhModule.doMain from a console application causes a NullPointerException. Server-side applications can be tested from a console application
by creating a DhModule object, setting the server-side code class, and then calling doMain. Previously, calling doMain in this manner would cause a null pointer exception; this now
Changing a tab selection cause NullPointerException. Selecting a tab in a TabControl that is hosted in an HTML page in
a code-behind scenario would cause a NullPointerException. This exception is no
Code-behind-HTML applications edited in the HTML Designer do not function in Internet Explorer 5. Code-behind-HTML applications edited in the HTML Designer do not
function with Internet Explorer 5 installed, because the <PARAM> tags of
<OBJECT> elements are incorrectly discarded. Code-behind-HTML
applications that are already deployed are not affected. This has been
corrected in Visual Studio Service Pack 3.
Code-behind-HTML samples from vj6sampl.exe may stop working when Internet Explorer 5 is installed. The Code-behind-HTML samples from vj6sampl.exe such as
"dhButton," "dhContainer," and "dhImage" may stop working when Microsoft
virtual machine version 5.0.3167 is installed. Microsoft VM version 5.0.3167
ships with Internet Explorer 5. This has been corrected in Visual Studio
Service Pack 3.
DhBulletedList.resetID throws DhElementNotFoundException. Calling resetID on a DhBulletedList will still throw DhElementNotFoundException, and the method is now marked as @deprecated. However, a warning will be generated at compile time. Moreover,
the method is not displayed in CodeSense or in the Object Browser to prevent a
developer from accidentally calling it.
DhCell.getText on cell in data-bound DhTable returns an empty string. This now works correctly.
DhDocument.findElement throws DhElementNotFoundException if called after DhDocument.getAllElements. Calling DhDocument.findElement(string elementID) would throw a DhElementNotFoundException if it was called to find an element after a call to DhDocument.getAllElements.DhDocument.findElement now works correctly even if DhDocument.getAllElements was called first.
DhEdit.addOnClick throws a com.ms.wfc.core.WFCException for multiline text boxes only. Adding an event handler to a multiline DhEdit in initForm would throw a WFCException claiming the element was not a
<INPUT type=text> or <TEXTAREA>. The workaround was to add the
event handlers to the multiline edit control in onDocumentLoad. Adding event handlers now works as expected in both initForm and onDocumentLoad.
DhElement resetID Method has been Deprecated. The DhElement class resetID method failed. In this service pack, the method works, but it has
DhModule is never finalized, causing an IIS memory leak. In this service-pack release, DhModule is now properly discarded
DhModule Methods to Retrieve an Object's PARAM Value. The DhModule class now supports the following methods that make it possible to
retrieve the value of an object's PARAM tags:
public String getParameter(String paramName)
public String getParameterNames()
The paramName parameter identifies the object parameter that you want to
retrieve. If no object parameter corresponds to the one that you request, this
method returns an empty string.
The second method, getParameterNames, retrieves the names of all available PARAM values and returns these names in an array of String objects.
These methods are supported for use only within Internet Explorer. A call to
these methods from within any other environment triggers a WFCInvalidStateException.
DhRadioButton and DhCheckBox won't surface Document Object Model attributes or styles set in HTML. Binding to an HTML radio button or check box that had custom
properties set on it would not keep those properties once the object was bound
in JDHTML. These unique properties would be lost once the object was bound.
This is now fixed, and custom properties for radio buttons and check boxes are
available from JDHTML.
DhRow.add now takes only DhCell. In the first release of WFC, DhRow.add would take any
DhElement-derived object. If the object was not a DhCell derivative, the method
would silently fail. In this release, a WFCInvalidParameterException is thrown if the DhElement is not derived from DhCell.
DhTable.showNextPage throws a null pointer exception when called after getBodyCell. This issue shows up only on Internet Explorer 5. Calling DhTable.showNextPage now works correctly even if getBodyCell has already been called.
DhText.setFont, DhText.getFont, and DhText.resetFont do not work correctly. If text represented in a DhText object was rendered in a struck-out or underlined font, calling setFont on that object with a non-underlined or non-struck-out font would
not remove the underline or strike-out attributes from the font. This now works
Getting an exception in WFC in server-side code will create problems in IIS, causing memory shortage. DataBound DhTables that were never added to a container would not
be properly finalized, causing IIS to consume but never free its memory.
Internet Explorer 5 returns "can't get WFC form surface exception" if loading a complex code-behind scenario across network. The default security settings in Internet Explorer 5 were
preventing WFC controls in a code-behind scenario from working correctly if the
HTML document was loaded from a local network drive or intranet site. This
scenario now works as expected.
Internet Explorer problem with Mshtml.dll would close the browser window after the timer started. The IOleClientSite for the timer control was being destroyed before the object was
deactivated. The object is now deactivated before its site is destroyed.
Performance improvement: Add DhBaseContainer.removeAllSafe. DhBaseContainer now has a method removeAllSafe that removes all child elements very quickly. It is currently used
on DhBulletedList and can also be used in a developer's derived container as
public void setElement(DhElement e)
m_item = e;
if (e != null)
Problems binding elements to DHDocument if no objects were bound first. There was a problem with binding and adding objects to a
DhDocument. If no objects were added to a DhDocument before a call to setHTMLDocument, then all subsequent additions, such as setBoundsElement, to
DhDocument would fail. This behavior has been corrected.
ReadyStateEvent has "???" as the value for the readyState. The ReadyStateEvent had the string "???" as the value for the readyState regardless of
what the ready state was. The ready state can now be one of the following
values: complete, interactive, loaded, or uninitialized.
Styles without a period (.) at the beginning of the name can't be added to elements. If a DhStyle was created using the DhStyle(string name) constructor, and the name parameter did not begin with a period, the style could not be
added to an element. This constructor now prepends a period to the style name
if one is not already there.
The getPropertyBag method has been added to DhModule. In the first release of WFC, it was impossible for a
DhDocument-derived class in a code-behind scenario to get at any <PARAM>
tags within its DhModule <OBJECT> tag. DhModule has two new methods:
public String getParameterNames returns an array of strings representing the NAME attributes
for each of the <PARAM> tags.
public String getParameter(string parameterName) Returns the VALUE attribute for the passed in
When binding to a table with an existing header or footer row, the header/footer row is not treated as part of the table. Calling DhDocument.setBoundElements(DhElement elements) to bind a DhTable to an existing <TABLE> in HTML would bind
to the table. However, if that table had a <THEAD> or <TFOOT>, they
were not treated as a part of the table. For example, myTable.removeAll would remove all the body rows, but the header and footer rows
would remain. The previous workaround was to get the <TABLE> with DhDocument.findElement(string id) in onDocumentLoad. Both of these scenarios now work as expected.
Creating more than two MDI children in the parent's constructor throws a WFCException. If a form created more than two multiple-document interface
children in its constructor, a WFC Win32Exception would be thrown. After this
exception, the form would have only two children added. This is now fixed. An
arbitrary number of MDI children can be created and added to a form in its
: MouseEnter and MouseLeave get confused on a PictureBox that has to re-create a handle. The MouseEnter and MouseLeave events would cause problems if, in
response to one of them, a PictureBox were to be re-created. For example,
calling the setBorderStyle method on a PictureBox will cause a handle re-creation. If this
method were called in a MouseEnter or MouseLeave event handler, the state of the MouseEnter/Leave would be left
unresolved, and future Enter/Leave events would not be recognized. This is
fixed in most cases, though it is possible to miss one or more enter/leave
events. The control, however, will resynchronize itself, and Enter/Leave events
are triggered as expected after some time.
The setSelectedIndex in Tab Control does not properly paint children. Calling the method setSelectedIndex on a TabControl would sometimes fail to render the child controls
on that page correctly. This issue has been resolved.
Method setChecked not working on Context Menu. Context menus for controls were not receiving their
WM_INITMENUPOPUP message. Therefore, any menu checks performed were not
applied. Calling the method setChecked on context menus now works as expected.
Button sizing is inconsistent between the Forms Designer and run-time. Child MDI windows that are created in the constructor of their
MDI frames would have autoscaling applied to them twice, once by the parent and
once by themselves. This could cause controls on the child window to be sized
differently at run time and at design time. MDI parents no longer autoscale
The com.ms.wfc.app.RegistryKey.setValue method doesn't work correctly for string arrays. When calling com.ms.wfc.app.RegistryKey.setValue(Object) with a string array that is its parameter, several
characters of the last string element in the array would not be written
correctly. Writing string arrays with this method now works
The com.ms.wfc.app.RegistryKey.setValue method does not account for terminating characters on Windows NT. When setting the value of a string with com.ms.wfc.app.RegistryKey.setValue on Windows NT, it was not adding to null-terminating characters
correctly. This has been corrected. A NullPointerException is thrown when removing a RebarBand without a child control. The following code threw a NullPointerException:
RebarBand Band = new RebarBand();
rebar1.removeBand(Band); // throws NullPointerException
This now works correctly, and the exception is not
Can't start up Rebar with multiple RebarBands on the same row. At design-time, it was possible to create a Rebar control with multiple RebarBands on the same row. At run-time,
however, each RebarBand would appear in its own row. The RebarBands now appear
in the row where they belong.
Databinding issues for dateTimePicker. The date field in the DateTimePicker control can now successfully be bound to a date data field in a
Form.createWindowGraphics throws a WFCInvalidArgumentExceptioN. This method now works as expected, and a usable com.ms.wfc.ui.Graphics class is returned.
Garbage appears on toolbar after installing IE5. When running Internet Explorer 5 in Windows 95 or Windows 98,
garbage characters would appear in the ToolBar ToolTip and under the ToolBar
button image. This has been corrected in this service pack.
ImageList sets defaults to 16 colors. The ImageList control now has a new property: colorDepth. The value of this property should be set to one of the constants
in the ColorDepth enumeration. However, when running on a system with more than
256 colors where the ImageList is to contain images that have 256 colors, the colorDepth property should be set to one of the following:
ListItem.setSelected(false) and setFocused(false) don't work. In code, you can now successfully clear and remove the focus from
ListItems in a ListView control.
Modifying drop-down Data Field menu on DataBinder's Properties page. Visual J++ 6.0 would stop responding when the user attempted to
modify the drop-down Data Field menu on the Properties page of a DataBinder
object. RasterOp.BRUSH and RasterOp.PEN do not work as expected with transparent images. Drawing a transparent image with a RasterOp of PEN or BRUSH would
draw the non-transparent areas of the image in white instead of the color of
the BRUSH or PEN. This is fixed for the RasterOp.BRUSH case. For RasterOp.PEN,
nothing is drawn.
Saving an Image object to a memory stream does not work as expected. Extracting an Image object from an ImageList and trying to persist it to a memory stream or file would fail if
the underlying PICTDESC was null. A valid bitmap PICTDESC is now returned, and the image can
successfully be persisted.
System problems on Windows NT 4.0 Service Pack 3. Under specific circumstances, a computer running Windows NT 4.0
Service Pack 3 freezes when running a WFC application that showed a window that
did not have a parent window. This problem has been fixed in Windows NT 4.0
Service Pack 4 and Visual Studio 6.0 Service Pack 3. The WFC now checks for the
parent window correctly.
When extending HTMLControl, onDocumentReady is never called. A user-written control that extended the com.ms.wfc.ui.HTMLControl never called the onDocumentReady method. This is now fixed, and the method is called as
Method Time.getDayOfWeek Value Returned Error. The "Remarks" section for the Time.getDayOfWeek method contains
incorrect information. It should state the number returned by the getDayOfWeek
method is always from 0 through 6 where a value of 0 represents Sunday.
Overloaded File.File Constructors Omitted from WFC Reference Documentation. The following overloaded versions of the constructor were omitted
in the File.File topic:
public File (String path, int mode)
public File (String path, int mode, int access)
In the first version, file access is set to
FileAccess.READWRITE, and file sharing is set to FileShare.NONE. In the second
version, file sharing is set to FileShare.READ if the access parameter is set
to FileAccess.READ; otherwise, file sharing is set to
Access 2000 databases must be connected via ODBC in Data Form Wizard
You might get a "Unrecognized database format" error when
connecting to an Access 2000 database using the Data Form Wizard. To connect to
an Access 2000 database, specify the database type as ODBC (rather than Access,
which will assume Access 98) on the "Database Type" page. On the Connect
Information page, you can then specify the Access 2000 database file (*.mdb) as
the database, and Microsoft Access Driver (*.mdb) as the driver. Alternatively,
you could set up a DSN using the ODBC Data Source wizard from the Windows
Control Panel and specify the DSN on the Connect Information page of the Data
Code-behind HTML support and Windows 2000 Beta 3
WFC controls from the com.ms.wfc.ui package that are added to a DhDocument (via the DhComponentWrapper() method) do not work on Windows 2000
Beta 3. This issue will be fixed in a future release of Windows 2000.