Symantec Top 10

By Michael Hopkins and Noah Liebermann

Q: When I compile the Animator Sample Applet using Symantec Caffeine, I get the error, “The last command could not be completed because the apple event was not handled.” Why is this occurring?

A: You need to be sure that you have the Javac.PPC application running before you compile. For further information, read the Your First Applet.pdf Acrobat file.

Q: When I have compiled my Java project, why can’t I choose Run from the Project menu?

A: Symantec Caffeine does not currently support building stand-alone applications. You can currently build only applets, which must be viewed as part of an HTML file. You can use any Java-enabled browser to view them, or use AppletView.PPC, which is included in the MacJDK folder. Once your applet is compiled, you can choose Run Applet (example1.html) from the Scripts menu, or use the shortcut Apple-control-R to run the applet with AppletView.PPC.

Q: The installation instructions for Symantec Caffeine say I need something called “8.0.4d11” to use the Java compiler. What file is this referring to?

A: This file is the version of the Project Manager required by Caffeine. You can find it in the pre-release folder on the Symantec C++ release 4 CD. The Project Manager on the Release 5 CD is already set up to use Java, so no additional configuration should be necessary.

Q: I cannot compile the GraphicsTest demo in the Sample Applets folder. How do I get this sample to compile?

A: Files that are mutually dependent and do not include package specifications will not compile properly, because the environment passes these .java files to the Java compiler independently. The work-around is to manually drag all of the files from the Finder onto the Javac compiler to generate the .class file. See the READ ME!-Known Issues file for information on this and other problems.

Q: I am compiling a Java project, but I cannot figure out where the resulting .class file is being saved. Am I doing something wrong?

A: No. When you build a Java project, the .java source files are compiled by the Javac compiler and the resulting applet is placed in Javac.PPC’s target folder. The default folder is classes. With this setting, all resulting .class applet files are placed in the JDK Classes folder, which is called Caffeine:MacJDK1.0b1:Classes. Alternatively, you can specify the paths for classes and the target by launching Javac.PPC and choosing Properties from the File menu. Note that the classes path should be the location of the sun and java folders containing the JDK library classes.

Q: I am trying to use the cursor routines documented in Inside Macintosh: Imaging with QuickDraw. I have added CursorCtl.h, but I still get a link error. Can I use this routine with Symantec C++ 8.0?

A: Yes. This routine is supported by our PPC product. To use these calls, add PPCToolLibs.o and StdCLib to your project.

Q: Is there a way to get the frame of a window? I tried looking at the portRect, but that is the interior of a window. Can I get the rectangle that includes the title bar and any other window parts outside of the portRect?

A: Yes. There is a struct element called the rgnBBox that can be accessed by type-casting the WindowPtr to a WindowPeek. The following example demonstrates how to access this data:

 WindowPtrmyWindow;// must point to valid window
 RgnHandlewindowRgnHandl; // local copy of handle
 Rect   totalWindRect;    // receives total area of window

    // set up the handle to the structRgn
 windowRgnHandle =
 (Handle)(((WindowPeek)theWindow)->structRgn);
    // lock the handle since we are ready to access it
 HLock(windowRgnHandle);
    // get the rectangle for the entire window
 totalWindRect = (**(RgnHandle)windowRgnHandle).rgnBBox;
    // unlock the handle, we are done with it
 HUnlock( windowRgnHandle );

Q: I am using the Think Class Library and Visual Architect to create a dialog box. When I run the generated application, I notice that the tab order for the CDialogText items is not correct. Is there any way to change the tab order without re-creating my dialog box?

A: Yes. Tab order is determined by the item numbers of the text boxes. For example, if you have three text items numbered 2, 7, and 3, pressing Tab in the first edit box (number 2) will cause the cursor to jump to the last edit box (number 3). To display the item numbers, choose Show Item Numbers from the Views menu. You can change the tab order of CDialogText items in Visual Architect by selecting each item individually and choosing Send To Back and Bring To Front from the Pane menu. Bring To Front will increase the item number and Send To Back decreases the item number.

Q: When I click in the go-away (close) box in my VA-generated CWindow, I do not receive a cmdClose message like I do when I use the Menu option Close or hit Apple-W. Why does the close box not generate a cmdClose that I can trap, and how can I override this mysterious TCL shortcut?

A: The window’s close box circumvents the cmdClose command path that is normally issued after the Close menu option is chosen. The close box issues a CWindow::UserClose() command, which calls CWindow::Close(), which finally calls CDirector::Close(), at which point your close click disappears into the forbidding domain of CDirector, having completely circumvented the command structure of the TCL.

Overriding this is fairly straightforward. In the Visual Architect, create a new class in the Classes dialog window. Call it what you like; TmyWindow would be a good choice. Select CWindow from the Base Class popup menu, and close the Classes dialogue window. From the main VA window, open your window, or create one if you do not already have one. Select View Info from the View menu. Now select your newly created derived class from the Window Class pop-up menu.

Once you generate your source code, you need to add a prototype in your header file and then go into the source file for your derived class and add the following:

void    TmyWindow::Close()
{
    // Add your own supplementary Close handling routines here

    inherited::Close(); // Call the inherited method 
    // to finally close the window
}

Now when the close box is clicked, your Close method will get called, wherein you can add whatever housekeeping functionality you like.

Q: I am using TCL and the Visual Architect to write my application. I have created a modal dialog box with a button that sends a cmdQuit. When I run the generated application, clicking the button seems to do nothing. In fact, I seem to go into some kind of infinite loop and I have to force my application to quit. What is going on?

A: First of all, it is considered bad form to quit an application by clicking a button. That behavior is reserved for the Quit item in the File menu. If, for some reason, you really want this behavior, you will need to do the following.

Go into your upper level source for that dialog, and add the following class definition:

class myChore: public CChore
{
 public:
 myChore(){}
 virtual void Perform( long *maxSleep )
 {gApplication->Quit();}
};

 Now, modify the DoCommand function:

myDialog::DoCommand( long theCommand )
{
 myChore *theChore = new myChore();

 switch ( theCommand )
 {
 case cmdQuit:
 Close( true );  
 gApplication->AssignIdleChore( theChore );
 break;
 default:
 x_myDialog::DoCommand( theCommand );
 }
}

By setting up an idle chore, we ensure that the dialog has a chance to close before the application quits.

Special thanks to: Mark Baldwin, Levi Brown, Andrew McFarland, and Scott Morison.