Setting background style for dynamic WebDialog

I can create a Webdialog dynamically on 2016r4.1 (Win) with

dim MyDialog as new WebDialog1

…but if I try to set a background Webstyle for the dialog as part of the process with

dim MyDialog as new WebDialog1 MyDialog.Style = Style1

…the the dialog is not displayed at all.

It looks like this issue was covered in <>, but it’s been closed as “Not Reproducible”.

Is there a problem here, or do I need to go about things differently? Here’s a sample project showing the behaviour.

Actually, I think it cannot work the way you do it. When the control is created, it is not yet sent to the browser, so it does not exist in the DOM. And the style being CSS has to be applied in the DOM.

If you do this, the style is applied because the control exists in the DOM after show :

dim MyDialog as new WebDialog1 MyDialog.Style = Style1

Problem is, the background color is set for the grey overlay, instead of the dialog itself.

Here is a workaround :

[code] dim MyDialog as new WebDialog1

	dim js as string
	js = js + "var MyDialog = document.getElementById('"+MyDialog.ControlID+"_body');"
	js = js + "MyDialog.setAttribute('class','Style1');"

Note that the use of _body in Javascript is a quick fix. If for some reason Xojo was to change the framework for the dialog components, it could break. That said, it is much better to have styles working right immediately, than to wait for an indeterminate fix.

Thanks Michel, that works for me. My aim is to create a generic dialog that I can reuse, so I’ve ended up creating a public String property for the dialog called BackgroundStyle, which in the example project I can set to “Style1” before showing the dialog. Then in the “Open” event of the dialog, I’ve used the Javascript that you posted in the Feedback case:

self.ExecuteJavaScript("document.getElementById('"+me.controlID+"').getElementsByTagName('div')[0].className='"+me.BackgroundStyle+"'; ")

So in your opinion, has the feedback case been incorrectly marked as Resolved? Or are we looking at something different here?

I just looked at the case. It has been fixed, then has been closed when it appeared the bug did not manifest in 2016R1.

From what I see it is not the same as your issue.

Great, thanks again. Solution works a treat. Happy New Year when it comes!