WebDialog Constructor

Topic: Using Constructor on WebDialog is causing Wrong Optic behaivor
Text: If we use a constructor in a WebDialog, the Displaying is not correct any more, we are calling the super.constructor but this doesn’t help.
If you delete the constructor the WebDialog fits perfectly. We would like to use Constructors for that, because we can react in the Window if data exists or not
(Constructor with no parameter or Contructor with parameters) but this is at the moment not possible
The Problem exists for Xojo2014r1 and Xojo2014r2b2
thanks for help

It’s a known bug. What are you trying to accomplish that requires the constructor?

In general, avoid using Constructors in web apps. They just don’t work the same way as in desktop apps. It’s been like this since it was first released.

What we do for WebDialog is have a Display method and pass in whatever arguments we need. Then in the Display method we have self.show which shows it. So by the time we get to the Display call it already exists and all controls exist.

[code]//Dynamic Dialog handling
dim dlg as new WebDialog1
addhandler dlg.dismissed, addressOf DialogDismissed
dlg.display(“Some String”, iSomeData)

//Static Dialog handling
WebDialog1.display(“Some String”, iSomeData)[/code]

like bob mentioned we want to pass data and react in the webdialog depending on them and we are using the same workaround like he showed.
For Example building a dialog which should edit / add Adresses, on the edit side we would like to pass the existing Data and change some content and on the otherside we just display the default window
Greg do you know when there will be a fix for that bug? i found an old entry which is about a year old which already had this problem and i personally prefer to use the Constructor for that, it’s easier to use and less error prone.

Thanks for the Help

This bug existed before I started at Xojo and is an inherent design flaw which cannot be easily fixed without a huge refactoring. Suffice it to say that creating a second setup method is probably the best way to solve this problem. You could make it so your app throws an exception when in debug mode is the dialog is shown without calling the method.


thanks for the nice idea with the exception on debug mode. I’ll try to use this instead