--- Benoit Marchant <[EMAIL PROTECTED]> wrote:
> Ok, I've seen the code in ie. I moved that as well
> to the dragevent. In
> fact when a drag start, there's some code that
> disable the selectstart:
> if (dynapi.ua.dom) {
> lyr.elm.ondragstart =
> dynapi.functions.False
> lyr.elm.onselectstart =
>
> dynapi.functions.False
> }
> I had to move that test to the mousemove after we're
> sure a drag
> session starts, otherwise the text wouldn't be
> selectable when an click
> happens if that code stayed where it was after my
> modifications.
>
> So to fix the ie issue, in the mouseup, we just have
> to enable it again:
>
> if (dynapi.ua.ie) { //Was there
> lyr.doc.body.onselectstart =
> null; //Was there
> lyr.elm.ondragstart =
> dynapi.functions.Allow //Added
> lyr.elm.onselectstart =
> dynapi.functions.Allow; //Added
> }
>
> I have 2 questions before I send you the changes so
> that you can test
> it.
> On the drag start, the test is made for
> dynapi.ua.dom, and in the mouse
> up for dynapi.ua.ie. I don't think that's right,
> moreover because I
> think ondragstart and onselectstart aren't standard
> and doesn't exists
> outside of IE. Please correct me if I'm wrong, but
> otherwise, the first
> test should use dynapi.ua.ie too.
I think opera v7 also uses onselectstart and
ondragstart - can't remember right now. But in any
case just use ua.ie for now.
> The other question is why do we do
> "lyr.doc.body.onselectstart = null;"
> ? It wasn't modified before in the dragevent code,
> so why touching it
> here ?
I can't see why that was used. Comment it out and see
if it solved the problems with selecting text in IE.
--
Raymond Irving
> As soon as I get answers from you, I'll send the
> dragevent, the
> mouse_dom and mouse_ie modified so you can test
> validate it before I
> commit to cvs.
>
> Thanks,
>
> Benoit
>
> On Wednesday, March 12, 2003, at 07:45 PM, Raymond
> Irving wrote:
>
> >
> > --- Benoit Marchant <[EMAIL PROTECTED]> wrote:
> >> Well,
> >>
> >> If I comment the code I've added in dragstart, it
> >> works everywhere but
> >> in Safari. If I comment the code in
> >> MouseEvent._eventHandler() , and
> >> use only the one I've added in dragstart , it
> works
> >> fine everywhere.
> >> So I don't know why. However, it seems more
> logical
> >> to have thes check
> >> which are drag specific in dragevent rather that
> in
> >> mouse_...
> >>
> >> So I would say, let's comment out the code in
> >> MouseEvent._eventHandler() in favor of the one in
> >> dragevent. Run some
> >> tests to make sure.
> >
> > Ok, sounds good to me
> >
> >> The code you mention in mouse_ie.js is the block
> >> about the drag event
> >> or is it another one ?
> >
> > Line 86
> >
> > if(tt=='textarea'||tt=='text' &&
> > target.onselectstart==null) target.onselectstart =
> > dynapi.functions.Allow;
> >
> > --
> > Raymon Irving
> >
> >
> >> Benoit
> >>
> >> On Wednesday, March 12, 2003, at 06:51 PM,
> Raymond
> >> Irving wrote:
> >>
> >>>
> >>> One other thing...
> >>>
> >>> Have you looked at the mouseevent codes
> >> (mouse_xxxjs)?
> >>> The MouseEvent._eventHandler() contains some
> codes
> >>> that will prevent form elements from being
> >> dragged.
> >>> Inside the mouse_ie.js file you'll also see a
> new
> >>> piece of code that enables selection of text
> >> inside
> >>> the textarea if the layer is drag-able.
> >>>
> >>> So in that case we can either more the code from
> >>> MouseEvent._eventHandler() to dragevent.js or
> >> remove
> >>> the code from drag events. What do you think?
> >>>
> >>> --
> >>> Raymond Irving
> >>>
> >>> --- Benoit Marchant <[EMAIL PROTECTED]> wrote:
> >>>> Well, I think it did before I modified the
> code.
> >> In
> >>>> dynapi2, there the
> >>>> following:
> >>>>
> >>>> DynMouseEvent.EventMethod=function(e) {
> >>>> var dynobject=this.lyrobj;
> >>>> if(is.def) {
> >>>> if (is.ie) var e=dynobject.frame.event
> >>>> e.cancelBubble=true;
> >>>>
> >>>> if (DynAPI.wasDragging && e.type=="click") {
> >>>> DynAPI.wasDragging=false;
> >>>> return false;
> >>>> }
> >>>> }
> >>>> ....
> >>>>
> >>>> to avoid sending onclick after a dragend. We
> can
> >> re
> >>>> do the same, the
> >>>> wasDragging is still set in dragevent.js
> >>>> I can't think of a case where it would be bad
> to
> >>>> receive both. But if
> >>>> we need to do it, we know what to do !
> >>>>
> >>>> So I'll go on and commit the changes.
> >>>>
> >>>> Benoit
> >>>>
> >>>> On Wednesday, March 12, 2003, at 01:36 PM,
> >> Raymond
> >>>> Irving wrote:
> >>>>
> >>>>>
> >>>>> Yep! It works fine on my machine with the
> >>>> exeception
> >>>>> of one thing...
> >>>>>
> >>>>> The onclick event is been triggered at the end
> >> of
> >>>> a
> >>>>> drag. Is that by design?
> >>>>>
> >>>>> --
> >>>>> Raymond Irving
> >>>>>
> >>>>>
> >>>>> --- Benoit Marchant <[EMAIL PROTECTED]> wrote:
> >>>>>> Thanks Raymond, that should fix the
> ondragend
> >>>>>> issue, but listeners
> >>>>>> would still receive an ondragstart and maybe
> an
> >>>>>> ondragmove.
> >>>>>> The only way I see to do it "right" would be
> to
> >>>>>> bring back the logic
> >>>>>> from dynapi2.
> >>>>>> I've brought back t he fix to be able to use
> >> form
> >>>>>> elements in draggable
> >>>>>> layers.
> >>>>>>
> >>>>>> Here it is. Please test in on your machines
> >>>>>>
> >>>>>>
>
=== message truncated ===
__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com
-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open!
Get cracking and register here for some mind boggling fun and
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://www.mail-archive.com/[EMAIL PROTECTED]/
