Jun 96 Top 10
Volume Number: 12
Issue Number: 6
Column Tag: Symantec Top 10
Symantec Top 10 [TOKEN:61441]V
By Michael Hopkins and Noah Liebermann
Note: Source code files accompanying article are located on MacTech CD-ROM orsource code disks.
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
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:
WindowPtr myWindow; // must point to valid window
RgnHandle windowRgnHandl; // 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
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.