*** empty log message ***

2 files changed, 84 insertions, 0 deletions

diff --git a/TAO/ChangeLog-98c b/TAO/ChangeLog-98c
index 83f855e2446..e4e3a75e849 100644
--- a/TAO/ChangeLog-98c
+++ b/TAO/ChangeLog-98c
@@ -1,3 +1,8 @@
+Thu Sep 17 21:22:42 1998  Jeff Parsons <jp4@cs.wustl.edu>
+
+	* TAO/tests/DynAny_Test/README.txt
+	  Updated and edited file.
+
 Thu Sep 17 18:52:14 1998  Carlos O'Ryan  <coryan@cs.wustl.edu>
 
 	* orbsvcs/orbsvcs/Event/EC_Gateway_UDP.cpp: 
diff --git a/TAO/tests/DynAny_Test/README.txt b/TAO/tests/DynAny_Test/README.txt
new file mode 100644
index 00000000000..522284d05b0
--- /dev/null
+++ b/TAO/tests/DynAny_Test/README.txt
@@ -0,0 +1,79 @@
+
+		***********  DynAny_Test  ****************
+			
+			updated 9/17/98.
+
+
+What we have so far starts with the DynAny.idl file. Since TCKind is 
+a return type in one or two of the functions, another file called
+tckind.idl is included in DynAny.idl, but is not included in the NT project 
+build. This causes the TAO IDL compiler to generate include statements for 
+files called tckindC.h and tckindS.h which don't exist, so these statements 
+must be commented out of the generated source files. Note that tckind.idl 
+contains a copy of the TCKind enum in Orb.h, so if the TCKind enum ever 
+changes, there will be a choice of recompiling from scratch or doing an 
+extensive search and edit for code depending on this enum.
+
+Since the IDL generated source files have had to be modifed, the .idl files 
+are collected in a separate "project" in the VC workspace, so source files 
+are not regenerated  automatically every time the IDL compiler gets rebuilt. 
+The VC project names "client" and "server" mean nothing.
+
+The _i classes inherit from the POA_ classes generated by the IDL compiler, 
+not from DynAny_i. This leads to some repeated code (mostly in the insert 
+and get functions, the other common functions being slightly different 
+for each class), but allows specialization of classes, notably DynAny_i. 
+Since the basic DynAny_i instances will populate the lowest level of any 
+complex DynAny, this class has been kept as lightweight as possible. 
+Thus this bridge pattern has some advantages to offset the increased 
+footprint, but it may be changed when the files are moved into TAO.
+
+The insert_xxx and get_xxx functions in POA_DynAny (in DynAnyS.h), 
+which were generated as pure virtual, have been modified to be 
+non-virtual. This is because DynEnum_i, which inherits from 
+POA_DynEnum which inherits from POA_DynAny, does not override 
+these functions (nor does POA_DynEnum).
+
+The file da_tests.idl contains some data structures that have been used 
+for debugging (nothing yet for DynUnion). The file driver.cpp has been 
+used for this debugging, and the contents of these two files are in 
+flux. There is as yet no test to run.
+
+****************Some things to note about DynUnion: 
+
+The spec is vague on the action of set_as_default
+and member_name and there seems to be disparity in the interpretation of 
+the spec by other vendors. In this implementation, they are interpreted 
+as follows:
+
+set_as_default -
+	Treated as read-only, the assignment version is included to 
+	override the virtual function, but has an empty body. The 
+	fetch version returns TRUE if the DynUnion has a default 
+	value and that default value is the active member.
+
+member_name
+	Fetch version just returns the name of the active member. The
+	assignment version makes active the member with the supplied 
+	name (if it is valid), but does not save the previous value, 
+	so to be meaningful, an insert or assignment should be done 
+	after this operation, since the new active member will be 
+	uninitialized.
+
+If a non-valid label is supplied for initialization or assignment 
+(in the typecode of an Any supplied to the constructor or to 
+from_any, for example), and there is a default index, the member 
+index will be set to the default value and the label will be stored 
+in the member DynAny holding the descriminator. If there is 
+not a default index, an exception will be thrown.
+
+For the DynUnion functions next(), seek() and rewind(), a new
+uninitialized member will be created and the original will be lost. 
+I can't see what use these functions have when used with DynUnion, 
+but a behavior has been defined. If some behavior as yet unforeseen 
+turns out to be useful, these functions can always be changed.
+
+The spec calls for the seek() function to take an argument of 
+type Long, which is only one of ten types that a DynUnion label 
+can have, so the argument to seek() must refer to an index and 
+not to a label.