Sorry, I guess I read that too quickly.
Looks like a bug in the widget factory. There's no check to make sure
you're not re-initializing elements. I'll try to commit the fix today
or tomorrow.
On Sep 2, 3:31 am, Paul Carey [EMAIL PROTECTED] wrote:
On Sep 1, 3:36 pm, Scott González [EMAIL
You're setting alwaysOpen to false and event to mouseover, so this is
proper behavior. You can set alwaysOpen to true and set the default
active panel to one that doesn't have children (like Contact Us).
On Sep 4, 8:52 pm, bcbounders [EMAIL PROTECTED] wrote:
I have the accordion plugin
You're going to need to provide a page showing the problem. It will
also help to keep the test page as simple as possible while still
showing the problem.
On Sep 8, 5:55 pm, Brandon Jones [EMAIL PROTECTED] wrote:
I tried searching but came up with nothing about my issue (though a
couple of
This is working fine for me with current SVN. If you're still having
problems, please make sure you're using the latest version and provide
a test page.
On Sep 12, 9:06 pm, pkw [EMAIL PROTECTED] wrote:
I'm trying to determine is a dialog is open or not.
When I us dialog(isOpen) it seems to
The reports you looked at are for developers, not submitters. You
need to search for your ticket.
On Sep 17, 3:12 am, LM [EMAIL PROTECTED] wrote:
Hi again.
I've submitted a bug about all of this but it seems it's gone... I
can't seems to find it neither in My Bugs
This sounds like a bug. Removing a dialog element should inherently
destroy the dialog (and revert everything it has done). This is true
for all UI plugins. Can you please make sure this is occurring with
the latest version of core + dialog, and if it is please file a
ticket. Thanks.
On Sep
The patch is checking for options that have values set to none. Can
someone explain why that should be supported?
There are already tickets filed for bugs with NaN, so you can search
trac for these tickets and follow them to see any progress. If the
original submitter wants to create a patch
Can you please verify that you're using the latest version (one of the
1.6 release candidates or latest svn)?
On Sep 19, 2:59 pm, Jeremy [EMAIL PROTECTED] wrote:
I must be doing something wrong, but it's driving me nuts so hopefully
you guys can help me. I want to check to see if a dialog is
Glad to hear you're having a good experience with the community.
This problem has been fixed (see ticket #3457). Thanks for pointing
this out.
On Sep 19, 12:05 am, Jeremy [EMAIL PROTECTED] wrote:
Thank you both for your quick responses. I'm encouraged by how active
the jQuery groups are.
We're currently only doing bug fixes right now. 1.6 will be released
by the end of the month, so you'll have to wait for 1.7.
On Sep 21, 11:35 pm, Jeremy [EMAIL PROTECTED] wrote:
Any chance this is getting resolved in UI 1.6? This would be VERY
nice to have for alert boxes and other dialogs
am, Scott González [EMAIL PROTECTED] wrote:
Hey snobo,
I haven't forgotten about your problem. I still have your emails in
my inbox for reference and access to your intranet.
It is confusing that the problem is seemingly unrelated to the event
bindings, so I'll probably just have
Setting the speed is not currently supported. There is a ticket for
this, but Trac is currently down while we're switching servers, so I
can't tell you which ticket it is.
On Sep 23, 4:41 pm, Greg E. [EMAIL PROTECTED] wrote:
Hi all,
Here's what I have going on:
//create dialog
Have you tried using the jQuery UI Dialog?
On Sep 30, 1:01 am, Jordan Isip [EMAIL PROTECTED] wrote:
Hi All,
I can't seem to get the datepicker() widget to work on a modal box.
I've tried it on both the Boxy and Facebox plugins and I get the same
result - nothing. It works just fine when I
If you want to get that custom, you should be making the dialog
draggable/resizable on your own instead of using the built-in dialog
options.
On Oct 2, 9:11 am, André Cassal [EMAIL PROTECTED] wrote:
Hey guys, I don't know exactly if this is the right place to ask/
suggest this.. but
I'm
I could see possibly adding an option for whether or not to animate,
but I don't think there should be a hard-coded exclusion for IE 8
just because it will be slow with multiple. It sounds like it would
be perfectly reasonable to have only one progressbar and want
animation.
On Oct 6, 11:14
Can you post a sample page showing this problem? Also, which version
are you using?
On Oct 14, 8:32 am, Jamie [EMAIL PROTECTED] wrote:
I have a page with two dialogs in it, both are modal and reference
different elements within the page (i.e. two different forms)
$(#dialog-page).dialog({
Check the jQuery FAQ about events and AJAX requests (even if you're
not using AJAX).
http://docs.jquery.com/Frequently_Asked_Questions#Why_do_my_events_stop_working_after_an_AJAX_request.3F
On Oct 18, 11:17 pm, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Here's what's happened in order. I
Can you please test with the 1.6rc instead of 1.5.1? Thanks.
On Oct 21, 9:44 am, Antranig Basman [EMAIL PROTECTED] wrote:
Antranig Basman wrote:
We have created a simple test case here:
file:///E:/workspace/fluid-components/src/webapp/tests/jquery-tests/manual/jQueryUI-focus-test.html
Please post a demo page showing the problem so we can look into this.
Thanks.
On Oct 21, 9:26 pm, javatech [EMAIL PROTECTED] wrote:
Hi,
I'm new at JQuery and try to get dialog close button working.
Currently, if there is no AJAX, close button worked but if I did a
ajax call, then close
Try updating to the 1.6rc, this problem has been fixed:
http://ui.jquery.com/bugs/ticket/3349
On Oct 22, 12:45 pm, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Hi,
The Dialog component doesn't seem to work in IE 6 if I don't specify a
class name for the div. If I set class=flora then it works.
The actual HTML of the dialog doesn't reset on open; if you want that
to happen, you'll need to do it yourself. You can either clear out
the fields in the dialog prior to opening it or clone the div and
create a new dialog each time.
On Oct 22, 5:07 pm, [EMAIL PROTECTED] wrote:
Hello-
I am
Calling .dialog() and passing in a hash initializes the dialog - this
can only happen once. To open a dialog after it has been initialized,
you need to do $(el).dialog('open');
Try this:
$(#delpicdialog).dialog({
autoOpen: false,
title: 'Are you sure?',
modal: true,
This is a known bug: http://ui.jquery.com/bugs/ticket/2807
Unfortunately, it probably won't be fixed until after 1.6. If you're
interested in looking into this, the ticket has a link to a thread
that identifies the cause of the problem.
On Oct 27, 7:14 pm, JEF [EMAIL PROTECTED] wrote:
When i
Please post this on the main jQuery list, this list is specifically
for jQuery UI.
http://groups.google.com/group/jquery-en
On Nov 6, 5:31 am, vijaygarg [EMAIL PROTECTED] wrote:
Hi,
I have grid (ASP:ListView) control in my .net appliction where i have
hours information along with other
On Nov 12, 1:36 pm, Richard D. Worth [EMAIL PROTECTED] wrote:
If you're just going to call it once with an argument or two, better off
with a plugin. If you're creating something the user will see, touch, feel,
interact with, a widget may be a good fit.
This is a pretty good way to generalize
This type of question is really better suited for the jquery-en group,
as this group is specific to jQuery UI plugins.
Something like this should work:
var intervalId;
$(el).mousedown(function() {
intervalId = setInterval(function, interval);
}).mouseup(function() {
Can you describe what's supposed to be happening?
On Nov 12, 11:25 pm, Micah C [EMAIL PROTECTED] wrote:
Bump. Anybody? I really badly need the help here.
On Nov 11, 10:34 pm, Micah C [EMAIL PROTECTED] wrote:
I've gotten the accordion playing almost perfectly, but It appears to
be
http://docs.jquery.com/Effects/animate
On Nov 12, 12:02 pm, Jørn Schou-Rode [EMAIL PROTECTED] wrote:
This is probably a very lame question, but I cannot seem to find the
answer in the demo section of the jQuery UI website nor on Google, so
here here we go: Is there any simple way to gently
All UI widgets have _init. init only exists in old versions, when the
widget factory didn't have a way of determining which methods were
private.
On Nov 14, 6:25 pm, h3 [EMAIL PROTECTED] wrote:
I was looking to some of the ui widget source code recently and saw
that some are using _init
This list is specific to jQuery UI plugins. Please post this on the
main jQuery list.
On Nov 17, 8:16 pm, Bhavin [EMAIL PROTECTED] wrote:
Hi,
I am using JQuery with Struts 1.1. I am using following code when user
clicks on Save button:
$('#save').click(function() {
I'm pretty sure jQuery doesn't support cross-window operations. You
need to create a method on the parent window that will close the
dialog and then call that method from the child window.
On Nov 18, 1:43 pm, manilodisan [EMAIL PROTECTED] wrote:
I'm loading a dialog and inside it an iframe to
As stated in the previous thread, this won't be looked at until after
the 1.6 release. Also, this now has a dependency of the postionTo
plugin that is being developed for 1.7.
On Nov 24, 9:03 am, sparkpool [EMAIL PROTECTED] wrote:
For some reason, I can no longer reply to this thread, maybe
If this is occurring with current SVN, feel free to create a ticket
for this. Thanks.
On Nov 24, 10:24 am, sparkpool [EMAIL PROTECTED] wrote:
I'm finding that closing a non-modal dialog by pressing escape closes
other open dialogs too, in some cases but not all. Has anyone else run
into
Moving the call to _init outside of the constructor would be fine.
Can you file a ticket for this? Thanks.
On Nov 27, 5:32 am, Paul Bakaus [EMAIL PROTECTED] wrote:
Hi there,
this indeed a severe issue - ironically, once I read it, I was facing the
exact same issue when
building a new
I assume you're referring to the zindex problem in IE6. If so,
include the bgiframe plugin and set the bgiframe option to true in
your dialogs.
On Nov 28, 4:12 pm, Jeff_N [EMAIL PROTECTED] wrote:
Embedded objects always appear above UI dialogs and are unaffected by
modals. Is there a special
is an object. I know that this.text is actually
text internally though.
On Dec 9, 10:54 am, Scott González [EMAIL PROTECTED] wrote:
Hey Brian,
You're correct that you would use this.page to access the element if
you did this.page = this.element.find('.page').
this.page.element
Yes, ui.core.js is significantly different between 1.5 and 1.6 and
using 1.5 plugins with 1.6 core is unsupported.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery UI group.
To post to this group, send email to
There's currently no way to re-position a dialog through the dialog
API. This doesn't seem like an intuitive feature - the developer
should only set the opening position, and only the user should move it
afterward. You could manually calculate the position yourself and
just set the top and left
Dialogs are essentially asynchronous so the confirm function is
returning before the user clicks either button. You need to put the
logic for what to do inside the button functions.
On Dec 16, 4:16 pm, Carl Von Stetten vonner.li...@vonner.net wrote:
I'm trying to replace the standard browser
In an effort to keep our APIs simple and meet the needs of the largest
possible audience, we only provide limited built-in support for mixing
plugins. In the case of draggable for dialog, you can only turn it on
or off and you always drag by the titlebar. If you need more complex
functionality,
The dialog plugin, like many other jQuery UI plugins, require CSS to
work. You can generate your own or download existing themes at
http://ui.jquery.com/themeroller
On Dec 16, 12:36 pm, JQueryProgrammer jain.ashis...@gmail.com wrote:
Can anyone please give me any link where I can find some
We can add support for height: 'auto' (I have this locally and am just
waiting to get in touch with some other team members about this).
It's worth mentioning that auto-resizing will only happen if the user
has not resized the dialog manually. If the user has resized the
dialog, we should not be
This question is really better suited for the main jQuery list since
it's not about a jQuery UI plugin.
It sounds like you probably forgot to set position to absolute. If
that doesn't work, please post in the main jQuery list and provide
some sample code (a live, stripped down version is the
Can you please create a ticket for this? We'll try to tackle this
before the 1.6 final release if possible. Thanks.
On Dec 12, 10:09 am, Fabien Meghazi amigr...@gmail.com wrote:
Using overlay in $.fn.dialog()
$(win).dialog({
overlay: {
opacity: 0.5, background: black
},
Support for height: 'auto' has been added in r1197.
On Dec 20, 11:31 am, Scott González scott.gonza...@gmail.com wrote:
We can add support for height: 'auto' (I have this locally and am just
waiting to get in touch with some other team members about this).
It's worth mentioning that auto
I talked to Scott Jehl from the design/interaction team and he agrees
that repositioning automatically is not a normal behavior for a dialog
window.
You can cause dialogs to be repositioned with the following code:
$(el).dialog('option', 'position', $(el).dialog('option',
'position'));
On Dec
You should re-post this to the main jQuery list to get more
responses. This list is specifically for jQuery UI plugins. With
that being said, the jQuery UI Dialog plugin supports modal dialogs
and there are plans to split out the overlay code into its own plugin
soon.
On Dec 23, 7:14 am,
See responses in original thread:
http://groups.google.com/group/jquery-ui/browse_thread/thread/fce3cde1149840c8
On Dec 27, 5:02 am, jQDeveloper ashish...@gmail.com wrote:
Hi All,
I was trying to replace my window.open() code with the jQuery Dialog
box. Now here is my code:
$(function() {
and feathered for allowing so much content into a dialog
that it would make it so big).
Would it help if I provided an example?
Thanks for all the great work guys.
On Dec 22, 4:45 pm, Scott González scott.gonza...@gmail.com wrote:
I talked to Scott Jehl from the design/interaction team and he
You can tell a dialog to reposition itself with one line of code:
$(el).dialog('option', 'position', $(el).dialog('option',
'position'));
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
jQuery UI group.
To post to
Fixed.
Ticket: http://ui.jquery.com/bugs/ticket/3756
Commit: http://ui.jquery.com/bugs/changeset/1493
On Jan 2, 4:40 pm, Nikola nik.cod...@gmail.com wrote:
Is there any word on this?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to
The alwaysOpen option does not affect the initial status of the
accordion; it only determines what should happen when a user tries to
toggle an active panel. The active option lets you set which panel is
active, so setting this to false on init will cause all panels to be
closed.
On Jan 4,
to be :-)
On Dec 30 2008, 8:55 am, Scott González scott.gonza...@gmail.com
wrote:
Joshua,
We fully understand what you're asking for and why it would be
useful. However, you have to consider all of the other common cases
like a user manually moving or resizing the dialog. Also, it's only
one line
Hi Jason,
We're at an interesting crossroad right now, where UI 1.6rc4 doesn't
work with jQuery 1.3 and UI current SVN doesn't work with 1.2.6. The
final 1.6 release (and any more RCs) will only work with 1.3. This
problem should be fixed in current SVN. Can you try using current SVN
with 1.3
to the superbox, so whenever you click it, it
tells you what it thinks is its id with this.element.get(0).id
You will see in the example that it always returns experiment1 for the
id. Any help is much appeciated!
-j
On Jan 8, 11:20 am, Scott González scott.gonza...@gmail.com wrote
Okay, so the dialog content is hidden on destroy. This is intended
behavior. However, the dialog does nothing to ensure that the content
is visible on init/open. This is probably a bug. Feel free to create
a ticket for this at http://ui.jquery.com/bugs/newticket (requires
registration).
I don't see how binding an event handler and passing in the widget
instance is any cleaner than creating a closure and referencing the
instance that you already have. In fact, this looks like it just
causes an increase in the amount of code needed to bind the event
handlers.
What's awkward or
On Jan 13, 10:33 am, h3 hainea...@gmail.com wrote:
In my example yes, because it was a simplified scenario. Your method
most likely is more efficient with small codebase, but when I deal
with many components and events it does get ugly.
The dialog plugin is built entirely in this fashion and
Great. Sorry for all the confusion, this should all settle down soon
when 1.3 and UI 1.6 both have final releases.
On Jan 13, 9:26 am, Stefan Sturm stefan.s.st...@googlemail.com
wrote:
Hello,
UI current SVN requires jQuery 1.3. Try upgrading to 1.3rc2 and see
if that fixes your problem.
not tried this but are you saying in your last sentence that I could
just do
div class=ui-widget-content/div
On Tue, Jan 13, 2009 at 7:24 AM, Scott González
scott.gonza...@gmail.comwrote:
I don't really understand what you're asking for. If all you want is
a panel, then it's just a div
This has been fixed in rc5.
On Jan 15, 8:59 am, Scott González scott.gonza...@gmail.com wrote:
We've got a ticket for this:http://ui.jquery.com/bugs/ticket/3808
We'll try to get this resolve today.
On Jan 15, 5:43 am, Chris sa...@flexidx.com wrote:
HERE IS THE CODE:
all js and cs
This is fixed in rc5.
On Jan 16, 2:35 pm, Fontzter dmfo...@gmail.com wrote:
Strange...I'm having a similar problem. I get the alternating height
in FF. However, I am not getting errors in IE.
Have you resolved it?
On Jan 15, 10:38 pm, Chris sa...@flexidx.com wrote:
Hello,
If I set
Can you show a page with this problem?
On Jan 16, 3:03 pm, Sarge dsarg...@gmail.com wrote:
In 1.6rc2 dialogs where auto positioned quite well in the center of
the screen, now in 1.6rc5 all my dialogs are positioned too low on the
screen (way too low). I know I could fix this manually with an
);
}
}
);
Is there anything built into the plugin to address this or a more
elegant solution?
On Dec 18 2008, 5:44 am, Scott González scott.gonza...@gmail.com
wrote:
In an effort to keep our APIs simple and meet the needs of the largest
possible audience, we only
time only. When you
click the zoom icon again it's positioned correctly (in the center).
--
Bohdan Ganicky
On Jan 17, 4:40 pm, Scott González scott.gonza...@gmail.com wrote:
Can you show a page with this problem?
On Jan 16, 3:03 pm, Sarge dsarg...@gmail.com wrote:
In 1.6rc2 dialogs
We have redone our markup for several of the plugins while building
our new CSS framework.
The wrapper div that contains the header and content panel gets the
selected class and the header gets the active class.
On Jan 16, 8:24 am, zemm simonenast...@gmail.com wrote:
Hi,
as in subject,
This is fixed in r1668 and will be available in 1.6. I added a
comment to the ticket, but it's worth noting here as well.
You should make sure you that you have all properties and states set
appropriately before invoking any callbacks on init. By invoking a
callback, you're opening yourself up
In rc5 and previous releases the logic was:
find the first tabbable element in the dialog and give it focus on
open.
In current SVN the logic is:
find the first tabbable element in the following order:
- content area
- button pane
- title bar
and give it focus on open.
This is done for
at start. Needs «alwaysOpen: false».
- Richard
On Mon, Jan 19, 2009 at 2:38 AM, zemm simonenast...@gmail.com wrote:
Oh ok - then will be there an activeClass:.whatever ?
On 18 Gen, 15:33, Scott González scott.gonza...@gmail.com wrote:
We have redone our markup for several of the plugins
of the close button?
Thanks,
On Jan 19, 8:14 am, Scott González scott.gonza...@gmail.com wrote:
In rc5 and previous releases the logic was:
find the first tabbable element in the dialog and give it focus on
open.
In current SVN the logic is:
find the first tabbable element
This will most likely be included for 1.7. It is dependent upon the
positionTo plugin http://jqueryui.pbwiki.com/PositionTo
On Jan 19, 6:38 pm, iFeghali igor.fegh...@gmail.com wrote:
Hello,
This has already been discussed here but as far as I know there was no
positive answer. So I would
Currently the only way to do this is to manually find all dialogs and
loop through them checking their zIndex. There's some code in the
dialog plugin that does this that you can grab.
On Jan 19, 2:39 pm, JonUK jdo...@flinttechnology.co.uk wrote:
My page opens multiple dialogs. If a user clicks
Currently you can only set text, so you would have to pass in the
actual characters. Feel free to create an enchancement ticket to
support HTML (http://ui.jquery.com/bugs requires registration).
On Jan 20, 10:07 am, smurkas marcus.dalg...@gmail.com wrote:
Hello.
I have a dialog where I have
I just fixed this in SVN. The problem should go away with 1.6rc6
(being released tomorrow, final release this weekend).
On Jan 20, 8:29 pm, Jeoff Wilks jeoffwi...@gmail.com wrote:
Actually, it looks like both textarea cases cause the dialog to fail. I had
transposed my link hrefs so didn't
I just fixed this in SVN. The problem should go away with 1.6rc6
(being released tomorrow, final release this weekend).
On Jan 21, 1:20 pm, Jeoff Wilks jeoffwi...@gmail.com wrote:
This is the same problem I encountered... I created a ticket
athttp://ui.jquery.com/bugs/ticket/3901
On Tue,
I just fixed this in SVN. The problem should go away with 1.6rc6
(being released tomorrow, final release this weekend).
On Jan 22, 2:32 am, Jeoff Wilks jeoffwi...@gmail.com wrote:
Try initializing your dialog with a large minHeight ... e.g.
$(...).dialog({minHeight:600});
If that works then
Can you provide a page showing the problem?
On Jan 25, 10:36 am, ktpmm5 ka...@steppingstonez.com wrote:
I also upgraded to jQuery UI 1.6rc5, and changed to using a class on my
button - my tabs still do not work, and neither does the dialog. I get NO
js errors, which is making it very hard to
This is fixed in SVN. It will be available with 1.6rc6 tomorrow.
On Jan 24, 1:47 pm, Kostrowsky francois.x.h...@gmail.com wrote:
Posted first on the jQuery group.
Hi,
Just want to report an odd bug, using the UI dialog widget, in IE7
only:
How I create the dialog:
++
$('#' +
it. If I
dont do it like that, it doesn't even listen to my sizes.
On Jan 16, 10:22 pm, Scott González scott.gonza...@gmail.com wrote:
This is fixed in rc5.
On Jan 16, 2:35 pm, Fontzter dmfo...@gmail.com wrote:
Strange...I'm having a similar problem. I get the alternating height
in FF
This is fixed in SVN. It will be available in 1.6rc6 tomorrow.
On Jan 27, 1:15 am, brian brian.whit...@gmail.com wrote:
When I moved to jQuery 1.3.1 and UI 1.6rc5, draggable didn't work
completely anymore. Objects are still getting dragged around, and the
drag and stop and start methods are
In your code, you're trying to reinitialize the dialog on each click,
which won't work (as you've noticed). What you want to do is create
the dialog with the autoOpen option set to false. Then in your click
event you would call .dialog('open') to open the dialog:
...
On Jan 29, 4:47 am, Scott González scott.gonza...@gmail.com wrote:
Can you try with 1.6rc5, or 1.6rc6 which will be released tomorrow?
On Jan 28, 5:58 am, David Healy davhe...@googlemail.com wrote:
ui.core.js shows as version 1.5.3
On Jan 27, 3:37 am, Scott González scott.gonza
In the most simple case of tabs, you would want to base case
(JavaScript disabled, CSS disabled) to be a list of links that point
to some other content on the page.
One step up from this would be to use CSS to add some styling to the
links, and possibly even the content they link to.
The final
You simply apply the ui-state-error class to whatever element you want
to.
div id=dialog
p class=ui-state-errorsomething went wrong/p
/div
$('#dialog').dialog();
On Jan 29, 12:57 pm, niner jyi...@gmail.com wrote:
I have jQuery dialog working with my custom theme. I would like to use
the
Sortable elements don't interact with droppable elements. Try making
the thumbnails draggable as well.
On Jan 31, 8:55 pm, spiderling webmas...@spiderling.ca wrote:
Is there someone that could please, please help with this? I have
viewed many versions of similar sample code, which seem simple
Hi Samo,
This problem is limited to fixed position elements in webkit. I've
created a minimal test case and attached it to the ticket, so it
should hopefully be fixed very soon. Thanks.
On Feb 2, 1:48 pm, Samo Korosec smoof...@gmail.com wrote:
Hi,
I noticed the following bug in
Hi, Bennie,
JavaScript and jQuery already provide a few different methods for
doing this in any context. I'll outline the two most common methods:
Use a closure:
function openDialog(someValue) {
$('#example').dialog({
buttons: {
Yes: function() {
// do
to -63px
On Feb 2, 6:54 pm, Justin Sunseri jmsuns...@gmail.com wrote:
I have this exact problem with IE 6 in rc5 it would crash immediatly
with the bug described above in rc6 it hangs the browser for a long
while before crashing with the same issue
On Jan 28, 10:15 pm, Scott González
The easiest way would be to just use the .load() method in conjunction
with the .dialog() method:
$('div/').load('somepage.html', function() {
$(this).dialog();
});
Alternatively, you could create a div that says loading, instantiate
the dialog on that, and then load the page into that div.
The height is set on the element which you call .dialog() on; it is
not set on the wrapper:
div id=loaderContainer class=loader ui-dialog-content ui-widget-
content style=display: block; height: 88px; min-height: 120px;
width: auto;
Are you actually experiencing a problem where your dialogs are
directly if you need more specific information.
On Feb 4, 9:05 am, Scott González scott.gonza...@gmail.com wrote:
Can you show a page that has this problem?
On Feb 2, 8:35 pm, Justin Sunseri jmsuns...@gmail.com wrote:
in hindsight i think the hang i was experiencing earlier was related
Thanks for pointing this out. I've created a ticket for this (
http://dev.jqueryui.com/ticket/4077 ).
On Feb 5, 2:25 pm, relphie relp...@gmail.com wrote:
Hello, when trying to build a custom UI download, I am unable to de-
select draggable and resizable after selecting dialog. Both of those
UI 1.5.3 doesn't work with jQuery 1.3.1. You need to either downgrade
jQuery to 1.2.6 or upgrade UI to 1.6.
On Feb 6, 11:14 am, Duane duanegar...@gmail.com wrote:
First Here is my info and working Dialog call:
jQuery ver 1.3.1
jQuery UI ver 1.5.3
$(#dialog).dialog({
to it. The dialog options I specified for that
dialog were height 50 px.
I re-copied rc6 and it seems that things are working better. Ill
respond if they are still acting quirky.
Thanks!
On Feb 6, 12:01 pm, Scott González scott.gonza...@gmail.com wrote:
The height is set on the element
I've created a ticket for this ( http://dev.jqueryui.com/ticket/4086
). I'll fix it in a few minutes. Thanks.
On Feb 6, 10:31 am, M Dennis gar...@gmail.com wrote:
jQuery v1.3.1
Query UI 1.6rc6
Base theme
I'm either doing something wrong or it appears as though the method
for changing the
Fixed in trunk.
On Feb 7, 9:17 am, Scott González scott.gonza...@gmail.com wrote:
I've created a ticket for this (http://dev.jqueryui.com/ticket/4086
). I'll fix it in a few minutes. Thanks.
On Feb 6, 10:31 am, M Dennis gar...@gmail.com wrote:
jQuery v1.3.1
Query UI 1.6rc6
Base
On Feb 8, 12:54 am, M Dennis gar...@gmail.com wrote:
Thanks again and glad I could help squash a bug for 1.6, looking
forward to it getting out of release candidate.
Thanks, we're glad too :-)
--~--~-~--~~~---~--~~
You received this message because you are
The name of the event is slidechange.
On Feb 8, 11:52 pm, Viktor N viktor.nord...@gmail.com wrote:
Hello
I'm trying to binds a handler to the sliders 'change' event. But i
cant make it work, can anyone tell my what I'm doing wrong? It works
if is done via the 'change' option when creating
On Feb 13, 8:13 am, SimonS si...@ssewell.freeserve.co.uk wrote:
var options = {
beforeclose: function(){_onDataEntryPopupCloseButtonClick();}
You're not returning anything here.
--~--~-~--~~~---~--~~
You received this message because you are
The shadow has been removed for this version.
On Feb 13, 9:13 am, DEfusion david.sp...@gmail.com wrote:
When I submit the form inside a dialog I hide the form inside the
dialog and show a loading message, when I do this the shadow doesn't
resize properly - but it updates fine if I move the
1 - 100 of 357 matches
Mail list logo
