Custom Query (18300 matches)


Show under each result:

Results (148 - 150 of 18300)

Ticket Resolution Summary Owner Reporter
#9568 fixed dijit.Tooltp doesn't work when is instantiated from inside of other widget template bill Aleksey Rechinskiy


Please, take a look into attached test file.

It creates a new widget with dojo.declare(), based on [dijit._Widget, dijit._Templated], with widgetsInTemplate:true and templateString set to a string with dijit.layout.BorderContainer? widget inside. Inside of a second pane of BorderContainer? there is a dijit.Tooltip, that doesn't appears, while it must.

Run a page, click on the "resize" button (it is necessary to deal with #9567 ) and open a Pane 2 of BorderContainer?. Big text has a dijit.Tooltip attached, but it won't fire. The same HTML as templateString works as expected when is parsed on page load directly from a page.

This test case also demonstrates #9567 for BorderContainer?.

#9669 invalid Change dijit.Dialog::_position() method to make it part of public interface Aleksey Rechinskiy


I'm looking for a way to deal with dijit.Dialog bug, that prevents two successive dialogs to work (#6759).

The main idea of a workaround I see, it to use one instance of Dialog to display two instances of Dialog's data: display the first data and then replace it when necessary with the second dialog's data. When the second data has to be hidden, restore the first data.

It is obvious that this scenario requires the Dialog's content to be changed during Dialog's run-time and that feature, in turn, requires the Dialog's frame to be resized and repositioned. If one is to use Dialog::attr('content', newContent) - it ok. This method changes the Dialog's size and position to fit new content. But I need slightly more: I want to be able to change only a special part of Dialog's content leaving most of other content (especially internal button widgets - I don't want to re-create them each time I need to change Dialog's content) intact. When I change some nodes inside of Dialog's content, I had to trigger Dialog's resize&reposition, but it looks like there is no "public" method for this action.

There is a Dialog::_position() method, marked with underscore as internal. It looks like the method I need and it works as expected, but I'm not sure if it is good idea to use it. Is there a real need to keep this method as internal? Could it be made a part of public interface?

If not, is there an other way to trigger Dialog resize&reposition after changing some internal nodes of Dialog's content?


#9670 duplicate Dialog: closing should be cancellable Aleksey Rechinskiy

And one more proposition to dijit.Dialog:

Consider the following Dialog use-case:

Lets imagine the page, that makes an important long-runnning AJAX requests and must prevent a user to iteract with the page content during that requests. Each request should also be cancellable by user after confirm()ing "Are you sure you want to cancel this request? (not recommended)"

An obvious Dojo component to use to create a cancellable modal message "request is running, please wait" is a dijit.Dialog with the message and a button "Cancel request". When user clicks on the button, confirm() is fired and if the user agrees, the request is cancelled. If the user disagrees, Dialog should be running as before. Looks good?

There is a small issue with the Dialog I don't know how to overcome: if user clicks on X button in Dialog's title bar, Dialog will close without a chance to prevent closing (when user say "No, I don't want to cancel the request, I've just decided to wait until it ends, let it run.")

X button is tied to onCancel() function. onCancel() has a hide() function connected. There is no room for Dialog closing prevention in this model.

It is possible to override hide() function on the Dialog's instance to make it fire confirm() and call original hide() if YES, and dismiss the call if NO. But it would be much better, if the Dialog::hide() function will call a some kind of callback shouldIClose() and if it returns true, do real hide(), but if false - dismiss the call.

The proposal looks very easy to implement, but it would widen a range of possible use-cases of dijit.Dialog.


Note: See TracQuery for help on using queries.