similar to: Element#fire normal (i.e., non-custom) events

Yea that''s what I am seeing also. Think I got round this before by turning the structure into a table :( Andrew - Thanks for your input.. > -----Original Message----- > From: rails-spinoffs-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > [mailto:rails-spinoffs-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org] On > Behalf Of Andrew Tetlaw > Sent:

I have a page that I have been tasked with adding sortable support to, and the div elements that are being dragged have a <a href> in them with an onClick handler that opens a new window with a preview. Is there a way to keep that onCLick from firing when a sortable is dropped? Sam D _______________________________________________ Rails-spinoffs mailing list

I wanted to create an iframe that could be included on any page for uploading images, without determining the parent behaviour at all from within the iframe. The iframe include just checks if there was an image loaded, and does this to pass upload information to the parent (this only fires when an image was uploaded): $(window.parent.document).fire(''image:uploaded'',

im not good in English, so code here ----------------------------------------------------------------------------------------------------- <form id="form"> <input type="submit" value="submit" /> </form> <script src="http://ajax.googleapis.com/ajax/libs/prototype/1.6.0.2/ prototype.js"></script> <script> //i pass the

Hi all, we are writing a cross browser Javascript control that enhances the HTML text input element in order to accept only digits (more or less). Supposing that ''domText'' is the DOM element corresponding to the HTML text input, we wrote the following: Event.observe(domText, "keypress", this.onKeyPress.bindAsEventListener(this)); where this.onKeyPress =

Is anyone else finding it frustrating to do in Ruby client-side things that would be simple in Javascript? It seems like all of the "helpers" involve server (controller) communication. For example, having a text field that just echos below what the user types. Is this the only way to do it? <div id=''word_panel''> <%= text_field_tag

https://bugs.freedesktop.org/show_bug.cgi?id=107167 Bug ID: 107167 Summary: constantly firing events while screen attached to NVIDIA card is disabled Product: xorg Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component:

Hi All Not strictly Scriptaculous but I came across this whilst trying to implement some Scriptaculous code. I am hoping some XHTML guru out there might be able to shed some light. If you load up the attached file in IE6, you''ll see the events only fire in the middle section of the title bar when your over the border ! - FF1.5 is fine.. Any thoughts / comments appreciated.. Cheers

I''m looking for an event handler in Prototype (or plain old JavaScript) similar to onContentReady() in the YUI library: (see http://developer.yahoo.com/yui/examples/event/event-timing.html) How can I implement this? If I''m not mistaken, my testings showed the document.onLoad() happens too early (as soon as the page loads it fires, even before some dom elements are on the page

> a little more digging into this and it appears it''s that different > browsers > handle the keypress at different times (from what I can see, there are 3 > events triggered when you press a key, keydown, keypress, and keyup). I > changed line 1531 to ''keypress'' from keydown and on all of the browsers I > tested (safari, opera, konqueror) it appeared to

What are the pros and cons of using Event.observe vs. element.onxxx = somefunction ? I noticed that a lot of sau code doesn''t use Event.observe. For example, InPlaceEditor uses this.form.onsubmit = this.onSubmit.bind(this); In my code I''ve made a habit of using the equivalent (for example): this.onSubmitListener = this.onSubmit.bind(this);

Have anybody used Event.fire method appeared in v1.6. There are no samples, references or even api for this method. I want to use it for my needs and don''t know how. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to

Is there a standard way of programmatically firing an event on an element? I think this code works in IE but not FF: myElement.fireEvent(''onclick''); I really only care about IE and FF, but anything else is a bonus. I didn''t see anything in prototype/scriptaculous for this, but I might have missed it. Thanks. Joe Athman

Hi everyone! I came across and interesting problem with prototype Event.observe. Take this code for example: <script type="text/javascript" src="cropper/lib/prototype.js"></script> <script language="JavaScript"><!-- function handler(e) { if (document.all) { e = window.event; } var key; if (document.layers) key = e.which; if

attached is an html file I used to test the bug. the top text box should not allow you to type anything, not tab, not enter, nothing. bottom text box should work fine. requires prototype.js and includes jslog for jslog.info although it only occurs in one place, I just wanted to make sure the event was firing without having to use alerts :) tested browsers/platforms: opera: mac / win / lin:

I''m pretty new to ruby and rails and have been racking my brain for a few hours on this one. I have set up a text_field_with_auto_complete and it works great. It talks to my controller correctly, firing my method that queries mySQL and returns a nice <ul> to select from all with CSS. Ok great. Now I want to be able to capture the ID of the item that the user will select from. I

Dear Rui, Thanks for your quick reply -- this allows me to see the bottom of this. I was hoping we could have a handle of those p in genmoics such as 1e-300 or smaller. Best wishes, Jing Hua ________________________________ From: Rui Barradas <ruipbarradas at sapo.pt> Sent: 21 June 2019 15:03 To: jing hua zhao; r-devel at r-project.org Subject: Re: [Rd] Calculation of e^{z^2/2} for a

> I've tried to separate out the general bugfixes from the new > implementation work in this patch: Sorry, I should have done that, I do tend to fix stuff I find while coding and neglect splitting up afterwards. Bad me. > I've not yet committed this to trunk. It does sound pretty cool > though. I don't see any problem with adding pango etc. support, it's > pretty

Hello! I posted in another mail that I had a problem with this code: paths.each( function(img, i) { this.imglist[i] = new Image(); this.imglist[i].src = img; Event.observe( this.imglist[i], ''onload'',

Hi Peter, Rui, Chrstophe and Gabriel, Thanks for your inputs -- the use of qnorm(., log=TRUE) is a good point in line with pnorm with which we devised log(p) as log(2) + pnorm(-abs(z), lower.tail = TRUE, log.p = TRUE) that could do really really well for large z compared to Rmpfr. Maybe I am asking too much since z <-20000 >