Q: Regarding ANNOUNCE & REQUEST -- what was wrong with using the word EXTERNAL and what is the advantage of CA switching to the word REQUEST? A: [Don Caton:] The words "ANNOUNCE" and "REQUEST" more accurately describe what's happening. Too much of our terminology is vague or arcane, and I think it was a cool idea to implement these things. They can always clean up the underlying implementation without affecting the end result. ANNOUNCE declares a public symbol for a particular module. It's like a module saying "if you're looking for a bunch of code named xxx, here I am". It just gives an identifying name to a source code module (generally an .obj file) so that it can be pulled into your application even if none of the routines in that module are called directly (which would normally cause it to be linked in anyhow). Probably the main reason this was implemented is that INIT and EXIT procs generate private names so they're not visible to the linker, and some mechanism like this was necessary to instruct the linker to include them. ANNOUNCE/REQUEST allows modules like this to stay in libraries and still get linked instead of having to explicitly link them as obj files or use special linker instructions. This technique has been used internally in Clipper for some time. For example, when you compile with /b the compiler automatically includes something similar to a 'REQUEST _VDBG' in the generated obj file. Inside CLIPPER.LIB, there is a module named vdbg.obj which has the equivalent of an 'ANNOUNCE _VDBG' inside. The linker matches them up and, voila! This is how the debugger stuff gets pulled in automagically. The module vdbg.obj references other stuff that the debugger needs and it starts off a chain reaction which isn't complete until all the necessary modules are found by the linker. As you can see, the request for a single identifier can pull in a whole sybsystem. It's something that perhaps many Clipper programmers won't need to use, but if you're putting together your own code libraries, it's definitely something worth investigating. Q: But doesn't "REQUEST" do exactly the same thing "EXTERNAL" used to do? Also, isn't "EXTERNAL" used in Assembly and "EXTERN" used in C? Not to belabor the point, but I'm just curious as to why you think "REQUEST" more accurately describes what's happening. A: [Robert diFalco:] Yes, REQUEST is the same as EXTERNAL. However, EXTERNAL is just kind of a stupid name. When you do an "EXTERNAL DESCEND" what you really mean is "REQUEST DESCEND". Since we are getting into dynamic modules with Clipper with such things as RDD's and INIT/EXIT PROCEDUREs we needed a sane and readable way to deal with them without having the old "you must link this object file into the root". Therefore, with a third party product such as SuccessWare's DBFSix, for example, you would just add "REQUEST DBFSix" at the top of your main PRG file. ANNOUNCE allows you to create a REQUESTable module identifier for a module of routines. As Don, said, the implementation can always be changed but the decisions were correct. Here's an example of how to use it in a different way than described above. Say that you have three clients that all have the same essential code, code you put in a library for reuse. However, one of the three clients wants LOTUS style menus, one wants BOX menus and another wants Pull-Down menus. If all your menu subsystem protocols are the same, you would put each engine into a different .LIB with an OBJ ANNOUNCEing each type. Hence, you would solve your problem by simply adding this line to the top of "Client C"'s application: REQUEST PullDown // or LOTUSMENU or BOXMENU No this is a simple example and there may be other soloutions, but it should give you some ideas as to how to modularize dynamic code. For example, Client specific code could REQUEST a special ANNOUNCEd module specific to that Client. REQUEST clientXYZ [Don Caton:] I think "REQUEST" more accurately describes what's happening because the presence of that statement means that you are _requesting_ the named module to be linked into the application. Yes, it's exactly the same as the "extrn" declarator in assembly (in effect, but not in implementation), but it isn't the same as "extern" in C. The "extern" keyword in C is a modifier and means two different things: one, it's placed in front of a variable declaration to indicate that storage for the variable is declared somewhere else, i.e. "external" to the module the declaration appears in. It instructs the compiler not to generate any storage space for that variable in the module being compiled. The other use is as a modifier in a function prototype. In that context, "extern" indicates that the function body exists somewhere else; again, "external" to the current source module (this usage is superfluous). Neither of these uses of extern have any parallel in Clipper. The mere presence of a statement like 'extern int xyz;' does not generate a request for the symbol 'xyz', you actually have to reference 'xyz' somewhere in the code for the C compiler to generate an extdef for the symbol. Same with function prototypes declared as extern. If that was sufficient to pull in a symbol, just including an .H file with prototypes would drag in unnecessary code. There really isn't anything like Clipper's REQUEST in the C language. In C you have to do something like: extern int xyz; static void DoNothing( void ) { int dummy = xyz; } You would never call this routine but the compiler doesn't know that, and it causes whatever module that defines 'xyz' to be linked in. In the Obscure Trivia Dept., a routine exactly like the one above appears in some of Clipper's RDD modules in order to get their superclass RDD's dyn modules linked in (which, like Clipper's INIT/EXIT functions, are mostly invisible to the linker as well). There was no prior equivalent to ANNOUNCE in Clipper, although you could achieve the same result by declaring a function or procedure with the desired name and just don't put any code in it (which is exactly what ANNOUNCE does anyhow). Q: What do you mean by the term "dynamic modules"? Does that simply mean that the particular module requested may change depending on the situation or particular need at the time? A: [diFalco] In this context I was referring to modules which have no explicit references to them in other parts of the EXE. This would be the case in a data-driven application, for example.