Re: declare: mixin #0 is not a callable constructor. 34.clsInfo.cls.prototype is undefined

You have dojo.declare("dijit.Dialog", [dijit.Dialog], { ... }) ... what
is the intent there? Also the same for TabContainer. If you are trying
to "subclass" dijit.Dialog, give it a new name:

dojo.declare("my.Dialog", [dijit.Dialog], { /* now use my.Dialog()
instead of the dijit one */ })

You have multiple dojo.provide calls, which is bad.

Your dojo.require() calls must exist before the dojo.declare calls using
them.

If you are doing this via x-domain (dojo.xd.js) or simply <script
src="sample.js"></script> you'll want to wrap your dojo.declare calls in
an addOnLoad

You have two addOnLoad functions being registered. One shows and one
hides a dialog. Running them one after another is likely not what you
intended.

~phiggins

> Hi
> Iam geting below error wen using the attached code,Iam not able to search
> and understand why is this happening
> declare: mixin #0 is not a callable constructor. 34.clsInfo.cls.prototype is
> undefined
>
> Can i get any sugestion on that?
>
> Thanks n Regards
> Res

Underlay madness...

Moanin' List,

I have two dialogs that present one after the other. The first is a
throbber, which is a dialog so everything in the system shares style,
and so if I decide to do something fancy with it later it's simple. The
second is a real dialog that shows the result of the action performed
while the throbber was displayed.

Both use custom widgets derived from dijit.Dialog, and other than a
custom template and an attributeMap they are essentially identical,
meaning each relies on the default dijit.Dialog code to manage the underlay.

Except I couldn't figure out how to get a dark underlay, so each
custom widget has a show() that of course calls
this.inherited(arguments) on the first line, then it looks for the
underlay id and uses dojo.addClass() to tack on my class to make it
dark. In this respect each custom widget is identical as well.

THE ISSUE:

Now all the background is out of the way, what happens is the
throbber works perfectly, and the next dialog works perfectly, *except*
the dark underlay does not appear on the second one. When I look in
Firebug I see my class appear and then quickly disappear on the second
dialog.

My research shows this is a bug in dojo 1.3, which I was using,
related to a change that shared underlay across dialogs, and a delay
between first dialog dismiss and second dialog appearance fixes it.
This is in fact what fixes it.

My research also shows that dojo 1.4 corrects this issue. So last
night I put in dojo 1.4.3 and took out my delay. It did NOT work. Even
with 1.4.3 the second dialog fails to retain the correct underlay.

THE QUESTIONS:

1. Did dojo 1.4 really fix this?
2. If not, does dojo 1.5 fix this?
3. If not, is anyone aware it's happening? (grin)
4. Or am I simply not doing the underlay application correctly? I
looked all over for how to apply a custom underlay class and found
nothing that seemed to work, which is why I took the route I did. But
dojo is so flexible I still can't imagine I haven't missed something.

Re: Underlay madness...

On 2/17/2011 4:05 PM, Karl Tiedt wrote:
> give your dialog a class "darkDlg" create a class .darkDlg_underlay {
> background-color: black, }
>
> when that dialog is active, that class is added to the underlay...
Roger. Thanks Karl!
> As for 1-4, was there a bug reported? Was it marked fixed? Is it still
> open? If not did you open one? ;)
(chuckle) I'll look for the bug reports and see...

Re: Underlay madness...

> As for 1-4, was there a bug reported? Was it marked fixed? Is it still
> open? If not did you open one? ;)
I did not see a bug report, but before I put one in I'd like to know I
searched correctly.

- Search was not useful. It would only return 10 hits per page and I
could find no way to change that. After a few attempts kept yielding
full pages of nothing remotely relevant I stopped trying.

- I loaded the "All Tickets" page, which presents 1473 (I think it was)
Tickets at once. I then used the browser text search to scan the
titles. After numerous different things (underlay, multiple, _underlay,
dialog, etc) I found no Ticket that appears to relate to this issue.

Re: Underlay madness...

The fixed in 1.4 were actually my fixes... I can assure you there was
nothing related to this in those fixes... can you post exactly how you
are calling your dialogs?

I know we did some fixes on the show/hide so that consecutive dialogs
wouldnt fight over the animations or something like that... the
smallest test case you can make that illustrates your problem will
help me in tracking down exactly what needs tweaking ;)

Re: Underlay madness...

I have been unable to reproduce this in a stripped-down form. Since
your solution is good, and I'm actually running a dojo version that's
bundled with another product, I would chalk this up to that third party
product having a "custom implementation" unless proven otherwise.

I'll fiddle with it some more, but have no real expectation of
success at this point.