Dialog setContent doesn't trigger the parseOnLoad step

[guest]

When I using the setContent() method to refresh the content of a Dialog, I found the widgets of the content will not be parse normally. But if I use the setHref method, it works properly. It might be the design problem, cause I found the Dialog widget do something before and after the setContent method so that only the _downloadExtralContent() could work but the setContent method not.

Please fix this problem so that user can load the content by himself using specific program.

[guest]

I could tell something more about this bug now.

I found if the content of a ContentPane? like widget content another ContentPane? like object ,the child(ren)'s widget won't be parsed.

I hope this could help you fix this bug more easier, and I have tested all the ContentPane? and its subclass widgets they all have the same problem. The priority to this bug might need to be upgraded to a higher level I think.

[bill]

Please attach testcase using the "attach file" button.

[guest]

I'd attached a testcase in the attachment.

The 2 examples are having different problem to ComboBox? widget. test1.htm shows that widgets inside a form will not be rendered normally in an inner ContentPane? (in fact I'd tested with other form widget, they are not rendered either, you can have a try yourself). test2.htm shows that when you load an widget in a ContentPane? inside another ContentPane? widget, it would be disappear once it's loaded.

Please help to solve the problems, thanks.

[bill]

Looks to me like it's working, and just that you don't include tundra.css so the display is all messed up. I tried adding that and it worked fine for me, at least on FF.

PS: not to be picky but in the future please attach things as zip files, because rar support isn't built in to PC's or Mac's. Thanks!

[guest]

OK, I'll be caution about the attachment's type next time.

I'll give you my test environment: IE 6.0.2900.2180.xpsp_sp2_gdr.070227-2254 FireFox? 2.0.0.7 dojo release 1.0.1

For I.E. ===================================================================== In LoadTest1.htm,when I pressed the submit button, the combobox changed into a normal select item like the attachment pic1.jpg.

In LoadTest2.htm,pic2.jpg shows that once the inner pane is loaded, the ComboBox? will disappear.

For FF ==================================================================== In LoadTest1.htm, pic3.jpg tells that once the submit is pressed, the ComboBox? even disappear. LoadTest2.htm testcase can be run normally in FF.

Could you try another time following my steps? By the way, the test pages should be put at the root folder where puts the dojo tools.

[bill]

Hi.

LoadTest1.htm: Looks like pressing the button is submitting the form and reloading the page so that's why the content is disappearing on FF. IE is doing something stranger, but still, it's because the page is reloading. You can notice the reload easily on firefox because the URL bar changes a little.

IE/LoadTest2.htm: yup, I just reproduced this on IE6. It's fixed in trunk with the conversion of input widgets to use <div> rather than <table> in their templates.

[guest]

Thanks to your improvement.

I do know it'd been refreshed, but it's very odd looking in IE for the view before submitting is a beautiful combo box, but after submitting it becomes to the original select box.

This would only happen when you try to reload a ContentPane? or its children within another ContentPane?. I'd changed the code from submitting a form to just change the view by a direct link, it also happened.

[bill]

Looks like a test error to me. I uncommented your code for submitForm(). It does a

dijit.byId("innerDiv").setContent("... dojoType=innerDiv ...");

which fails because you can't have two widgets with the same ID.

I'm attaching the corrected files which seem to work fine on IE and FF.

[bill]

this example fixes the duplicate widget id problem and works on IE and FF

[guest]

Oh, that's it!! Sorry for my mistake and making so much trouble to you.