specifies the names of the HTML elementId's to look for in the HTML document; these elements are where the user interface of the simulation is created.
Private groupName of each group, to display in menu of group choices.
Private groupWhich group is currently selected.
Private groups_The test classes in which test functions are found.
Private startWhether tests should start when loaded.
Private testName of each test, to display in menu of test functions.
Private testindividual test parameter
Private testWhich test is currently selected.
Private tests_The 'setup' test functions. They create and arrange the set of objects that comprise the test.
Add the control to the set of simulation controls.
the control that was passed in
Private addAdds the given Observer to this Subject's list of Observers, so that the Observer
will be notified of changes in this Subject. An Observer may call Subject.addObserver
during its observe method.
the Observer to add
Adds the Parameter to the list of this Subject's available Parameters.
the Parameter to add
if a Parameter with the same name already exists.
Private addAdds tests from the given class to the menu of available tests.
Tests are static methods that take a parameter of type ContactSim
and return undefined.
The test added must end with '_setup'; the menu name is generated from
the test method name by changing all underscores to blanks, and removing
the '_setup' suffix.
the class whose tests will be added to the menu of available tests.
Notifies all Observers that this Subject has changed by calling observe on each Observer.
An Observer may call addObserver or removeObserver during its observe
method.
a SubjectEvent with information relating to the change
Notifies all Observers that the Parameter with the given name has changed by calling observe on each Observer.
the language-independent or English name of the Parameter that has changed
if there is no Parameter with the given name
Protected getReturns whether broadcasting is enabled for this Subject. See setBroadcast.
whether broadcasting is enabled for this Subject
Returns the ParameterBoolean with the given name.
the language-independent or English name of the ParameterBoolean
the ParameterBoolean with the given name
if there is no ParameterBoolean with the given name
Returns the ParameterNumber with the given name.
the language-independent or English name of the ParameterNumber
the ParameterNumber with the given name
if there is no ParameterNumber with the given name
Returns the ParameterString with the given name.
the language-independent or English name of the ParameterString
the ParameterString with the given name
if there is no ParameterString with the given name
Private makePrivate makeAdd the control to the set of simulation controls, before the damping control.
the control that was passed in
Removes the Observer from this Subject's list of Observers. An Observer may
call removeObserver during its observe method.
the Observer to detach from list of Observers
Removes the Parameter from the list of this Subject's available Parameters.
the Parameter to remove
Protected setSets whether this Subject will broadcast events, typically used to temporarily disable broadcasting. Intended to be used in situations where a subclass overrides a method that broadcasts an event. This allows the subclass to prevent the superclass broadcasting that event, so that the subclass can broadcast the event when the method is completed.
whether this Subject should broadcast events
the previous value
Private setPrivate startLoads and runs the selected test.
Note: Previously, TestViewerApp was rebuilding the entire world (controls, canvas, sim, display, etc.) and this was causing a lot of confusion. A symptom was that the test menus were being left behind when switching to a different Builder. Now TestViewerApp’s reset method is re-using the ContactSim and not rebuilding controls etc.
Returns a minimal string representation of this object, usually giving just identity information like the class name and name of the object.
For an object whose main purpose is to represent another Printable object, it is
recommended to include the result of calling toStringShort on that other object.
For example, calling toStringShort() on a DisplayShape might return something like
this:
DisplayShape{polygon:Polygon{'chain3'}}
a minimal string representation of this object.
Static loadGenerated using TypeDoc
Interactively run and view various engine2D tests after selecting the test to run from a set of menus. This lets us see what a test is doing; it uses the '_setup' method of the test to configure the simulation -- creating and arranging the initial state of objects. What you see should be exactly the same as what happens when running the test.
TestViewerApp examines a certain set of test classes and finds methods whose names end with '_setup' and adds the name of those tests to the menus. So it is only the 'setup' methods for the various tests that can be run here, not the actual tests.
In most cases, TestViewerApp should show the exact same results as the tests. There are a few tests that make changes outside of the _setup function for the test.
TestViewerApp has two levels of menus: a group menu for each group of tests, and another menu for individual tests. Selecting from the group menu changes what tests are available in the individual tests menu. Selecting from the individual tests menu starts that test running.
The main difference between how tests are run here in TestViewerApp versus how they are run in Engine2DTests is: in Engine2DTests we make a new ContactSim for each test, whereas in TestViewerApp we reuse the ContactSim. This is necessary because of the complex web of connections between controls, simulation, builder, etc. In future, it might be better to copy how Engine2DTests works and make a new ContactSim for each test.
WARNING: when trying to debug a test: check whether the options on the ContactSim and CollisionAdvance are different than the Engine2DTests options; such as ImpulseSim.setCollisionHandling, CollisionAdvance.setJointSmallImpacts, ContactSim.setExtraAccel, ContactSim.setExtraAccelTimeStep, the DiffEqSolver, the timeStep, etc.
Parameters Created
ParameterNumber named
GROUP, see TestViewerApp#setGroup.ParameterNumber named
TEST, see TestViewerApp#setTestParameterBoolean named
START_ON_LOAD, see TestViewerApp#setStartOnLoadHow TestViewerApp Works
Look in a set of specified classes (e.g. StraightStraightTest, CircleStraightTest, etc.)
Iterate over all methods in each class, looking for any methods that end with '_setup'
Make a list of '_setup' methods and their names
Make a set of menus, one menu item for each '_setup' method
When the menu item selected: reset the sim; run the selected '_setup' method.
Communicating the Time Step
The reason for storing the time step in AdvanceStrategy is so that TestViewer produces same results as running a test. This is a way to communicate the time step to the TestViewer. VERY IMPORTANT for reproducing results. See
TestViewer.startTest_where we set the timestep on theSimRunner.Communicating the Sim Rect
If a test sets a specific simulation rectangle on the ContactSim then we use that. Otherwise we try to find a rectangle that encloses all the objects and then some. See TestViewerApp#setSimRect_.
Gravity and Damping Get Special Treatment
Because GravityLaw and DampingLaw get recreated for each test we search for them after building each test and connect the respective gravity and damping controls to them.
Another consequence is that we don't provide GravityLaw or DampingLaw to the EasyScriptParser, so these aren't as easily scriptable as in other apps. However, there are short names defined for them, so it is still relatively easy to add JavaScript to a URL script like this:
The gravity and damping controls are 'built-in' to the HTML, and there is special code for finding the HTML controls and connecting them. There is also a special method for inserting a control before these built-in gravity and damping controls, see TestViewerApp#prependControl.
TO DO rename to reflect this is the test viewer for engine2D tests only?