| Volume Number: | 10 | |
| Issue Number: | 8 | |
| Column Tag: | Think Top 10 |
Think Top 10 
By Symantec’s Technical Support Team
This is a monthly column written by Symantec’s Technical Support Engineers intended to provide you with information on Symantec products. Each month we cover either a specific application of tools or a “Q&A” list.
Q. Can SourceServer be used successfully with a Visual Architect project?
A. It can. However, Visual Architect is not currently SourceServer “savvy” . Here are some guidelines for a peaceful coexistence between the two:
Rule #1: Check out necessary Visual Architect files BEFORE Generating. Since VA does NOT honor SourceServer’s 'ckid' resources, it will go ahead and overwrite files that have been checked out as read-only. So before you Generate from Visual Archtitect, make sure you’ve checked out any files that will be modified, otherwise you WON’T to be able to check the revisions back in. This goes for the Visual Architect.rsrc file, as well.
Rule #2: Close the Visual Architect.rsrc file before checking it in or out. A Visual Archtiect.rsrc file’s 'ckid' resource that is modified by SourceServer while the file is open will NOT be saved when the file is closed. The file won’t be able to be checked in or out after this.
If you forget to follow either of these rules, you may be able to set things right again by issuing the appropriate OrphanFiles, Undo Checkout, or DeleteRevisions commands. But this is not fun.
Strong Suggestion: Set up nested ProjectorDB’s to separate Generate-Once and Generate-Many and non-Visual Architect files.
Currently VA is rather inflexible about where it puts its generated files. You get exactly one choice: all go in a folder named “Source” in your project folder, and sub-folders are ignored. You can, however, use nested ProjectorDB’s to bring some order to this ungainly group of files, and at the same time avoid the performance hit which would be incurred from storing all those files in the same ProjectorDB.
The key difference among the files in the VA “Source” folder is whether they are generate-once or generate-many. For the most part, this means lower-layer versus upper-layer files, but it’s important to be aware that a number of other files, such as References.cp and the <class>Items.h files, are also generate-many. Since you’ll have to check out some, if not all, generate-many files each time you Generate, and then check them back in, it makes sense to group these files into a sub-project (“VA Regenerated Files”, for instance). Note that your VA.rsrc file should also be checked into this sub-project. The rest of the files in the “Source” folder will go in another sub-project (call it “VA One-Time Files”), and finally your non-VA files could go either into the top-level project, or into a sub-project (or sub-projects) of their own. That’s the basic idea!
Q. How do I get started converting my TCL 1.1.3 project to use the new TCL 2.0?
A. The file “Converting To TCL 2.0.doc” in the “Supplementary Info.Π” located in the TCL Folder contains an extensive list of issues you will face getting your source to compile and run under the new TCL. The most important first step, however, is to start with a fresh, working TCL 2.0 “Hello World” project and add your source to it, rather than trying to coax your existing project document into using the new TCL.
Follow these steps:
1. To convert your old TCL 1.1.3 project, create a new project and choose Visual Architect for the project model. (Version 7.0 now offers you a list of project models to choose from when creating a new project.)
2. Since you are converting an old TCL project and will probably not be using Visual Architect at the moment, remove the “Visual Architect.rsrc” file from the first segment of the project. A file called “Project Resources.rsrc”, located in its own segment, will also be created. This file contains essential TCL resources, some of which may be the same or similar to ones used by your original TCL project. You will have to determine which, if any, of your original resources you need to keep.
3. Add your sources into the last segment named “Application”.
Q. My Visual Architect application is dying in the debugger on a call to TCLGetWindow. It says it doesn’t know the type of my CWindow.
A. Every object instantiated by TCLGetWindow must be declared in a TCL_FORCE_REFERENCE() macro in your application’s ForceClassReferences() override. VA does this automatically for classes it knows about, but when you use your own classes in VA-generated code, you have to do it by hand. The usual suspects are CWindow (or CDialog), CScrollPane, CPanorama, etc. Or, check out the References.cp file generated by VA, which forces references to many standard TCL classes. Include this file in your project, and you’ll only have to worry about references to your own derived classes.
Q. What is the correct way of managing more than one document window?
A. The correct way is to create directors supervised by the document (or “main director”) for the second and additional windows.
Q. What happened to CObject in TCL 2.0.x?
A. This version of TCL is no longer rooted to a single CObject class. In fact, CObject no longer exist and must be removed from your own class hierarchy. The following classes can be used as root classes instead: CChore, CCollaborator, CTask, CStream, and CString. If you have added any functionality to CObject, they must be implemented elsewhere.
Q. How can I add persistence to my classes generated by Visual Architect?
A. At a minimum, you just define PutTo() and GetFrom() member functions for your class and - because Object I/O uses templates to get and put objects - expand the PutObject() and GetObject() functions in a file like CStream_CBitMap.cpp. (You don’t always have to do the latter; just for root classes.) For a more detailed discussion, look at the “Using CSaver.doc” in the “Supplementary Info.Π” located in the TCL Folder.
Q. Is it possible to test compiler options such as structure alignment during runtime in my C++ program?
A. Yes, you can with version 7.0.2 of the C++ compiler. A new feature in Symantec C++ 7.0.2 is being able to test and set various compiler options during run time as in Think C. Here’s how to do it:
/* 1 */ #if __option(xxx)// Returns TRUE if option xxx is on #pragma options(xxx,!yyy) // Turns option xxx on and option yyy off
The options are listed in a README file called “Compiler pragma options.”
Q. How do I call a code resource from my C++ program?
A. Here’s a small program (in C++) which calls a code resource. For this example the code resource takes 2 arguments, an int and a character pointer. It assumes that the resource has been merged into the project’s .rsrc with type CODE and name myCodeResource.
/* 2 */
/* UsesCodeResource.cpp */
#include <stdio.h>
extern "C" typedef void (*CRPtr) (int, char*);
void main()
{
char myString[20];
Handle myCRhandle;
myCRhandle = GetNamedResource('CODE',"\pmyCodeResource");
HLock(myCRhandle);
(* (CRPtr) (*myCRhandle)) (5,myString);
HUnlock(myCRhandle);
printf("myString=\"%s\"\n",myString);
}
Q. THINK Inspector doesn’t seem to be showing me all the objects created in my program. Why not?
A. The Think Inspector will only display objects created from the heap. Objects created from the stack will not show up. For example,
/* 3 */ CMyClassmyObject;//will not show up CMyClass*myObjectPtr = TCL_NEW(CMyClass, (args)); //will show up
Q. Are there any issues with running Symantec C++ for Macintosh on my Power Mac?
A. Symantec C++ for Macintosh 7.0 runs emulated on the PowerMac without problem. If you’re still running version 6.x, make sure you turn OFF the Modern Memory Manager.
