Implemented. The widgets HIDDEN form variables now belong to a form. By default
for "0" will be used to put HIDDEN form vars. If you want HIDDEN var from a
specific widget to be in an other form, use "FormIndex" widget parameter (0
default).

This bug needs to be verified, but not sure what I am verifying can someone
either tell me how to verify or verify it for me. 

Thanks

Changed target for beta 2

Sacha added an attribute to all widgets called FORMINDEX that can be set to an
integer value that is the form that the widget is part of.

To verify this would require that a new template be created with two forms on it
and with widgets in the second form, then set the FORMINDEX of the widget to be 1. 

This could theoretically be done in one of the samples by adding <form></form>
at the beginning of the body before the first form, then putting FORMINDEX="1"
into each widget in the form tags (select from <form> to </form> then do search
as replace on '<cwc2' with '<cwc2 formindex="1"' within the selection)

And the app should function normally.

Created an attachment (id=31) [details]
template file with two forms

Created an attachment (id=32) [details]
sample application that calls template with two forms

Created an attachment (id=33) [details]
application that load the two forms template

I created a template named "sample_basic_form.html" and an application named
"sample_basic_form.phtml" based on comment number 3.  It is not possible to
switch from tab to tab.  Also "ZoomIn", "ZoomOut", "Recenter" and "Query"
fonctionalities are not working as expected.

I attached my template and my application to this bug.

problem caused by many widgets not calling the base class InitDefaults function
from their own InitDefaults function.

Fixed by examining every widget and adding parent::InitDefaults(); as the first
line of the InitDefaults function if used.

Also, added check in the core framework to make sure that InitDefaults is called
by every widget in the page.  Now, if a widget is missing this, an error message
will be generated and reported through the error manager and in the HTML
template.  The 

note that the tabs in the example apps won't work correctly because the use of
document.forms[0] is hard-coded into the examples.  This is not a chameleon error.

verified using the attached templates and by changing  a couple widgets
formindex="1" to "0" parameter.

Viewing the source you can see two separate <form></form> sections.

This was verified using beta 2 2004-07-09 on Windows. 

Created an attachment (id=40) [details]
sample_basic_form.zip-Template and application with two forms

All widgets are displayed as expected but navigation tools need to be activated
each time before being used.

Steps to reproduce:

1.  Load "sample_basic_form.phtml" application.
2.  Click on "ZoomIn" button.
3.  Click on the map preview.
4.  View is updated as expected (larger scale but "ZoomIn" button is no more
selected.

Fedora Core 2
Chameleon 20040709

Changed target to 1.99 Beta 3.

tested ... this works fine for me, the problem is that the page contains other
javascript to initialize the tabs that that is referring to form[0] (which is
invalid) so javascript processing is terminated during page load and the button
initialization never happens.  There's not much that we can do if the user has
invalid javascript on the page.

I was working on something similar when I was this bug resurface ... I just
verified comment 14 ... I changed the refernces to forms[0] to forms[1] in the
sample.js and everything works as expected (with no javascript errors).

Correction to most recent comment ..

"I was working on something similar when I was this bug..."

I personally was never this bug - I only saw it.

Changed target for verification to 1.99 RC 1.