Aug 94 Top 10
Volume Number: | | 10
|
Issue Number: | | 8
|
Column Tag: | | Think Top 10
|
Think Top 10
By Symantecs Technical Support Team
This is a monthly column written by Symantecs 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 SourceServers '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 youve checked out any files that will be modified, otherwise you WONT 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 files 'ckid' resource that is modified by SourceServer while the file is open will NOT be saved when the file is closed. The file wont 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 ProjectorDBs 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 ProjectorDBs 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 its 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 youll 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. Thats 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 doesnt know the type of my CWindow.
A. Every object instantiated by TCLGetWindow must be declared in a TCL_FORCE_REFERENCE() macro in your applications 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 youll 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 dont 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. Heres 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. Heres 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 projects .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 doesnt 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 youre still running version 6.x, make sure you turn OFF the Modern Memory Manager.