---------------------------------------------------------------- JBuilder.txt Late-breaking news, workarounds, and useful tips ---------------------------------------------------------------- ----------------- TABLE OF CONTENTS ----------------- SECTION 1 A. General B. Install C. Migrating applications from JBuilder 2 to JBuilder 3 D. dbSwing E. Deploying applets and applications F. InterClient and other JDBC drivers G. Visual Design Tools and JavaBeans H. The jbInit method I. DataStore J. DataExpress K. Wizards L. Debugger M. Code Insight N. IDE O. Windows 95/98 P. Help System SECTION 2: International Issues A. Install and environment B. Compiler C. Visual Design Tools D. Swing, dbSwing and JBCL Components E. Database F. DataStore G. CORBA --------- SECTION 1 --------- A. General ---------- For the latest information on JBuilder, please see the JBuilder section at http://www.borland.com. The online Help is the most complete and updated version of the product documentation. To display the online Help, choose Help | Help Topics. See the JBuilder technical publications page at: http://www.borland.com/techpubs/jbuilder for updates as they become available. B. Install ---------- * In accordance with Windows conventions, JBuilder automatically updates your registry to add a file association for .java, .jpr, .class and .idl files. This means JBuilder launches automatically when you double-click one of these files in your Explorer. If you wish to change these file associations: 1. Open your Explorer 2. Select the View menu and choose Options 3. Select the "File Types" tab. 4. Select the file type you wish to change and select Edit 5. Update the "open" action for the file Now, selecting the Edit command from the right-click menu in the Explorer invokes your editor. Double-clicking the file still launches JBuilder. You will need to do this for each file type you wish to change. Additional information can be found in the online help for Windows. C. Migrating applications from JBuilder 2 to JBuilder 3 ------------------------------------------------------- * To migrate your application from JBuilder 2 to JBuilder 3, select Wizards | Package Migration... from the main menu. * If you have a JBuilder 2 project that utilizes Swing (JFC) and/or JBCL2, use the Package Migration Wizard to update your code for the new locations of classes in JFC and JBCL. * With JBuilder 3, Java source code created with earlier versions of JBuilder's JavaBeans Component Library or Java Swing components will not compile. This is largely due to: (1) A change in package names that now follow the industry standard naming convention of com.borland and (2) JavaSoft moving their com.sun.java.swing package to javax.swing. Also, selected Inprise classes have been moved to other packages to more appropriately match their usage. The Package Migration Wizard takes care of this for you. * The JBuilder 3 compiler is now more compliant with the Java specification. Some items that compiled in JBuilder 2 will no longer compile in JBuilder 3. Most notable is the change in switch statements (java lang spec 15.27) "... Qualified names of the form [TypeName] . [Identifier] that refer to final variables .. ". This means that qualified names of the form [FieldName] . [Identifier] are no longer considered to be a constant expression. The error is usually visible in case statements, because the case label is required to be a constant expression. The fix is to change code of the form KeyEvent e; KeyEvent e; switch(e.getKeyCode()) { into: switch(e.getKeyCode()) { case e.VK_UP; case KeyEvent.VK_UP; } } essentially replacing the name of the field with the name of its type. * When using the Package Migration Wizard, the project's .jpr file is not updated to reflect the new file locations. You must manually remove/re-add the project nodes to reflect the new location. (17151) D. dbSwing ---------- General ------- * Column edit masks are not supported. As with JBCL controls when there is no edit mask, a column's display mask - either the value you specify, or a default - is used to parse and format during edit. However, a mask of literals and character positions is not displayed during edit and invalid input is not detected until you try to leave edit mode. * dbSwing components do not support data set's columnPaint() method. A custom cell renderer, which has almost the same API, can be used instead in aJdbTable, JdbList or JdbTree component. * Pop-up menus for Swing components don't paint submenus that fall completely within the bounds of the component. JdbTable and JdbEditorPane have pop-up menus that exhibit this problem. The solution is to right-click close enough to the right or bottom edge of the component that some part of the pop-up menu will extend beyond it. Then the submenu is displayed correctly. * Setting visual properties at runtime: A dbSwing component picks up visual properties from the column it's bound to when those properties have not been set on the component itself. If a property has been set on the component, that setting takes precedence over the column's setting. This is straight-forward when all properties are set before the application is run. If you plan to change visual properties of a column while the application is running, you need to understand how this works in a little more detail. (If you're only changing component properties, you can ignore this.) * Swing uses objects tagged with the UIResource interface to distinguish default UI properties (which it will change freely) from custom settings (which it tries to preserve). This mechanism lets it change default setting when switching from one look-and-feel to another without losing custom settings. In this case, surprisingly, we need to make our custom settings look like default settings so they can be replaced by subsequent custom settings. * Suppose you change the font of a column bound to a JdbTextField whose font property has its default value. The data in the text field is displayed in the new font. Now the text field has a custom font setting, which Swing wants to preserve; if you change the column's font again, the text field won't inherit the newest value. To prevent this, always set the column's font to a javax.swing.plaf.FontUIResource object, which is just a java.awt.Font object that also implements the empty javax.swing.plaf.UIResource interface. The UIResource interfacce indicates that an object is a UI default rather than a custom setting. A dbSwing component will inherit and use a FontUIResource object just as it does a Font object - the difference is that it will consider the FontUIResource to be a UI-default object, and will be willing to discard it in order to inherit the next new FontUIResource from the column it's bound to. * dbSwing models: A component that uses a DBListModel or DBTableModel as its model may not see data even when it is properly bound to a data set and the data set is open. For example, KL Group's SimpleChart bound to a data set with a DBTableModel might not display any data. To force the DBTableModel to initialize, call a method on it, such as getRowCount(). Table ----- * Ending edit: You must press Enter to end edit in a field. Tab won't work because Swing unfortunately uses it to move to the next component. You can use the mouse to select another field in the same row, but you will no be able to begin editing it until you complete or cancel the edit already in progress. If editing is blocked unexpectedly, find the field still in edit (look for a lowered-bevel border) and finish editing it, or press Esc to cancel the edit. If you select a new row, JBuilder will end an edit in progress if it can; if it fails, you will see an error message on you JdbStatusLabel or in a dialog. * Hiding columns: If you don't want to display all of a data set's columns in a JdbTable, use JdbTable's hiddenColumns property. This property can't be set in the UI Designer because it takes an array, but the code is easy - something like: jdbTable1.setHiddenColumns(new int[] { 5, 6, 8 } ); where 5, 6, and 8 are the ordinals (counting from 0) of the columns that should not be displayed. To reset, use: jdbTable1.setHiddenColumns(null); * Customizing columns and column order: You can use JdbTable's customizedColumns property to associate cell renderers and editors with columns, set column widths in a table, and control the order of columns. Like hiddenColumns, customizedColumns must be set through code because it takes an array of values, in this case an array of TableColumn objects. A JdbTable has a TableColumn for each column in its data set, but this will probably be the only time you work with them explicitly; if so, remember to add an import statement for javax.swing.table.TableColumn to your code. Instantiate a TableColumn for each column you want to set properties for and set those properties. When you call setCustomizedColumns(), you must provide a TableColumn object for every column up to and including the right-most one you want to manipulate. Some may just be placeholders. For example, suppose you have a data set with five columns. You want to set a minimum width for the first column (remember that its ordinal is 0), to ensure that it's always be visible, and you want to swap the positions of the third and fourth columns (ordinals 2 and 3). You might use code like this: // Instantiate TableColumn for column 0 and set minimum width TableColumn tblCol0 = new TableColumn(0); tblCol0.setMinWidth(100); // Set customizedColumns property. Shift column 3 to left of column 2 by // changing their positions in the array. Need placeholder for column 1, // but not for column 4. jdbTable1.setCustomizedColumns(new TableColumn[] { tblCol0, new TableColumn(1), new TableColumn(3), new TableColumn(2) } ); jdbTable1.repaint(); To revert to default colums, use: jdbTable1.setCustomizedColumns(null); * Unlike in JBCL, a column with a picklist does not exhibit combo box behavior when displayed in a JdbTable. * JdbTable does not always update its TableColumn model correctly if its dataSet property is set after the JdbTable has already been displayed. If you need to change the dataSet being viewed by JdbTable after it is already visible, set its dataSet property to 'null' first, and then set it to the dataSet you wish to view. A typical indication that the TableColumnModel has not been set property is that the columns are all the same (default) width, and display masks are not used to display data. Text components --------------- * Limiting length of input with DBPlainDocument: The default document for a JdbTextField, JdbTextArea, or String column in a JdbTable is a DBPlainDocument. DBPlainDocument extends Swing's PlainDocument to add the maxLength property, which enforces a limit on the number of characters that can be entered into a field. DBPlainDocument is a late addition to dbSwing and is not documented in the package reference. The default value of maxLength is the bound-to column's precision. If precision is -1, input is not limited by maxLength. To set maxLength, use code like this: ((DBPlainDocument) jdbTextField1.getDocument()).setMaxLength(25); You might set maxLength for a column that is not provided by the query, or when using a TableDataSet. Don't set precision for a column from a QueryDataSet larger than than the value from the server because you won't be able to save those values back to the server. Also remember that if you set precision on a column from a server, the server's value takes precedence over yours unless you turn off metaDataUpdate. It is for this reason that we suggest setting maxLength instead. To enforce additional input constraints at the model level (for example, to convert input characters to upper-case), extend DBPlainDocument as necessary and set it as the text component's model. * Swing's support for HTML and RTF in JEditorPane is still under development. Before you begin saving HTML or RTF documents in a dataset and manipulating them through JdbEditorPane, be sure that they are simple enough to be loaded and saved successfully. Also be aware that loading files into a data-aware JdbEditorPane may not always succeed. Finally, don't mix document types in the column. Lists and combo boxes --------------------- * Unlike JBCL, dbSwing doesn't automatically give you combo box behavior in its standard field component when the component is bound to a data set column that has a picklist. Use a JdbComboBox instead of a JdbTextField in these cases. * JdbComboBox's dropDownWidth property sets the width of the drop-down, but has no effect on the width of columns in a multi-column drop-down derived from a picklist. dropDownWidth is mainly useful in conjunction with the items property for displaying a single column drop-down of arbitrary width. To specify the width of an individual column in a picklist drop-down, set the width property of the corresponding picklist Column. * Editable JdbComboBox: When an editable JdbComboBox gets its picklist from its items property, you are allowed to enter values not in the picklist into the column the combo box is bound to. When it gets its picklist from the picklist property of the bound-to column, you must enter a value from the picklist; editing in the selected text area of the combo box is simply a convenient way to choose a value from the list. * Unknown values: Ordinarily, the selection in a data-aware JdbList or JdbComboBox is the current value of the column it's bound to. If this value is not in its list, a JdbList has no selected value. Because its selected text area always displays some value, even when it's empty, JdbComboBox can't handle an unknown value in the same way. Instead, the message "Unable to locate corresponding value" is displayed when you navigate to a row with an unknown value. The assumption is that you want to correct these unknown values when you encounter them. If you don't, you probably won't want to use a combo box to display a column containing unknown values. * Duplicate values in JdbNavList and JdbNavComboBox: if there are duplicate values in a JdbNavList and JdbNavComboBox, selection from the list or drop-down will find the corresponding match. If you type into the selected text area of an editable JdbNavComboBox, you will always always find the first match. Check boxes and buttons ----------------------- * The selectedDataValue and unselectedDataValue properties take on default values if they are not set. This is most useful when the component is bound to a boolean column; then selectedDataValue defaults to true and unselectedDataValue defaults to false. When bound to a numeric column, the defaults are 1 and 0; when bound to a String column, they are "true" and "false". * The values of the selectedDataValue and unselectedDataValue properties must be consistent with the display mask of the bound-to column. This usually isn't an issue because these components are seldom bound to real number or date/time columns, which are the ones that benefit most from custom formatting. However, if you do specify a display mask for a colum bound to one of these components, it's important to be aware of this rule. For example, a boolean column with a display mask of "Yes;No" bound to a JdbCheckBox with a selectedDataValue of "true" will fail on open with a com.borland.dx.text.InvalidFormatException with the message "Error in parsing string". Set its selectedDataValue to"Yes" instead. E. Deploying applets and applications ------------------------------------- * JBuilder has the ability to specify a particular JDK to use with a project. Choosing a particular JDK switches the version of AppletViewer used bythat project to the one that comes with the selected JDK. JDK 1.02 applets won't run correctly from within the IDE due to a problem with the version of AppletViewer that comes with JDK 1.02. JBuilder (and subsequent versions of AppletViewer) uses the CLASSPATH to allow for Applet launching to be more flexible. You can still use JDK switching to compile and ensure that you are not using any 1.1 specific methods in your 1.02 code. * You can use the enhanced Deployment Wizard to add resources, files and dynamically loaded classes to your deployment set. You can also remove files from the deployment set if you feel they are not needed. F. InterClient and other JDBC drivers ------------------------------------- * When using InterClient or any other JDBC driver, a Library entry needs to be added to the project properties. This is done by adding the JDBC driver .jar to the project properties file. The following instructions show how to add an InterClient.jar file to the project properties file and assumes you have already installed InterClient to a location that does not include any spaces in the path name. You can follow these same instructions for any other JDBC driver. To add the InterClient library to your project, follow these steps: 1. Choose Project | Properties. 2. Choose Libraries. 3. Choose New. 4. In the Name field, type InterClient. Press the Edit button next to the Class path field. 5. Choose Add Archive... 6. Specify the path to the Interclient.jar file, which is in the InterClient directory. 7. Choose the OK button in this, and the next dialog box. This 'builds' the library's dependency files. 8. From the Project Properties dialog, choose Add. 9. Select InterClient, and choose OK. 10. Finally, choose OK to close the Project Properties dialog. If you want this change to affect all future projects, choose Project | Default Properties and follow the steps above starting with step 2. But if you've already built the library's dependency files, you can simply choose Project | Default Properties, and then continue from step 8 above. If you do not add a Library entry to your project for InterClient, you may receive the error: "No Suitable Driver". * The InterClient install no longer updates the classpath in JBuilder.ini, which is needed for live data at design time in the form designer. To make the update manually, follow these steps: 1. Exit JBuilder. 2. Make a backup of the file, \bin\JBuilder.ini 3. Now open the original JBuilder.ini file using Notepad or your favorite text editor. 4. Find the section headed by, "[JavaVM_Properties]" 5. Within a few lines after that, there will be a line that begins with, "Djava.class.path=..." 6. At the end of that line, add a semicolon and then the path to where you have installed interclient.jar. For example: Djava.class.path=;D:\InterBase\InterClient\interclient.jar; But be sure to use the path where you have located interclient.jar on\ your machine. Note, as with any Java classpath, there should not be any spaces in the directory names for this path statement. 7. Save the file you are editing. (18461) The online Help contains the rest of the instructions for using InterClient. G. Visual Design Tools and JavaBeans ------------------------------------ * If you see one of your components as a red box with its class name at the top, JBuilder has not been able to create an instance of that component for the designer. This is called a "Red Bean". Some reasons you might see a Red Bean are: 1) That class has no default (parameterless) constructor 2) That class threw exceptions on every constructor JBuilder tried 3) That class is the 'this' object and it extends an abstract class Items (1) and (2) can be fixed by supplying a proper default constructor or subclassing that class in order to provide a default constructor. Item (3) is more complex. Whenever JBuilder needs to instantiate an object to be the 'this' object, it encounters a paradox. It cannot instantiate the object you are designing. To circumvent this problem, JBuilder always attempts to instantiate the superclass of the "this" object. If the superclass is abstract, it cannot be instantiated. Here is the solution: In the file lib\jbuilder.properties, you will find a line that looks like: jbuilder.concreteProxy.com.sun.java.swing.JComponent=com.borland.jbuilder.dt.JComponentProxy This line says that whenever you are forced to instantiate com.sun.java.swing.JComponent (which is abstract), you will find an acceptable concrete proxy class for it in: com.borland.jbuilder.dt.JComponentProxy. You may add your own proxy objects using this pattern. The proxy class does not need to do anything other than the following: 1) Extend the abstract class in question. 2) Be concrete (not be declared abstract itself). * Currently an Application Generator-generated HTML client page is not set up for interactive password handling. It is therefore recommended that transparent logins are chosen in the Application Generator and the Data Modeler when generating an HTML client application. Transparent logins are the default settings for both of these tools. To change this setting in the Data Modeler, choose the View | Options menu item and change the "Username and password" checkbox. In the Application Generator, go to the Data Access page and change the "Login code generation" ComboBox. If a login process is required, a custom login page can be written and used to retrieve a username and password. The DataModelGateway.java file provides getUsername() and getPassword() methods that can be modified to obtain an HTML variable once the login page has been submitted. (19293) * In order to create a data module using the Data Modeler, it is required that the Data Express library (dx.jar) be included in the project properties. To add this library, choose the Project | Properties menu item to open the Project Properties dialog. Add the JBCL 3.0 library to the project or create a new library that includes the dx.jar archive and add that to the project. (21043) * In the Data Module Interface Designer, attempting to create a DataModule if no libraries are selected for the project will result in a NullPointerException and the generation fails. The workaround is to select a library. (21043) * If you see the exception: Unknown column name: you need to ensure that persistent column(s) are added to the DataSet. This occurs when using dbSwing components and QueryDataSets where the QueryDescriptor has the executeOnOpen parameter set to false. Parameterized query applications built using the Application Generator may see this problem. How to add persistent columns using the Designer: (1) Select the class that defines the QueryDataSet throwing the exception and Design it (select the Design Tab ). (2) Under the Data Access folder, double-click on the DataSet to bring up the column editor. (3) Add new persistent column(s) using +. Make sure you set the Column name and type corresponding to the column showing up in the Unknown column name Exception. (4) Save and recompile. H. The jbInit Method -------------------- * The contents of the jbInit method are arranged as follows: 1. Any assignment statements that provide initialization for subcomponents appear first. 2. Initial subcomponent property settings are in order by subcomponent and then by property. (Properties are ordered as defined by the BeanInfo class, or as the getter methods are found through reflection). Event listener addXxxListener calls are also placed with the subcomponent, ordered as if they were property settings. 3. Additional method calls for wiring subcomponent relationships are created by the designers. These include container.add(component, constraints) calls as well as menu and data module assembly. Generally, these are ordered by subcomponent, and then by child Z-order. If you rearrange any of these methods by hand, the changes will probably be undone the next time a designer manipulates something nearby. Additional hand-coded method calls or other statements can be placed anywhere within the jbInit method, but it is recommended that they be placed at the end. * The Designer only works with public classes that have public contructors. The class that you are designing does not need to be declared public, but its superclass needs to be, since the designer instantiates the superclass in its place. The designer looks for variables of class scope and method calls found in the jbInit(). If the jbInit() method signature is altered, the Designer will not recognize it. If you find that you need to pass a parameter for use in the jbInit method, consider using the 'entities' DataModule pattern. Essentially, the Designer also searches your class for a method with the signature 'public void setModule(Object a)'( where the parameter may be the type of your choice) and if it finds one, it will present the parameter as a property of the 'this' Object. This allows you to specify an instance for the Designer to use while you are designing. When using the 'entities' DataModule pattern, the call to jbInit() should be in the setModule method instead of fromthe constructor. At runtime, the object that instantiates the class that you are designing is responsible for calling the setModule method with the appropriate parameter. I. JDataStore ------------- JDataStore and DataStore are used interchangeably throughout JBuilder3. * More information on the new SQL Engine, Local and Remote DataStore JDBC drivers, and DataStore's support for transactions can be found in the DataStore Programmer's Guide. Sample JDataStore files ----------------------- * JBuilder includes three sample JDataStore (JDS) files: - Employee.jds: a conversion of the InterBase sample Employee.gdb database, which contains various tables for a company's employees, salaries, and sales. - Intlemp.jds: the same database with additional data that contains international characters. - IntlDemo.jds: a conversion of the InterBase database IntlDemo.gdb, which contains tables for IntlDemo, an order entry application. This database also contains international characters. The first two files are in the samples\com\borland\samples\dx directory. IntlDemo.jds is in the samples\com\borland\samples\intl\application\data directory. These files may be used to familiarize yourself with the DataStore Explorer, and as examples of the new JDataStore embedded database. None of these files are transactional, which means that you cannot access them with the DataStore JDBC driver. Access to a JDataStore through the JDBC Explorer or Data Modeler requires a JDBC driver. Use the DataStore Explorer to make them transactional: 1. Start the DataStore Explorer (Tools|DataStore Explorer in the JBuilder menu). 2. Open the JDS file (File|Open in the DataStore Explorer menu). 3. Select TxManager|Install. 4. Click OK to accept the default settings for a transactional DataStore. 5. Select File|Close, or exit the DataStore Explorer. You may now access the JDS file(s) through the JDBC driver. For more information, see the DataStore Programmer's Guide. * The property DataStore.LogBDir is disabled on transactional stores. (20631) Extended Properties for DataStore Explorer database connections --------------------------------------------------------------- * The New JDBC Connection dialog box in the DataStore Explorer now contains an Extended Properties option. When a database connection requires additional properties, use a comma-separated list of names and values; for example: user=sysdba,password=masterkey,charset=SJIS Otherwise, leave the field blank. This dialog box is used to define database connections that are stored in the DataStore, when using the DataStore Explorer as a query console. See "Using the DataStore Explorer" in the DataStore Programmer's Guide for more information. * JDBC URL using Unicode fails to connect to a DataStore. The workaround is to create the DataStore with the Unicode path by using the DataStore Explorer or reset the new information with TxManager.LogADir in the same form, before opening the store. For example: TxManager tx = new TxManager(); tx.setALogDir("//jazz/edrive/stormbuild...); * The DataStore Explorer will hang when trying to open a DataStore which is already in use by another process. (21010) J. DataExpress -------------- * DataSetException's exception dialog has been replaced by separate exception handlers for JBCL and dbSwing. DBExceptionHandler, dbSwing's version of JBCL's ExceptionDialog, has an Exit button (can be hidden via a property setting, but visible by default) which will also automatically close any open DataStores it can find. DBExceptionHandler is displayed by default by dbSwing components when an Exception occurs in a dbSwing component. (20241) Users converting JBCL 2.0 applications to JBCL 3.0 should use: com.borland.jbcl.model.DataSetModel.handleException(...); Users converting dbSwing applications to 3.0 should use: com.borland.dbswing.DBExceptionHandler.handleException(...); * com.borland.dx.dataset.Provider has a new ParameterRow property, which includes both a setter and getter. This addition is inherited by its subclasses DataModelProvider and JDBCProvider, and in turn, ProcedureProvider and QueryProvider. Strict date parsing ------------------- * JBuilder's date and time parsing is now strict by default: a value with month, day, hour, etc. outside the range of valid values will not be accepted. It's unlikely that you'll want to over-ride this behavior. If you do want to allow lenient parsing, follow the instructions for "Forcing Strict Date Parsing" at http://www.borland.com/devsupport/jbuilder/ti/strictdate.html, but call setLenient(true) instead of setLenient(false). You'll also need to correct the import statements: borland.jbcl.control.MaskableTextItemEditor is in com. borland.jbcl.control borland.jbcl.model.ItemEditMaskStr is in com.borland.dx.text borland.jbcl.model.VariantFormatStr is in com.borland.dx.text borland.jbcl.model.VariantFormatter is in com.borland.dx.text borland.util.Diagnostic is in com.borland.jb.util borland.util.Variant is in com.borland.dx.dataset Date patterns with two-digit years ---------------------------------- * By default, JBuilder uses Java's short date pattern to format and parse date values. When a string contains a four-digit year, the year is taken just as it is. When a string contains a two-digit year, the year is assumed to fall in a window that runs from 80 years before the current date to 20 years in the future. To understand the implications of this, consider an example: This character string is parsed: "9/23/2085" The value in the resulting date object is: September 23, 2085 With the default formatting, this is displayed as: "9/23/85" If you edit this string to be: "10/23/85" Parsing the string gives this value in a date object: October 23, 1985 Only the month was edited, but the century also changed. To prevent this unexpected behavior, JBCL components now always display a four-digit year when a date value is being edited using the default format. Because the edit pattern specifies a four-digit year, the 80/20 window is not used: any year from 1 to 4 digits may be entered, and that year is stored in the date object. If you specify the pattern used for editing, JBuilder will not alter it. dbSwing components do not substitue a four-digit year when editing with the default format. However, you still have a number of choices for date handling. The default behavior is often satisfactory when all dates in a column of a data set will be entered with two-digit years. In other cases, input can be validated in program code. Often this is as easy as specifying minimum and maximum values for a column. Or you can override the default formatting to use any desired display format, probably including a four-digit year, by setting the display mask property. * If an application has a status component, DataExpress sends some messages, typically ValidationExceptions, to it; otherwise, it tries to display them in a dialog. If there is a navigation component in the application it may intercept the message, preventing the dialog from appearing. Unless you handle exceptions yourself, it's a good idea to include a status component in any application that contains a navigation component. For a dbSwing application, this will be a JdbNavToolBar and a JdbStatusLabel; for JBCL, it will be a NavigatorControl and a StatusBar. * To use the Kona/MSSQL driver with JBuilder requires package references to be modified so that JBuilder can find the classes. You can do this by unzipping the Kona/MSSQL files and re-zipping them with a new directory structure. The mssqlserver4rel3111.zip file prepends weblogic\mssqlserver4\classes to all of the packages. This part should be removed. For example, as downloaded, the entire reference for the Driver.class is: weblogic\mssqlserver4\classes\weblogic\jdbc\mssqlserver4\ However, JBuilder looks for: weblogic\jdbc\mssqlserver4\ Unzip the mssqlserver4rel3111.zip file, and then re-zip it from the classes directory (so that weblogic is the root) and copy that new zip file into your JBuilder3\lib directory. * The JDBC Explorer only supports tables with unique rows. (19494) * The JDBC Explorer requires drivers that can have more than 1 statement open at any given time, such as the WebLogics type 4 driver. You can only have one statement open at a time in the JDBC Explorer if you are using an ODBC driver. (19042, 19497) * The UI Designer won't write skeleton code for StorageDataSet's calcFields event. The basic code to add a listener is: queryDataSet1.addCalcFieldsListener(new CalcFieldsListener() { public void calcFields(ReadRow changedRow, DataRow calcRow, boolean isPosted) throws DataSetException { queryDataSet1_calcFields(changedRow, calcRow, isPosted); } }); The skeleton for the event handler is: public void queryDataSet1_calcFields(ReadRow changedRow, DataRow calcRow, boolean isPosted) throws DataSetException { } Substitute the name of your data set. (21029) * If the drop-down list of target columns in the editor for Column's pickList property is empty, close the editor and try again. After you define the picklist successfully, its value may appear as "" in the property inspector. If you toggle to source, you will see that the code to set the property was written correctly. If you make any change to the source and return to the Designer, the definition will be displayed in the inspector and the property editor. (21066) * A lookup column is sorted by its actual values, not by their displayed lookup values. (20515) * Be sure to explicitly call the closeConnection() method of your Database objects when you are through with them or you will leave orphaned JDBC connections on your server. * If you get the error message "No suitable driver" when testing the database connection in the Inspector, and your URL is specified correctly, it could mean that a library does not point to the class files for that driver. Create a new library that points to the driver classes and add it to your project. Additional connectivity troubleshooting information is available in online Help. Look under Troubleshooting JDBC Connections in Developing Database Applications. * Providing problem: Query is read-only, even though the table on the server has a unique row id. When you try to modify the data set, you get a message that reports: "Cannot be saved. None of its updatable columns have a table name." This may mean that the driver does not support one or more of the MetaData functions used by JBCL. The solution is to provide some metadata manually. For more information on MetaData, please refer to the MetaDataUpdate, property entry in the Index of the Help System and "Working with Columns" topic in Developing Database Applications. * To make a query updatable: - If UpdateMode is ALL_COLUMNS (default), set tableName on QueryDataSet. - If the application has a QueryResolver, and UpdateMode is KEY_COLUMNS, set rowId on the columns used as an index to the table. - If you have a BLOB column, set the searchable property to false. Never use this column in a WHERE clause of an update query. Most databases don't support this for BLOBs. * The borland.samples.dx.entities.ServerOrderEntryModule.java file needs a modification to work properly. Replace all references to "DebugQueryProvider" with "QueryProvider". * While troubleshooting resolution problems, keep in mind that it is not necessarily columns that you have edited that are causing an error. For instance, the problem might stem from columns which are included in the WHERE clause of the update query. * If you get a message that no rows were affected by the update query, it could mean that someone modified the original row, causing the WHERE clause to fail. Use QueryDataSet.refetchRow() to get the original row from the server. If the original row has not been modified, here are some other possible causes. Columns of certain data types and fields that are calculated on the server could cause the comparison in the WHERE clause of the update query to fail. You could run into this problem if these conditions are true: - Column is of an imprecise data type (such as float or doubles). - Column is a fixed length string (some drivers don't pad strings with blanks, which leads to failures in comparison). - Column is calculated on the server, and successive saveChanges calls (without an intervening refresh) are made. There are two possible solutions: - In the MetaDataUpdate property editor, uncheck "Searchable", and set the searchable property of the column in question to false, so that the column is not included in the WHERE clause of the update query. - Add a QueryResolver to the application, and set UpdateMode on the QueryResolver to KEY_COLUMNS. This is done by instantiating a QueryResolver component, and setting the resolver property of the QueryDataSet to that QueryResolver. * Problem: You get error messages from the server that are not due to constraint or integrity violations -- the text of the message will vary from server to server. Possible Explanation 1: You have manually added a calculated field in your application which is being included in the update query (in the SET and/or WHERE clauses), and this is causing the resolution to fail. Workaround: Set the resolvable property of the column to false. This prevents JBuilder from trying to resolve changes to this column back to the server. Note: To prevent unwanted edits to columns, set the editable property to false for that column. Possible Explanation 2: Your driver does not support prefixing field names with table names (for example, testtable.column1). The workaround is to set useTableName in the database to false. Possible Explanation 3: MetaDataUpdate has been set to NONE, but searchable has not been set to false for BLOB columns. In this case the workaround is to set the searchable property to false. See the "Providing problem" in text above for more details. * Default value for a boolean columns doesn't work when set as a String. The workaround is to use setDefaultValue() instead. (20602) K. Wizards ---------- * Be sure to add any .properties, .txt, and .schema files you wish to deploy to your project so that they can be seen by the Deployment Wizard. Note that you may first need to use Tools|Treat As Text in order to view those files in your project. * The Deployment Wizard does not see the child nodes created for stubs and skeletons or other generated files. The workaround is to add the files to the deployment set from the second page of the Wizard. (14760) * The Deployment Wizard creates the manifest files for JAR archives in the Windows TEMP directory. These are not automatically removed. While JBuilder is not loaded, delete the manifest (.mf) files. (19232) * The Deployment Wizard does not traverse project folders to find manifest files. The workaround is to have manifest files at the top level in the project. (16968) * The CORBA Server Wizard fails to create code if no package is specified. (20454) L. Debugger ----------- * When debugging applications hosted on a JDK other than Java 2 or JDK 1.1.6_Borland, or when remote debugging, the debugger uses the JWatch debugger. In those cases, a debug console window is not available. * When the debugger is using JWatch to debug applications, by default, the IDE shows all threads being debugged. If user sets it to show a single thread only, debugger performance will improve. To display a single thread, right-click in the Stack and Thread pane after starting debug. Select Current Thread within the Context Information Choices and click OK. * It is possible to have more than one runnable process in a single Project (for example, a Client and a Server). Breakpoints are stored separately for each runnable process. When a process is selected as the Current Process to Run/Debug, the breakpoints for that process will become visible. Therefore, when setting breakpoints, you must first select the runnable process. This is done from the right click menu on a node in the Navigation pane. * Be sure the root class you are debugging is directly parented to the project as opposed to a child of a package node. Initiating debug sessions on files that appear under package nodes which are not directly parented to the project can confuse the debugger. Debugging into nodes that are in packages is fine - only the main(...) class needs to be under the project. * When remote debugging, adding the following code to the beginning of the main() of the program to be debugged remotely, will aid the IDE in waiting until the debug server becomes available: try { Thread.sleep(2000); } catch(Exception e) {} * Terminating applications being debugged from within the application may cause a General Protection Fault in certain situations with JDK 1.1.7. The workaround is to terminate the application by pressing the STOP button, or use a later JDK, such as JDK 1.1.8. * When debugging using Java 2 that has had HotSpot added to it, JBuilder will default to using the Classic VM (using the -classic switch). * When debugging an applet, you must have a breakpoint set or the applet will run without stopping in debug mode. (20723) * In the Evaluate/Modify dialog, a divide by zero operation crashes JBuilder due to a bug in Java 2. The bug has been fixed in JDK 1.2.2. (20768) * Due to problems debugging applications hosted on a JDK earlier than 1.1.8, for debugging applications hosted on a JDK prior to Java 2, e recommend using JDK 1.1.6_Borland or JDK 1.1.8 or higher. (21101) * When debugging an application hosted on JDK 1.1.7B, due to a bug in that JDK, stepping over a method call when an exception is caught by some method called by that method, will cause the debugger to stop execution and will incorrectly place the execution point in the last line of the try (not the first line of the catch). (21089) * When debugging under JDK 1.2 with a version of the JDK that has had HotSpot installed, JBuilder will default to debugging under the classic VM (-classic) mode. (20984) * After debugging more than one process in a project, when you close the application be sure the default run/debug process in the project corresponds to that application. You can do this by: 1. Selecting the debug tab for this application before closing it, or 2. In the project tab, selecting this application as the default run/debug process. (21178) * By default, static variables are not displayed in the Data Pane. To view static variables, right-click on the Data Pane, select Properties and then select all statics in the properties dialog. (21174) Improve Debugger Performance ---------------------------- * The following steps may help improve the debugger performance under JWatch: 1. Set Stack/Thread Pane Properties to show a single thread only. By default, all theads are displayed. To display a single thread, right-click in the Stack/Thread pane after starting debug. Select Properties then select Current Thread within the Context Information Choices and click OK. 2. Where possible, Collapse the expanded object node in the Data Pane after viewing. 3. On slower machines, you can turn off 'Display Context Information' to display only explicitly 'watched' variables. To not display context information, right-click in the Data pane after starting debug and select 'properties'. Select 'Display Data Watches Only' within the 'Type of Context Tree' Choices and click OK. M. Code Insight --------------- * For performance reasons, if you have a machine slower than 166mhz, you may want to turn off all of the Code Insight checkboxes on the Code Insight tab of the Tools | Environment Options dialog. You can still use Code Insight, but it will be on-demand (by pressing the hotkeys Ctrl+Space, Ctrl+Shift+Space, or Ctrl+Alt+Space). The performance when pressing these keys will be less for someone using "Background Research" but you won't have slower performance in other places. Using "Auto-Code Completion" and "Auto-Parameter List" without "Background Research" is not recommended, so turn these off. "Syntax Highlight Declaration Errors" won't work without "Background Research". N. IDE ------ * Change from JBuilder 2.01: in order to support debugging multiple processes within a single project when you open or create a project, JBuilder now sets the default runnable file. If the project does not contain a .java file it will set an .html file as the default. After adding a .java file that contains a main() function, if you select that file in the navigation pane, it will correctly be invoked from the Run menu choice. If you set a file as the default runnable file via the right-click menu or on the Run/Debug tab of the Project Properties dialog, then that setting will be saved with the project. * Due to a problem with modal dialogs restoring focus in JDK 1.2, JBuilder's main window sometimes becomes obscured by other desktop windows after closing certain dialogs such as the File | New... or Tools | Tool Options... dialogs. Use Alt+Tab to restore focus to JBuilder. * To save a read-only project, you must write-enable the project through the Windows Explorer by right-clicking on the .jpr file and selecting Properties. (18832) * To copy errors / messages from the message view in JBuilder, select the message view window and press Ctrl+Shift+Ins to copy the visible nodes in the tree. * If you have installed HotSpot to a version of JDK 1.2 and are using that JDK in a project, at runtime you will always be using HotSpot. HotSpot requires that the -classic flag for disabling the HotSpot JIT be the very first argument and that conflicts with how JBuilder builds the command line at runtime. If you have installed HotSpot but do not want to run with it from the IDE, the simplest workaround is to temporarily rename your hotspot directory. This will prevent the automatic detection and use of HotSpot by the JVM. (20957) * Projects dependent on nodes that generate an IIOP interface need to have that node(s) built first before building the entire project. (18062) * If you want to change JDKs you must delete all your generated dependency files in .\jbuilder\dependencies, but not the dependency files in the output directory. (20776) * File types which the IDE does not recognize will be opened as text files. (21057) * Under certain circumstances, the dependency checker may not be able to compile code that accesses a field of an inner classes that is declared later in the source file. In such cases, moving the definition of the inner class before using it will solve the problem. (20552) O. Windows 95/98 ---------------- * On some Windows 95 and Windows 98 machines with DirectX installed, there are painting problems in the Java portions of the JBuilder IDE. "Black out" of the icons on the component palette as the mouse passes over it, incorrect highlight when selecting text in JFC components and working with selection, expansion or drag and drop in JTree items (such as the structure pane in the Designer or the Deployment Wizard) are a few examples of where this problem may occur. The workaround is to rename the Direct Draw file ddraw.dll. Note: This is a problem that can happen with Java2 applications deployed to these platforms. (16860) * On Windows 95, the Debugger requires the latest OLE32 in-process server from MicroSoft. You can download the files from: http://www.microsoft.com/com/dcom/dcom95/dcom1_3.asp. * On Windows 95, you can only debug one process at a time. * When running JBuilder 3 on Windows 95 Gold, the toolbar icons do not paint correctly. Microsoft's "Windows 95 Year 2000 Update" fixes this problem. It is downloadable from: http://www.microsoft.com/windows95/downloads/ * When running VisiBroker Smart Agent, if your system is unable to find MSVCRT40.DLL, you can get the file from Microsoft's "Windows 95 Year 2000 Update". It is downloadable from: http://www.microsoft.com/windows95/downloads/ P. Help System -------------- * Due to Java 2 printing problems, the Help Viewer cannot print images cleanly. Image printing is turned off by default. To turn on image printing, change the printImage=0 setting in \jbuilder3\doc\help.properties to printImage=1. (19844) ------------------------------- SECTION 2. International Issues ------------------------------- A. Install and Environment -------------------------- * Due to JDK limitations, installation into a directory path containing non-ASCII characters is not supported. (3235) * Under Japanese Windows 95 (950) the IDE tools button bar appears without images. Occurs under both SVGA and XGA resolution. (20777) B. Compiler ----------- 1. Native encoded source files * By default the compiler uses the encoding appropriate for your environment. The JDK convention is to assume 8859_1 for most Windows environments (Cp1252). If you use Cp1252 characters within the range of x7F through x9F, then you should explicitly set the encoding to be Cp1252. (5882) To select the encoding used by the compiler, choose the Project | Properties menu item, then choose the Compiler page in the Tools menu. Select the encoding from the list provided. For the command line compiler, use the -encoding option. 2. Local characters in Identifier names * You can use local characters, including multi-byte characters, in identifier names. However, due to a JDK limitation, you can only use ASCII characters in class and package names. Therefore it is suggested that only ASCII characters be used as component names. This is because any event handler classes will use the component name. (6362) 3. Non-English versions of JBuilder * Non-English versions of JBuilder display compiler messages in the same language as JBuilder's IDE. If you prefer to have these messages displayed in English, rename or move the file, \lib\bcj_nn.properties, where the 'nn' is actually the language code that matches the setting for your operating system. For example, bcj_fr.properties for French, bcj_ja.properties for Japanese, and bcj_de.properties for German. Then restart JBuilder. This affects compiler messages displayed in the IDE as well as at the command line when using bcj.exe and bmj.exe. Messages displayed by javac.exe will always be in English. (17267) 4. Long lines truncated from text resource files * At compile time, text resources in projects (such as *.properties files) are copied to the output path for use when running the compiled project. Lines longer than 1024 characters will be truncated. Files that use many unicode escape sequences, \uNNNN, are particularly susceptible since each character displayed in a GUI requires 6 characters when expressed in the \uNNNN format of the text file. As a workaround, use the continuation character ('\') to break long lines in property files. Files in the Multilingual sample demonstrate this (such as \samples\com\borland\samples\intl\gui\resources\TextRes_ja.properties). (14252) 5. Supported -encoding The default (fast) compiler only supports a limited number of native encodings. An optional (slow) compiler supports all JDK 1.2 encodings. To setup and run the optional compiler from the command line: SETVARS SET CLASSPATH=\LIB\JBUILDER.ZIP;%CLASSPATH% JAVA com.borland.compiler.frontend.Make -encoding (18778) C. Visual Design Tools ---------------------- * When naming components with international characters, see the note regarding event handlers under the section above, "B.2. Local characters in Identifier names:". * When using the IME to enter DBCS characters into the Inspector, you should use the keyboard. Using the mouse can result in the characters not being entered properly. (5465) * There is a JDK limitation when creating localized applications whose menu commands have shortcuts such as Ctrl+S. For example, under a German locale, the shortcut should appear in the menu as Strg+S, but will always be listed as Ctrl+S. (6955) * Using a French keyboard to enter exclamation mark '!' or section mark '' into AWT components will only display question mark '?' under JDK 1.2. Swing components do not have this problem. (JDK)(17722) D. dbSwing, Swing, and JBCL Components -------------------------------------- * Swing components do not correctly display Traditional Chinese in Win95. Under Pan Chinese WinNT display is correct. (18357) E. Database ----------- 1. Schema file for TextDataFile * When multi-byte field names are desired, you will need to use Unicode for the column names. You can first create your text file in the native encoding format and then use the command-line command Native2Ascii, a tool included with the JDK, to convert the file to Unicode. This command is explained in the JDK documentation. 2. Text file for TextDataFile * When importing a text file with native encoding you must specify the encoding in the schema file. For example, if you are trying to import a file containing SJIS characters, you must change your encoding in the schema file from 8859_1 to SJIS. 3. Japanese Currency Values * Due to a JDK limitation, there are problems with entering values into fields of type currency in a Japanese locale. The workaround is to explicitly specify an edit mask for the field. (JDK)(11795) 4. JdbcOdbc workaround for DBCS support * When using the JdbcOdbc driver from Sun, an SQL command that contains a DBCS table or field name will not execute correctly. Also, any SQL command that returns DBCS (or other) data which have Unicode character codes with second byte equal to 00h will result in truncated data in the resulting query. A workaround is provided for your convenience. To workaround this JDK bug: 1. Uncomment the following line in JBuilder.ini: ;Xbootclasspath/p:..\java\lib\DBCSpatch.jar= 2. From JBuilder. Add the following to: Project | Default Properties | Run/Debug Options | Java VM Parameters -Xbootclasspath/p:\jbuilder3\java\lib\DBCSpatch.jar Note that the DBCSpatch.jar file is NOT redistributable. (17350,17351,19758, Javasoft #4215746) F. JDataStore ------------ * This version of JBuilder does not support the use of non-ASCII characters in DataStore directories and file names. (13413, 13415) G. CORBA -------- * When compiling an IDL file with idl2java, where the file contains non-ASCII characters in identifier names, an exception is thrown. This is because non-ASCII characters are not officially supported in identifier names according to the CORBA 2.0 spec. (11241) * The ORB Explorer Import feature or the IDL2JAVA compiler may report errors when unicode escape sequences are contained in #pragma hint lines which are very long (>128 characters). (19435,19437,20319) * When an IDL file with Unicode escape sequences is imported to, then exported from, the Interface Repository (IREP), the resulting IDL will contain extra "u" characters in the escape sequence. (20235) /------------------------------- END OF FILE ----------------------------------/