You can add an item to the BX Toolbar in the Main Window by holding the Shift key when you select a menu entry. You can remove an item from a Toolbar by holding the Shift key when you select either the Toolbar item or the item's corresponding menu entry.
By default, a Delete Confirmation dialog is displayed when you attempt to delete an object. To unset Delete Confirmation, select User Preferences from the Main Window Options menu, click on the Behavior tab, and unselect the Confirm Delete Actions toggle.
To quickly populate a menu, use the Keep Parent option from the Main Window’s View menu. Select the Pulldown Menu you want to populate and set Keep Parent. Then to add children to this menu, just double-click on the desired widget in the Palette.
If you have selected an object on the palette you did not intend to select, simply press the Escape key OR press the MB2.
To save screen space, you can selectively hide shells you are not using. To hide a shell, click on a selected shell name in the Browser Instance or Class list on the left of the Main Window. The shell name is unselected and the shell is hidden.
Note: This does not effect whether the shell is managed, and so visible, when you generate code. See question on "How do I gain control over the display of these Dialog boxes?" if you are trying to control when a particular shell is visible in the actual application.
Constraint resources are always grouped together at the bottom of the Resource Editor.
By default, any object you create in BX is automatically visible. You can hide objects in your interface by selecting one or more and choosing the Hide option from the Resource Editor Component menu. You would commonly do this to Dialog boxes that would popup under control of the applications that you do not want visible at startup. "Hidden" objects will not appear until your application specifically "manages" them.
Note: Although the "Hide" option will have the side effect of cleaning up screen clutter, it performs a much different function. If you just want to cleanup screen clutter, see the question on "Can I set BX to only display the shells I am currently working on?".
To save screen space, you can click on a Palette collection folder icon to close the folder. For example, if you are tailoring a particular shell and have already laid out the containers, you might want to collapse the Motif Containers to eliminate the need for scroll bars on the Palette. This would provide easier access to the widgets that you need to complete your user interface.
Depending on what you are trying to accomplish, there are several approaches here. The first approach is to select each widget in the Browser or in the application window and enter the resource value as you would for a single widget. Each selected widget will be updated with the new value. The second approach uses the Builder Xcessory feature of Styles. Styles are groups of resources that can be applied to widgets or widget hierarchies. You would use the first approach if you were just setting these resources for a specific situation. You would use Styles if you wanted to create an overhaul consistent Look-and-Feel to your application. Some practical applications of Styles are provided in Tutorial 5.
Whenever you change a value in the Resource Editor, it requires that the change be confirmed by clicking the checkmark to the right of the entry field. It is very common for users to type in a new value and then forget to hit the "checkmark" to the right of most text fields in the Resource Editor. You loose your changes if you forget to click on the checkbox or click on the Enter key to apply your changes.
Select both objects in the Browser using the Shift-MB1 combination. In the resource editor, select the icon in the resource editor toolbar (by default, it is the circle on the far right) that displays only resources that are not equal. The list of resources that are different will then appear below.
SGI’s RapidApp was originally based on Builder Xcessory Version 3 source code. Consequently, RapidApp and Builder Xcessory share many of the same approaches to GUI development. And when SGI took RapidApp to End of Life, Builder Xcessory was given the nod as the official SGI recommended upgrade path for RapidApp users.
The actual process of converting involves the running of a converter on the RapidApp save file. This converter only supports RapidApp save files that were created using RapidApp 1.2+. The converter is written in Python, allowing users to extend and modify it as necessary to address any unique needs of their RapidApp user interface.
Builder Xcessory can directly read in the user interface save file created by VUIT. As with SGI and RapidApp, Builder Xcessory is the officially recommended upgrade path for VUIT users.
Yes. Builder Xcessory on UNIX workstations (Sun, HP, etc.) has an "import GIL" option under the File menu. The Linux version of BX doesn’t provide this capability. However, we would be happy to issue you a short term license for BX on Sun, etc. so that you can make the conversion and then import the converted UIL into Builder Xcessory on Linux.
Prior to Motif, Sun developed and distributed the Xview toolkit. Today, few developers use Xview and Motif is the dominant commercial user interface toolkit on Linux and UNIX systems. If your XView-based user interface was built with Sun's DevGuide GUI Builder, ICS offers a direct migration path. (See question that follows). If your GUI was not build with DevGuide, or the DevGuide save files (GIL) are no longer available, there is still an alternative. ICS has a tool that can recreate GIL files from applications built with Xview. Ask your ICS representatives for details or email info@ics.com.
Engineering work is underway to allow the conversion of the UIM/X save file formats (.uil and .i) to a format that can be imported by Builder Xcessory. Ask your ICS representatives for details or email info@ics.com.
If your old GUI Motif GUI builder can export files in UIL, BX can import them. This will preserve the raw user interface. At this point you will need to complete the conversion by using BX to add callbacks, setting form attachments, etc.
ICS offers BX/WIN SDK as the preferred solution to a Windows deployment. BX/WIN SDK includes a complete UNIX development environment that runs on Windows. It also includes copies of Motif and ported versions of ICS’ ViewKit and EnhancementPak libraries. BX/WIN SDK provides a proven solution for the migration of large applications to Windows.
Generally the answer is yes. However, there are two exceptions. 1) If you used ViewKit and/or EnhancementPak in your user interface, you must also have these libraries available on your new platform. 2) There can be slight differences in Motif from vendor to vendor. Please allow time for you to debug any subtle differences.
BX 3.x is upwards compatible with BX 4, which is upwards compatible with BX 5, etc. This means that files save by BX 3.x can be read into BX 4 and BX 5 can read BX 4 save files. You cannot "jump" a level (i.e. have BX 6 directly read in BX 4 based saved files. If you are migrating from an older release, contact your ICS representative and we can arrange for temporary access to the releases you need.
- 1. When you run install script ./setup make sure you select the same directory that has previous version of BX 6.1.x. For example, if you have BX 6.1.x installed in /opt/bxpro-6.1/ then select the same directory for installing BX 6.1.3.
- 2. Once BX 6.1.3 is installed successfully, go to /opt/bxpro-6.1/xcessory/packages/ directory. You should still find .cat files for the extra widget libraries.
- 3. Open the file, default.cat in an editor. Introduce new lines of Include cat files for all .cat files identified in step 2. Save and close the editor.
This will get you going with extra widget libraries integration in BX 6.1.3.
Builder Xcessory does not have an immediate UNDO. However, The Revert... option from the Main Window’s Edit menu allows you to reload your work from the last saved version of your file or from the last autosaved version of the file.
Some widgets that appear as a single object on the Palette are actually Compound Objects that are made up of several Motif widgets. For example, the XmMessageBox is a compound object made up 6 child objects. You can toggle whether Compound Objects are expanded or not in the Browser by setting/unsetting the toggle "Show Compound Children" under the View menu of the Main Window. For example, if you did not want an "OK" button, a "Cancel" button, and a "Help" button, you could select "Show Compound Children" and then delete one or more buttons.
If you have installed extra libraries from ICS, such as ViewKit or EPak, they are installed by default in ${BXHOME}/lib. To use these libraries in your programs just add a link line in "Options->Code Generation Options->Makefile". Then choose "Save As Default".
There will come a time when modifying the generated code will be the most direct solution to a special function or need of your application. When you have to do this, just make sure that your modifications are placed within a user code block in the generated code. If you keep your code there, Builder Xcessory will automatically detect it, save it and restore it after you regenerate the code for your user interface. And if as the result of a change in your user interface, there is no reason for a particular user code block (and your hard written code!), BX will automatically save your code in a special file and make you aware of this by publishing a message in the Message area of the Main Window.
No. User code blocks require special handling in the BX code generation phase to preserve your changes. However, user code blocks have been a key BX feature for a long time, and we've taken input from many users over the years on their locations. It is likely that anything you would like to do, can be supported by an existing user code block. If you believe that you have some unique need, please send a description to support@ics.com. If we can't suggest how you can use an existing user code block, we'll consider adding it!
Many users are confused on how to connect their app-defaults file to their application. To get your application to pickup your app-defaults file, you need to take the following steps:
- Set the name for the app-defaults file in the File Names tab of the Main Window->Options->Code Generation Preferences.
- In the Application Tab of the Code Generation Preferences, make the Application Class match the name of the app-default file you set in #1.
- Set the
XUSERFILESEARCHPATH
to include the location of the app-defaults file. For example, the following shell command (or the equivalent one for your choice of shell) will set this variable correctly:%export XUSERFILESEARCHPATH=$XUSERFILESEARCHPATH:./%N%S
You can save time when reading in a large application by setting Delay Shell Realize. To set Delay Shell Realize, select User Preferences from the Browser Options menu, click on the Behavior tab, and select the Delay Shell Realize toggle. A shell will not be created until selected from the Instance list in the Browser.
If you want the fastest possible response to your support question, try to do ALL of the following:
- If you are not yet a customer, please send your questions through your ICS sales representative. If you are not sure who that might be, send email to sales@ics.com and the proper person will get in touch with you.
- If you are a customer and are having problems using an ICS product, send your support request to support@ics.com. Sending your support request to any other email address will only delay our response. DO NOT sending your support report to a specific person at ICS. If that person is on vacation or traveling for the day, the response to your problem could be delayed.
- Make sure that you receive an automated reply from ICS Support with a case number. Make a note of that case number and include it on all communications with ICS Support. If you do not immediately receive the automated acknowledgement to your support request, send email to the support manager.
- On any communication with ICS, make sure you put the case number between "["..."]" (e.g., [94271]) in the subject line. This will ensure that your email is logged into your case. Again, always reply to support@ics.com and not directly to a specific person. This allows multiple people to work on your case.
- Include with your initial support request, your Support Number. This was provided on your letter that accompanied your software. When you renew your support, you will also receive a letter with your support number. ICS Support will always ask for this support number before responding. If you do not know it, and you are using BX 6, send us your Media Serial Number. This will be the quickest mechanism to find your support number. This serial number is available via Help->Media Serial Number. If you are not using BX 6, tell ICS Support in your initial email that you cannot find your Support Number and they will research it. This can delay your response, so please write it down for future use when we find it!
- Depending on the problem attach one of the following files to your email:
-If this is a license problem, attach your license.dat file.
-If this is an installation problem, attach your install log file. It is in /tmp and looks like:IcsInstal-mm-dd-1yy.log
-If you are having a problem with the design of your user interface, make sure that you attach your UIL file.
-If you are having a runtime problem, reduce your code to a minimal case that demonstrates the error. - Include detailed step-by-step instructions on how to reproduce the error. Screen captures are also very helpful!
- Please include a description of your hardware/software environment. At a minimum, this description should specify hardware, operating system version, C++ compiler version. On Linux, you might want to describe the distribution, kernel version and release of glibc too. Network topology might also be relevant if you are experiencing a licensing failure and the license server is on another machine or if you are using a PC Xterm like Hummingbird.
- The smaller the test case that exhibits the problem the better! If we have to create our own test case, the response delay could be significant and we might never be able to duplicate your problem.
When using BX there is an issue that occurs regularly when using the XmForm container widget. As I place child widgets like textLabel or buttons or even another XmForm, I sometimes have trouble changing XY or width/height parameters in the Resource Editor. This forces me manually change the geometry on the screen by selecting and dragging things around to either change position or size. I prefer using the Resource Editor when I need to set very specific parameters values. Can you explain why I am getting this warning and if there is a work around.
Work around:
- By adding widgets to the XmForm, now the form will manage the position and geometry of its child widgets and their relative positions
- In order to change XY position of a widget within the XmForm, you change the left, right, top or bottom offset in resource editor. BX will not allow you to change XY or width/height in the resource editor directly.
- Be aware if a widget has attachment on the right and you are making changes to the leftOffset, this will change the width as the left side will be shifting while the right side is static.
- Alternatively, if there is no right attachment, changing leftOffset will shift the entire widget back and forth without affecting the width.
- Same behavior is true for top and bottom offset