© 1998 Microsoft Corporation. All rights reserved.
Other product and company names herein may be the trademarks of their respective owners.
Visual J++® Readme includes updated information for the documentation provided with Microsoftâ Visual Studioä -- Development System for Windows® and the Internet. The information in this document is more up-to-date than the information in the Help system.
MSDNä, the Microsoft Developer Network Readme.
Contents - Click any of the items below
Important This section contains vital information about installing Visual J++. Please read all items carefully before you begin your installation.
For general installation issues on the Visual Studio 6.0 suite of products, including side-by-side product installation, see the Installation Notes readme (install.htm).
Preview Versions of Visual J++ Must be Removed Before Installing Visual J++ 6.0
Minimum Disk Space Requirement to Install Visual J++ 6.0 Web Preview
Unsupported Tools Included with Visual J++ 6.0 Professional Edition
Compatibility Issues Between Visual J++ 6.0 and Pre-Releases of Microsoft Office
Interactions with Visual J++ 1.1
Visual J++ 1.1 Project Import Issues
Upgrading the Visual J++ 1.1 Compiler for Use With the New Microsoft Virtual Machine for Java
Windows NT 5.0 Beta 1 Installation Not Supported by Visual J++ 6.0
Windows 95 Registry Size: 64KB Limitation May Cause a Warning During Visual Studio Installation
Internet Explorer 4.01 Setup May Require Two Reboots on Computers That Have Windows NT Option Pack 4.0 Installed
Removal of Visual J++ 6.0 if Installed from Removable Media
Method DhDocument.onElementServerBound Missing from Documentation
Resource Localization Topic Incorrectly Shows Use of Two Suffixes for a File Name
Control.onEraseBackground Has Incorrect Parameter Type
CODECLASS Parameter Should Include Two Underscores
Debugging on Windows 98
Debugging MTS Components can be Unreliable Under Windows NT Server 4.0 Service Pack 3
Running Visual J++ 6.0 on Checked (Debug) Windows NT
Certain WFC Controls Added to a Web Page May Not Function
Benchmarking with Visual J++ 6.0
Unable to Add an ActiveX Control to a Form After Adding It to the Project With the Add COM Wrapper Dialog Box
ActiveX Controls Using Windowless Activation Not Supported
DataGrid Control is Read-Only with Server-Side Cursors
DataSource Control Now Defaults to Client-Side Cursors
Java Moniker Issues
WFC Control Property Settings May Be Lost When Placing Controls With Large Amounts Of Persistent Data Onto Web Pages
Templates May Not Display Correctly if Format Settings Are Changed
Java Files Created in Pre-Build Rules Are Not Built
Writing Add-ins for Visual J++
Specifying Output Directory as a Parent Directory of the Project Will Not Create DLL and EXE Output Types Correctly
Euro Currency Support
Potential Problem Getting Text or Changing Contents of a DhCell in a Data-Bound DhTable
Using The com.ms.wfc.html Package in a Console Application
Sample Code Sometimes Does Not Cut and Paste Properly
Solution Inspector Sample May Fail to Launch if Path is not Properly Set
MiscUI and WFCRocks Samples Will Not Run Properly From Samples Start Page
OutlookSample Fails to Start if Microsoft Outlook is Not Installed on the Target Machine
DxSoundMix Sample Application Requires a Windows Sound Card
ServerDataBinding Sample Instructions Contain Link to Wrong Test ASP File
ServerDataBinding Sample Requires a DSN to be Created for the Sample Northwind Database
ServerGenerator Sample Instructions Incorrectly Reference the ServerGenerator.htm File
The Server Data Binding, ServerHTTPHeaders, And ServerGenerator Samples Instruct You to "Build the .java Files To A Directory On The Classpath" Without Adequate Explanation
DHTML Sample Projects Use Deprecated Method of Binding WFC Classes to HTML Documents
CodeSense Statement Completion Keystrokes Conflict with Chinese Input Method Editor
HTML Editor May Cause Painting/Clipping Problems When Mixing SBCS and DBCS Character Sets
Method java.lang.Runtime.exec() Cannot Use DBCS Characters
Deploying and Debugging Updated Visual J++ Authored COM Servers that Run in IIS
External Dependency Download Limitations in Internet Explorer 4
FrontPage Servers Require a 7-bit URL for Deployment
Build May Fail on Computers with Anti-Virus Software
Deployed HTML Files Can Get Corrupted If Quotes Are Not Put Around Certain Values
Deploying Server Component Fails If the Specified Destination is a Floppy Drive
Default Registration of COM Classes in Java Packages
To fully uninstall past Visual J++ 6.0 Technology Previews, you must use the Windows Control Panel. Select Add/Remove Programs from the Control Panel, and double-click Microsoft Visual J++ 6.0. When prompted, select Remove All.
For a successful installation of Visual J++ 6.0, computer must have at least 160 MB of space available on the drive to which the TEMP or TMP environment variable is set, in addition to the 50 MB needed for the program (total of 190 MB). This space requirement is specific to the setup procedure used for the Web Preview version.
A number of useful tools are available to owners of Visual J++ 6.0 Professional Edition. For more information about these tools, locate the readme file available in the directory \common\tools\vj98\unsupprt on the Visual J++ 6.0 CD. Note that these tools are not supported by Microsoft Product Support Services.
Installing a pre-release version of Microsoft Office on the same computer Visual J++ 6.0 is installed may prevent both applications from running correctly. Any problems will be resolved in the final release of Microsoft Office.
There are no known problems with installing Visual J++ 6.0 on the same computer as Visual J++ version 1.1, provided you do not install them in the same directory. However, Visual J++ 6.0 does require the final version of Internet Explorer 4.01 or greater, which affects certain aspects of the Visual J++ 1.1 debugging environment. This known problem with Visual J++ 1.1 debugging and Internet Explorer 4.0 is described in the Microsoft Knowledge Base article "Q167998 Cannot Debug Visual J++ Programs On Internet Explorer 4.0 Pre-Release." To view this article, see http://www.microsoft.com/kb/ and type Q167998 in the Search phrase field. To prevent this debugging problem, install Visual Studio 97 Service Pack 3 from http://www.microsoft.com/vstudio/sp/.
Why is it necessary to "import" a Visual J++ 1.1 project?
Projects in Visual J++ 6.0 work differently than they do in earlier versions. The "import" process converts a Visual J++ 1.1 project into a Visual J++ 6.0 project.
While the new projects are improved in many ways over the Visual J++ 1.1 projects, there are certain Visual J++ 1.1 projects that will not import properly into Visual J++ 6.0. The import process is described below, along with some possible problems and how to work around them.
See the "Directory-Based Projects" help topic in MSDN for a more general description of the differences between projects in Visual J++ 1.1 and Visual J++ 6.0.
How do I import a Visual J++ 1.1 project?
There are two ways to import a Visual J++ 1.1 project, via the project file (.dsp) or the workspace file (.dsw).
Open the project .dsp file.
One .dsp file is created per Visual J++ 1.1 project. Its name is derived from the project name. The .dsp file contains all the project-specific information associated with the project. To import a Visual J++ 1.1 project via the .dsp file, follow these steps:
Open the project .dsw file.
A .dsw file is created when two or more projects exist in the same Visual J++ 1.1 workspace. It contains information that is not specific to a particular project in the workspace. Importing the .dsw file causes all projects enumerated in the workspace file to be imported into Visual J++ 6.0. Thus, importing a workspace that originally contained four projects in Visual J++ 1.1 will result in a solution containing the same four projects in Visual J++ 6.0.
Note that some project types in a workspace cannot be imported into Visual J++ 6.0. In Visual Studio 97, a workspace can contain Visual J++ 1.1 and Visual C++ 5.0 projects at the same time. Importing mixed workspace into Visual J++ 6.0 will result in only the Java projects being imported. Visual C++ 5.0 projects are not imported and are removed from the imported solution file.
To import two or more Visual J++ 1.1 projects via the .dsw file
What happens when a project is imported?
Assume that you have a directory called "MyProj" that contains a project file "Proj.DSP".
MyProj Proj.DSP foo1.java foo2.java à
When you import this project in Visual J++ 6.0, a new project file will be created. The default name for the new project is the name of the directory with a VJP extension, for example "MyProj.VJP."
MyProj Proj.DSP foo1.java foo2.java MyProj.VJP MyProj.SLN à
The information from your DSP file will be imported and stored in the VJP file. Some other files that are associated with this project will be created ù a Visual Studio solution file (myproj.SLN) and others. In most cases, you can now use Visual J++ 6.0 to edit, compile, and debug your Java project without any further modifications.
Once I've imported, what happens to the old Visual J++ 1.1 project?
After import, Visual J++ 6.0 leaves the original, unmodified Visual J++ 1.1 project file (DSP) in place. We recommend that you do not continue to use the DSP file, however. Any further changes to the DSP file will not be reflected in the Visual J++ 6.0 (VJP) project. You can re-import the project, but the existing Visual J++ 6.0 project file will be overwritten and any changes you made will be lost.
Why can't I import a Visual J++ 1.1 project that is under source code control?
You can, but you must import it via the file system rather than through the Visual Source Safe browser. Navigate to your enlistment directory and double-click the .dsp or .dsw file. The appropriate project conversions are made.
What features of my Visual J++ 1.1 project won't be imported?
There are some features available in Visual J++ 1.1 projects that won't import properly into Visual J++ 6.0. Here is a list of those features, with suggested workarounds:
For files other than Java source files, Visual J++ 1.1 allowed you to specify a per-file custom build rule. In Visual J++ 6.0, you will need to use the pre- and post-build commands instead. These are available in the Custom tab of the project Properties dialog box.
All of the files in a Visual J++ 6.0 project must be in a single directory, or in sub-directories that are contained by a single directory. For instance, if you have the following directory structure:
MyProj foo1.java MySubProj Proj.DSP foo2.java
In Visual J++ 1.1, it was possible for both foo1.java and foo2.java to be part of the project contained in Proj.DSP. When Visual J++ 6.0 imports Proj.DSP, however, it will only import those files that are in the MySubProj directory or in directories that are contained by MySubProj. You can either move other project files underneath the MySubProj directory, or you can create a new Visual J++ 6.0 project in a directory that contains all of your project files (in this case, that would be the MyProj directory).
Visual J++ 1.1 supports custom build configurations in addition to the standard debug and release configurations. Visual J++ 6.0 only supports debug and release build configurations, and will only import those configurations from the old project.
Visual J++ 1.1 build order dependency maps are not imported into Visual J++ 6 projects. You must recreate them using the Build Order dialog box for the solution. Select the top node in the Project Explorer and press Shift-F4 to view the Build Order dialog box for the solution node.
Installing Visual J++ 6.0 will update the Microsoft Virtual Machine for Java, which stores the classes in the Package Manager. In order to compile from Visual J++ 1.1, you will need to copy three files (jvc.exe, msjvc.dll, and jps.dll) from the Visual J++ 6.0 compiler directory (an installation in the default directory would put the files in c:\program files\microsoft visual studio\vj98) into the Visual J++ 1.1 compiler directory (an installation in the default directory would put the files in c:\program files\devstudio\sharedide\bin). You will also need to recreate the CLASSES.ZIP file that Visual J++ 1.1 uses by running the command line tool "clspack -auto". This will extract all of the class files from the package manager and recreate the CLASSES.ZIP file that Visual J++ 1.1 recognizes.
Microsoft Windows NT 5.0 Beta 1 installations are not supported by Visual J++ 6.0. Setup will fail if attempted on a Windows NT 5.0 system with Beta 1 installed. You must have either Windows 95, Windows 98, or Windows NT 4.0 with Service Pack 3 installed to run this product.
A 64-KB limitation in the size of the SharedDLL key in the Windows 95 system registry may cause a warning to appear when you install Visual Studio 6.0. To work around this problem, before continuing with setup, you should shorten the install path where you plan to install Visual Studio 6.0, thus reducing the amount of registry space required.
Additionally, you can uninstall programs you no longer use by accessing Add/Remove Programs from the Control Panel. The registry keys used exclusively by those programs will then be deleted.
To save further on registry space used by programs you intend to keep, uninstall, then reinstall these programs to shorter installation paths.
Consider using the RegClean utility, designed to clean up unnecessary entries in your registry. For more information and a download link, go to http://support.microsoft.com/support/kb/articles/q147/7/69.asp
Note On Windows NT Workstations and Servers, Visual Studio setup will automatically resize the registry.
If you have previously installed the Windows NT Option Pack 4.0 and are prompted by the Installation Wizard to upgrade Internet Explorer, you may see the following message after Internet Explorer reboots the system the first time:
"Some services could not be started. Setup needs to reboot your system in order to start the services."
If you experience this problem, you should NOT continue with the Installation Wizard. Accept the Internet Explorer 4.0 dialog box and reboot. Upon the subsequent reboot, launch the Visual Studio setup again. Setup will continue where it left off.
If you installed Visual J++ 6.0 from a removable media drive, such as an Iomega Jaz drive, and you do not have the disk from which it was installed, you should use the following steps to remove the product:
The Setup Message dialog box appears again.
Clicking No will allow you to cancel the removal.
Some features of Visual J++ 6.0 relating to Microsoft Transaction Server (MTS) require Windows NT 4.0 Service Pack 4 (SP4). The service pack was in final beta testing at this writing, and is scheduled to be available by the time Visual J++ 6.0 products are available. Information on the availability of SP4 will be published on the Windows Downloads page at http://www.microsoft.com/windows/downloads/default.asp
For information on Visual J++ 6.0 features affected by SP4, see Debugging MTS Components can be Unreliable Under Windows NT Server 4.0 Service Pack 3, and the Client-Server section of the Visual J++ 6.0 samples.
The reference documentation for com.ms.wfc.html.DhDocument is missing the following method for server-side access of bound elements:
DhDocument.onElementServerBoundCalled after a bound element on the server has been processed and just before it is written to the client.
Syntax
In the Visual J++ Programmer's Guide topic WFC Programming Concepts, under Localizing Your Application, several references are made to using two suffixes when renaming your .resources file. (For example, Form1_jpn_jpn.resources is mentioned.) This is incorrect. Only one language suffix is required (i.e. Form1_jpn.resources); use of two suffixes in a .resources file name will not work properly.
The reference documentation for com.ms.wfc.ui.Control.onEraseBackground incorrectly states that the parameter is an EraseBackgroundEvent object. The correct parameter is a PaintEvent object.
In the topic Quick Start in Programming Dynamic HTML in Java, all references to the name CODECLASS should be replaced with __CODECLASS. (Note the use of two underscore characters.)
If you are running Visual J++ 6.0 on Windows 98, you must do the following before other computers can run debug processes on your computer.
Debugging MTS applications can be unreliable when running Windows NT Server 4.0 Service Pack 3. These problems are resolved in Windows NT Server 4.0 Service Pack 4. See Visual J++ 6.0 and Windows NT 4.0 Service Pack 4 for information on downloading Windows NT 4.0 Service Pack 4.
If you are running checked builds of Windows NT, you may see an access violation when shutting down Visual J++ 6.0. This exception is benign and will not cause data loss. You may safely ignore it. The situation will be addressed in a future release of Visual J++.
Some WFC controls can be dragged into the HTML Designer from the WFC Controls tab of the Toolbox, but do not apply to HTML pages, and thus will not function properly. The following controls, while enabled in the Toolbox, should not be used on HTML pages.
In order to provide maximum power in developing and debugging applications, the Microsoft Virtual Machine (VM) for Java implements the ability to attach to running Java processes for debugging purposes. This option exacts a small but measurable performance price. The option is turned off by default when the VM is installed, so end-users running applications will see no impact.
Since Visual J++ 6.0 is a development tool, the option is turned on when Visual J++ is installed. Therefore, if you are attempting to run benchmarks on a machine with Visual J++ installed, you should turn off the option before running applications that measure performance. In the Visual J++ environment, select the Options from the Tools menu. Then, select Debugger node in the list, and note the Java options near the bottom of the panel on the right. Uncheck the "Attach to programs running on this machine" check box.
You may sometimes see the following message after attempting to add an ActiveX control to a form.
"Unable to find the class. Ensure that it is on the classpath and, if it is part of a project, that the project has been compiled."
This situation may occur after first creating a wrapper for the control using the Add COM Wrapper dialog box, and then placing it on the Toolbox via the Customize Toolbox dialog box. To work around this, either compile the project before adding the control to your form, or, add the ActiveX control by going directly to the Customize Toolbox dialog box.
Note that if a control has already been added via the Add COM Wrapper dialog box, you may remove it using the same dialog box.
ActiveX Controls using windowless activation are not supported in Visual J++ 6.0.
If the cursorLocation property of the DataGrid control's data source is set to CLIENT, the DataGrid control will support read/write operations. If the cursorLocation property is set to either SERVER or NONE, the DataGrid control will function in a read-only manner.
In earlier preview versions of Visual J++ 6.0, the DataSource control defaulted to utilizing server-side cursors. The release version of Visual J++ 6.0 now defaults to client-side cursors. To use server-side cursors, set the cursorLocation property of the Datasource control.
Visual J++ 6.0 includes support for including Java classes as ActiveX controls onto Web pages using the Java Moniker tag. The advantage of the Java Moniker tag is that Java classes can be used as ActiveX controls on a Web page without having to be registered on the client machine.
To create a WFC control on a Web page
<OBJECT classid="java:com.ms.wfc.ui.Button" id=Button1 style="LEFT: 0px; TOP: 0px" VIEWASTEXT> <PARAM NAME="data" VALUE="...."> </OBJECT>
- or -
<OBJECT ID="OBJECT1" WIDTH=292 HEIGHT=98 style="HEIGHT: 98px; WIDTH: 292px" CLASSID="java:MyPackage.MyControl"> <PARAM NAME="cabbase" VALUE="MyPackage.CAB"> </OBJECT>
The following limitations apply to the use of the Java Moniker.
<HTML> <HEAD> <META NAME="GENERATOR" Content="Microsoft Visual Studio 6.0"> <TITLE></TITLE> <SCRIPT LANGUAGE=javascript FOR=Button1 EVENT=Click> <!-- button1_onclick() //--> </SCRIPT> <SCRIPT ID=clientEventHandlersJS LANGUAGE=javascript> <!-- function button1_onclick() { alert("Hi from WFC"); } //--> </SCRIPT> </HEAD> <BODY> <P> <OBJECT classid="java:com.ms.wfc.ui.Button" id=Button1 style="LEFT: 0px; TOP: 0px" VIEWASTEXT> <PARAM NAME="data" VALUE="UEsBAAAEZm9udAsAEmNvbS5tcy53ZmMudWkuRm9udCsAAACfSgAAAgAAAAAFQXJpYWz/////AABQQQIAAAC8AgAAAAAAAAAAAAAAAAAAAARzaXplCwATY29tLm1zLndmYy51aS5Qb2ludAgAAABLAAAAFwAAAAAIdGFiSW5kZXgFAAAAAAAEdGV4dAkAAk9LAAA="></OBJECT> </P> </BODY> </HTML>
<OBJECT ID="OBJECT1" WIDTH=292 HEIGHT=98 style="HEIGHT: 98px; WIDTH: 292px" CLASSID="java:MyPackage.MyControl"> <PARAM NAME="cabbase" VALUE="MyPackage.CAB"> </OBJECT>Note An alternative is to place the control classes on the classpath.
When the com.ms.wfc.ui.HTMLControl control is added to a Web page, a WFC exception is thrown as the control is loaded. This occurs both at design time and run time. The alternative is to use the ActiveX control equivalent of this WFC control on the Web page.
WFC controls containing over 3 kilobytes of persistent data may encounter data loss when the control is placed onto an HTML page. For example, this problem typically manifests itself when a property of type com.ms.wfc.io.Image is exposed to developers. Symptoms include the loss of property data inside the Visual J++ IDE, and HTML pages not displaying properly inside Internet Explorer.
Microsoft is currently researching this problem and will post more information to the Microsoft Product Support Knowledge Base as it becomes available.
By default, all templates are formatted with tabs rather than spaces . If you want to change the format settings to use spaces instead of tabs, the templates will still have tabs in them. The workaround for this is to load the actual template .java file and then save it using spaces instead of tabs.
If the project directory is a sub directory of the output directory specified on the Compile tab of the Project's Properties dialog box, certain resources will not be found when attempting to run a DLL and EXE output type. For example, if the project directory is set to "c:\my projects\com\company\sales" and the output directory is set to "c:\my projects" and the project is set to create a DLL or EXE, certain resources may not be correctly packaged into the DLL and EXE output. When this project is run, you will get a 'com.ms.wfc.core.WFCException was not handled' dialog. If you click Yes to debug, you will see that it's failing on a call to 'com.ms.wfc.core.ResourceManager.getObject'. To fix this, set the output directory to be a sub directory of your project directory, such as "c:\my project\com\company\sales\debug" or under a different tree altogether, such as "c:\my projects\debug".
Java files that are created in pre-build rules will not be built the first time the project is built. An example of this would be a project with a pre-build rule that uses jactivex to create Java wrappers. The first time the build is run, the new Java wrappers will appear in the project, but will not be built. Building a second time will build the new files.
Workarounds for this are:
Visit the Microsoft Visual J++ Web site to download the Add-in Wizard. This is a single DLL that fully installs itself when you invoke regsvr32 on the DLL. The next time you start Visual J++, in the Visual Studio folder of the New Project dialog box, there will be a Visual J++ Add-in project that you can select. Creating one of these projects launches the wizard. The wizard creates a basic add-in that you can run immediately after you finish using the wizard. The wizard lets you supply a display name for the add-in (which appears in the Add-in Manager dialog box) and a description for the add-in. You can optionally choose to have the wizard generate the code to add a command to the Tools menu for invoking the add-in once it is loaded into Visual J++. After using the wizard to create a basic add-in, you can add project items for WFC UI to create add-ins that seamlessly integrate with Visual J++. If you do not install Visual J++ in the default location, then you will need to modify the project settings for the add-in project to correct the pathname for the alternate launch program (devenv.exe).
The Euro currency, the proposed single currency of the European Union, becomes effective January 1, 1999 with a gradual introduction. Widespread appearance of notes and coins in the unit is planned for 2002. Applications written with Visual J++ will support the Euro based on features in the underlying operating system. Windows 98 and Windows NT 5.0, as well as Windows NT 4.0 with Service Pack 4, all correctly support the Euro symbology. Other platform configurations require patches, available at no charge from Microsoft. Information on platform support for the Euro, and associated patches, is available at http://www.microsoft.com/typography/faq/faq12.htm.
There is a known problem with the getText() function on DhCell when the cell is part of a data-bound DhTable. In some circumstances, the getText() function returns an empty string. The following code can be used to get the correct text:
private String getCellText(DhCell cell) { cell.getElementCount(); DhElement[] elems = cell.getElements(); String text = cell.getText(); cell.removeAll(); ((com.ms.wfc.html.om.IHTMLElement)cell.getPeer()).setInnerHTML(""); for( int i = 0; i < elems.length; i++ ){ cell.add( elems[i] ); } cell.setText( text ); return text; }
The code above may also be modified for other manipulations of cell content, such as adding elements or changing existing text. This problem will be addressed in a future release.
The com.ms.wfc.html package can be used in a console application to generate static HTML pages. When using this package in a console application, the initForm method in your DhDocument-derived class must be placed in the onDocumentLoad method. The following is an example:
// please save the following code as MyDhDocument.java import com.ms.wfc.html.*; import com.ms.wfc.core.*; public class MyDhDocument extends DhDocument { /** * overriden from DhDocument */ public void onDocumentLoad(Object o, Event e) { this.initForm(); } private void initForm() { DhText text = new DhText("Hello World"); this.setNewElements(new DhElement[] {text}); } } // please save the following code as MyConsoleApp.java import com.ms.wfc.html.*; public class MyConsoleApp { public static void main(String args[]) { DhModule mod = new DhModule(); // set the code class, since we are not using an HTML template, there // is no call to DhModule.setHTMLDocument mod.setCodeClass("MyDhDocument"); // DhModule.doMain() will output the HTML generated by the MyDhDocument object to // standard output mod.doMain(args); } }
Using the com.ms.wfc.html package in a console application is very similiar to using the package on the server-side in a client-server application. For more information on using the com.ms.wfc.html package on the server-side, please see the "Using the com.ms.wfc.html Package on a Server" section in the documentation.
When a control is copied and paste in the Forms Designer, the new copy of the control will, by default, have its events handled by the same handler methods as the original control. To create new handlers for the new control's events, follow these steps:
A control in development can be hosted on a form that exists in the same solution as the control. Changes to a control, however, will not be reflected in the hosting form's designer until the control's project is rebuilt, and the designer is closed and reopened.
Line breaks and formatting information may not copy correctly when you copy and paste sample code from the MSDN Library Visual Studio documentation to your code editor. To work around this issue, do one of the following:
The SolutionInspector sample is hardcoded to execute C:\Program Files\Microsoft Visual Studio\Common\IDE\IDE98\devenv.exe. If the file devenv.exe was installed to a different path on your system, do the following to successfully run the program:
Now you can run SolutionInspector by following the instructions in the HTML page included in the SolutionInspector project.
The "Open Project" button on the MiscUI sample (MiscUI.exe) and the "Launch the Project for the Active Form" toolbar button on the WFCRocks sample (WFCRocks.exe) will not be function properly if run from their respective documentation pages. This problem occurs because the executable files are coded to find the Visual J++ project files (.vjp) in the current directory, while the browser is running each executable from the cache.
To open each project, use the "Start as a Visual J++ Project" links on each respective page.
The OutlookSample WFC sample project requires that Microsoft Outlook be properly installed and configured on the computer that you are executing the sample on. If Outlook is not present or is improperly installed, the sample will fail with an error message: "An exception of type 'com.ms.com.ComError' was not handled" when trying to run the OutlookSample application. The sample also requires network access to an Exchange server to properly look up email names and convert them to Exchange server addresses.
The DxSoundMix sample requires a properly installed and configured Windows compatible sound card to run. You will receive the following error message "com.ms.com.ComFailException" if you do not have a sound card installed on your computer.
The instructions for building and running the ServerDataBinding sample application contain a link to the .asp file, ServerHTTPHeaders.asp. This link is incorrect. The correct link should be to the ServerDataBinding.asp file that step one of the build/run instructions had you copy to an executable directory on your IIS machine. The proper link is "http://localhost/scripts/ServerDataBinding.asp".
The ServerDataBinding sample utilizes the Northwind sample database installed along with the Visual J++ 6.0 samples. To run the ServerDataBinding sample you will first need to create a System DSN on your NT IIS server for the Northwind database. Instructions for creating this DSN can be found in the "Configuration Requirements" section of the DataGridSample application instructions.
The instructions for the ServerGenerator sample instruct you to copy the ServerGenerator.asp and the ServerGenerator.htm files to an executable IIS directory. This is incorrect since the file name ServerGenerator.htm does not exist. You will only need to copy the ServerGenerator.asp file to an executable IIS directory and follow the other configuration instructions to be able to execute the sample.
The configuration instructions for these three samples have a step that reads "Build the .java files to a directory on the classpath". This is telling you that the .class files generated by compiling the .java files mentioned must be available on the Java classpath of the server computer for the samples to be run. To actually build the sample class files onto the classpath, you can set the "Output Directory" in the "Compile" tab of the "Project Properties" dialog box to the directory where you want the .class files to be generated (for example c:\winnt\java\trustllib). This will cause the .class files generated when you build your project to be written in the specified output directory. If this directory is on the Java classpath, your class files will be automatically be available to other Java and COM applications.
The WFC DHTML sample projects included with Visual J++ 6.0 were created with the Visual J++ 6.0 Technical Preview 2 style of attaching to HTML documents. For example, the dhButton sample has two java classes: a Class that extends DhDocument, and a Module1 that extends DhModule. The Page1.HTM file included with the project has an OBJECT tag that references the project Module1 class file and a BODY tag that references the Class1 class file. This has been changed and simplified for the Visual J++ 6.0 final release, but the DHTML sample code was not updated. While both styles still work with the current WFC run time, the recommended method for binding WFC code to your HTML files is demonstrated by the "Code-behind HTML" project type which can be found in the "New Project" dialog in the "Web Pages" folder of the "Visual J++ Projects" top level folder (under the "File" menu, "New Project" menu pick). This project will contain a single Java class that extends DhDocument. The Page1.htm file also generated by the project template will contain an OBJECT tag that references "com.ms.wfc.html.DhModule" and a PARAM tag that references the Java class to be loaded and bound to the HTML page. This is a simpler and cleaner way to bind the HTML documents and is the recommended method that you use.
In the Visual J++ Text editor, CTRL+SPACE is used as a part of CodeSense to complete words as you type them. Unfortunately, this keyboard control sequence conflicts with the keystrokes used to invoke the Input Method editor (IME) on Chinese versions of the Windows 9x and Windows NT operating systems. To work around this problem, use the TAB key for word completion (which is the same as CTRL+SPACE on other language platforms,) or, remap the keystroke combination in the Tools/Options dialog box.
When using the HTML editor on Chinese platforms, mixing DBCS Kanji characters and italicized characters from the Latin alphabet can cause painting and clipping problems. This is a known issue in Internet Exporer 4.0 and will be addressed in future versions of Internet Explorer.
When using the method java.lang.Runtime.exec() on DBCS platforms, the command passed to the exec() method must not contain DBCS characters. Use of DBCS characters will cause an exception to be thrown. To work around this problem, always use Single-Byte Character Set (SBCS), or English characters.
The following is a list of some of the more common WFC issues that developers may encounter when upgrading to the release version of Visual J++ 6.0:
/* @designTimeOnly menuItem3.setLocation(null); */In the final release of Visual J++, this line will cause an error that prevents the Forms Designer from viewing the form. To work around this problem, delete the line of code manually.
private void keyPress (Object sender, KeyEvent e)- or -
private void addOnKeyPress (new KeyEventHandler (this.xxxxxxxxxx));To handle key press events in the final release, replace the above lines of code with code similar to the following lines:
private void keyPress (Object sender, KeyPressEvent e)- or -
edit1.addOnKeyPress (new KeyPressEventHandler (this.xxxxxxxxxx));
If you are installing Visual J++ or Visual Studio on Windows NT 5.0 (beta), you will also need to install signcode.exe from the Windows NT 5.0 SDK or the Internet Explorer SDK for Windows NT 5.0, and then ensure that signcode is on the Windows path.
When using the Microsoft development environment deployment feature, you should be aware that servers which have the FrontPage acceptor installed as the default acceptor cannot support posting to URLs which contain non-7-bit characters. This is because the FrontPage acceptor is non-UTF8 compliant, and Visual Studio encodes all URLs in an encoded UTF8 format so that deployment between computers having different code pages is possible. When posting to a server which has the FrontPage acceptor installed as the default acceptor, URLs should be formed from characters in the range 0x20 through 0x7f (32 through 127).
If the server supports Posting acceptor 2.0 as the default acceptor, then this limitation does not occur.
Running a self-extracting executable created by the development environment self-extracting package/installation feature on an international operating system that allows the use of MBCS characters (for example, Japanese, Chinese, and so on) will fail if the TMP environment variable is set with MBCS characters. To solve this problem temporarily, you can change the TMP environment variable to use Single byte characters instead.
To temporarily change the TMP variable to Single byte characters
Any executable launched from within the MS-DOS window will use the temporarily set TMP variable until the window is closed.
You can deploy Visual J++ authored COM servers that are called from ASP pages in Microsoft Internet Information Server (IIS). Once IIS has executed an ASP page that loads a Visual J++ authored COM server, IIS will cache the server in its internal storage. If you then deploy an updated version of the COM server to IIS and try to execute it, the new version will not be loaded, and IIS will continue to use the old version until IIS is stopped and restarted.
To make IIS use the updated version of the COM class by restarting IIS
- or -
You can build a .cab file distribution unit with an external dependency in another .cab file distribution unit, so that both distribution units will be downloaded to the client computer when the client views the Web page that hosts the distribution unit. However, be aware that Internet Explorer 4 does not track changes to the versions of external dependencies - creating a situation in which the first .cab file is downloaded but the updated dependency is not.
For example, if you modify both distribution units, update their version numbers, and update the dependency's version number in the External Dependency tab of the Cabinet Properties dialog box, the first .cab file will be downloaded, but the second will not.
To resolve this, you might change the friendly name of the second .cab file distribution unit. This will cause the second .cab file to be downloaded again. Be aware that both versions of the .cab file distribution unit will now be installed on the client computer.
Microsoft Visual Studio supports deployment between computers with differing code pages. It does this by converting the URL to a tokenized UTF-8 format, so that characters outside of the range 0x20 - 0x7f can be used in URLs. Thus, if you specify the following URL on an English computer for your deployment target:
http://myserver/▄╓
The characters ▄ and ╓ are hi-ASCII and are not necessarily supported outside of the scope of the current code page, and so the URL used internally for the purpose of deployment will be:
http://myserver/%c3%9c%c3%96
since 0xc3 0x9c is the UTF-8 representation of the hi-ASCII character ▄, and 0xc3 0x96 is the UTF-8 representation of the hi-ASCII character ╓. The server will then "decode" this URL, and place the files in the appropriate location, so that from the client computer you can still access the deployed files by using the URL "http://myserver/▄╓/{name of the file}".
A problem occurs, however, because FrontPage servers do not understand tokenized URLs, and will interpret the encoded URL literally without decoding it. Thus, if you deployed a solution to a FrontPage server, and used the URL "http://myserver/▄╓", Microsoft Visual Studio may indicate that the files were deployed successfully, but the files will in fact be deployed to "http://myserver/%c3%9c%c3%96". You will therefore be unable to access the files, either for browsing or debugging, by using "http://myserver/▄╓/{name of the file}".
Because of this limitation, it is important to use only 7-bit characters in URLs when deploying to FrontPage servers; specifically, characters in the range 0x20 - 0x7f (Microsoft Visual Studio does not encode the "space" character 0x20 in deployment URLs). Hi-ASCII and MBCS characters should be avoided when deploying to FrontPage servers. Alternately, you can install Microsoft Posting Acceptor 2.0 on the server, which fully supports UTF-8 encoded URLs for deployment. See the installation documentation for instructions on how to install Posting Acceptor 2.0 onto your server from the Microsoft Visual Studio CDs.
If you build a setup distribution unit that contains large files on a computer that has anti-virus software installed, the build process can fail with file access errors. If this happens, try turning off the anti-virus software on that computer.
If you include delimiting characters when assigning values to tag attributes in HTML files - such characters include semicolons, colons, or angle brackets - the values must be contained within quotation marks, as per W3C standards. The HTML editor in Microsoft Visual Studio does not do this, and in fact will remove quotation marks from values when an HTML file is loaded into the editor. Therefore, when the deployment engine updates the file's CODEBASE links, the deployment parser may stop reading in the value when the first standard HTML delimiter is encountered. If this happens, only part of the value will be saved back to the file before the file is actually deployed. (The deployment engine works with a temporary copy of the file, so the original is unaffected by this.)
To avoid this problem, manually put quotes around the values which contain delimiters before deploying the file. You will need to do this whenever you open the HTML file for editing in the Visual Studio HTML editor, since the editor will strip the quotation marks when the file is reopened, or the view type in the editor is changed.
If you specify the floppy drive of a network server computer as the destination for server component installation for deployment, the deployment will fail even if no error messages are given. This is due to an inability to create folders on the floppy drive.
To correct the problem, right-click on the Server Components service in the deployment target and select "Deployment Target Settings." In the resulting dialog box, change the installation drive and directory so that a hard drive location on the network server is specified. (Since the default location for server component installation is the C: drive, users deploying to NEC PC's will want to change that default location, as C: may specify a floppy drive on those machines.)
The default naming convention for the registration of COM components is projectname.classname, regardless of the Java packaging of each COM class. A build error will result if you attempt to create two COM classes with the same name in the same project, even if they are in different Java packages. To create classes with the same name in different packages, you may deliberately specify a progid for the class using the "progid=" parameter in the @com.register tag. As an example convention, you could specify "progid=projectname.packagename.classname " in the @com.register tag for each of the COM classes.
Visual Component Manager User Interface Reference: The topic "Related Files Tab (Component Properties Dialog Box)" incorrectly states that the tab is used to display and enter files that are related to the selected component. In fact, none of the information displayed on this tab can be modified. You can add related files to a component only when publishing or re-publishing the component. For more information, search online, with Search titles only selected, for "Publishing Components" in the MSDN Library Visual Studio 6.0 documentation.
If you installed VCM 5.0 (previously available for Web download) you will have the following Windows Registry keys setup. They were necessary for VCM 5.0 and the 1.0 version of the Repository. If you find the following Registry entries then it is safe to remove them and may, in fact, improve VCM 6.0 performance.
If you try to open an existing .mdb file from within VCM that is not a repository database (i.e., it does not contain the repository structure/tables), you will be asked if you want the repository tables added to the database. You should not do this for normal use; the repository should generally be in a separate database. This will work, but it can take as long as 10 minutes to create the repository structure in an existing .mdb file.
To create a brand new .mdb file containing the repository structure, right-click in the folder outline, click Repository, click New, and then enter the name of the file you want to create.