Hi Marco,

If I understand your scenario correctly, then this is a perfectly understandable behaviour, caused by the by the fact that your contained Html code (or application or whatever is the content of the HrmlBox) is considered a seperate application from your Visual WebGui application.

When you click your filtering button within the contained Html, which caused the Url of the HtmlBox's frame to change, this is only updated client side and your Visual WebGui server side has no idea you changed the Url. The next time you reload the page, or even resize it or do whatever will cause the contents of the HtmlBox to be reloaded, the HtmlBox is rerendered with the values known to the Visual WebGui application as the Url, and that Url does not have the filter value as query parameter.

What you need to do is to notify the Visual WebGui server-side about the changes it must make to it's Url, and you can basically do it two ways. If you have access to the server-side of the Visual WebGui application from within the Html inside the HtmlBox, you may be able to set it directly from there (note it will cause a reload of the HtmlBox contents). If you do not have that access, you will need to raise an event from within the HtmlBox's code using Client-Client invocations, and you should find sample of such communications linked from the HtmlBox article here.

Hope this helps,

Palli

Hi Marco,

When you load contents into HtmlBox or AspPageBox, the contents are loaded into a seperate Html IFrame, and as such, it is considered a different application than your Visual WebGui application is concerned.

Your Visual WebGui application preserves state for all it's UI elements. This means that if you press F5 (reload) on your browser, the whole web page will be regenerated and rerendered in your browser, from the contents that the server-side knows best at that moment. Every time there is a change to any of your controls within a Visual WebGui application (like click a checkbox, make combobox selection etc...) an event (request) is sent from the client-side, notifying the server about the change. The server sets the corresponding attributes on the server-side controls and then responds with an XML which is the delta of changes that the client (possibly) needs to update in the UI as the result of the former request.

In your case, you dynamically change contents inside your HtmlBox, only on the browser, and the server has no idea of the change. Should there be a F5 (reload) at this point, the server would do what it knows best and regenerate the whole browser form, and as the server-side still believes the HtmlBox is using the original Url, it will regenerated it like that and you are back to your original Url.

What needs to be done here is to somehow notify the server-side of your Visual WebGui application about the change that have been made on the contents of the HtmlBox, so that next time it will be regenerated, it will use the correct and modified Url.

We call it client-client invocation, when your HtmlBox code (seperate application), calls the client-side of your Visual WebGui application and have it raise an event to the server-side and make a not of the new HtmlBox Url.

Within the HtmlBox article I referenced in my last email, there are a few links to samples on how this can be accomplished, but to give you a direct link to such discussions, see this forum thread here. See Ori's message from 12/18/2008.

What you basically have to do is to raise an event, set the new Url as an attribute of that event and have it fired to the server. On the server-side you have to override the FireEvent method of the control the event is fired against, get the newly updated Url and set the property on the HtmlBox.

Hope this helps,

Palli