Loading ...
Sorry, an error occurred while loading the content.

Re: mousdown event overrides/ignores click event

Expand Messages
  • Jim Ley
    Francis Hemsher wrote in message news:bbdcdb+814v@eGroups.com... ... What do you mean by priority? Do you mean you expect that
    Message 1 of 8 , Jun 1, 2003
    • 0 Attachment
      "Francis Hemsher" <francishemsher@...> wrote in message
      news:bbdcdb+814v@......
      > Jim Ley Wrote:
      > > "A click is defined as a mousedown and mouseup over the same screen
      > > location."
      > > (which is somewhat nasty definition because it means that the
      > mousedown and
      > > click events can fire on different elements, which has some nasty
      > > consequences for scripting too.)
      > >
      >
      > I guess I expect the click to have priority over mousedown.

      What do you mean by priority? Do you mean you expect that when click fires,
      mousedown shouldn't? I'm afraid that's incorrect to the spec, and very much
      not what I want. (for example you can make buttons which seperate the
      animation to make them appear depressed, with the code that activates
      onclick.)

      > functions contained as attributes in an element:
      >
      > setAttribute("onmousedown","top.tryMouseDown(evt)")
      > setAttribute("onclick","top.clickEvt(evt)")
      > setAttribute("onmouseup","top.mouseUpEvt()")

      Please don't do stuff in HTML when there is absolutely no need, especially
      using TOP! when you have no knowledge if your site is framed or not (ie top
      is not what you think it is)

      > {
      > setTimeout("mouseDownEvt()", 300)
      > down=false

      Nowhere does it say that click has to fire within 300ms of onmousedown
      firing, so whilst this may work for certain clicks there's no guarantee it
      will work any more than any other system.

      I'm still intrigued as to what it is you're doing that requires this.

      Jim.
    • Francis Hemsher
      ... screen ... nasty ... click fires, ... very much ... the ... activates ... especially ... (ie top ... onmousedown ... guarantee it ... this. The application
      Message 2 of 8 , Jun 1, 2003
      • 0 Attachment
        > > Jim Ley Wrote:
        > > > "A click is defined as a mousedown and mouseup over the same
        screen
        > > > location."
        > > > (which is somewhat nasty definition because it means that the
        > > mousedown and
        > > > click events can fire on different elements, which has some
        nasty
        > > > consequences for scripting too.)
        > > >
        > >
        > > I guess I expect the click to have priority over mousedown.
        >
        > What do you mean by priority? Do you mean you expect that when
        click fires,
        > mousedown shouldn't? I'm afraid that's incorrect to the spec, and
        very much
        > not what I want. (for example you can make buttons which seperate
        the
        > animation to make them appear depressed, with the code that
        activates
        > onclick.)
        >
        > > functions contained as attributes in an element:
        > >
        > > setAttribute("onmousedown","top.tryMouseDown(evt)")
        > > setAttribute("onclick","top.clickEvt(evt)")
        > > setAttribute("onmouseup","top.mouseUpEvt()")
        >
        > Please don't do stuff in HTML when there is absolutely no need,
        especially
        > using TOP! when you have no knowledge if your site is framed or not
        (ie top
        > is not what you think it is)
        >
        > > {
        > > setTimeout("mouseDownEvt()", 300)
        > > down=false
        >
        > Nowhere does it say that click has to fire within 300ms of
        onmousedown
        > firing, so whilst this may work for certain clicks there's no
        guarantee it
        > will work any more than any other system.
        >
        > I'm still intrigued as to what it is you're doing that requires
        this.

        The application requires drag/drop for the element, plus a means to
        access the element to dynamically change/delete it via an onclick
        event. MouseDown=start drag, MouseMove=drag It,
        MouseUp=end drag. The OnClick event exposes the elements attributes
        and children so the user can dynamically make changes to them.

        As for "TOP!": Recently on this list it was stated that IE6 does not
        recognize the traditional "parent" as the means to access the
        function on the HTML side and that "TOP" was a workaround. Since the
        site has to work in IE5.5+, and since top also works in IE5.5, I
        chose to go with it at this time. (Generally, functions are preferred
        to be located on the HTML side, rather than CDATA in the svg, in
        order to facilitate troubleshooting and maintain a seamless
        development environment).

        The site is more for an Intranet environment rather than something
        for the general public. It is not intended to be accessed by
        nonconforming environments or operating systems. This allows for a
        good idea of the parameters that have to be addressed before it is
        launched.

        Francis
      • Jim Ley
        Francis Hemsher wrote in message news:bbdffc+fj6m@eGroups.com... ... I do this without problem, I always end drag on a
        Message 3 of 8 , Jun 1, 2003
        • 0 Attachment
          "Francis Hemsher" <francishemsher@...> wrote in message
          news:bbdffc+fj6m@......
          > The application requires drag/drop for the element, plus a means to
          > access the element to dynamically change/delete it via an onclick
          > event. MouseDown=start drag, MouseMove=drag It,
          > MouseUp=end drag. The OnClick event exposes the elements attributes
          > and children so the user can dynamically make changes to them.

          I do this without problem, I always end drag on a "background rectangle"
          aswell as the element, and since onclick guarantees that a mouseup is firing
          somewhere within the document, which means it doesn't matter if
          startDrag/endDrag are performed during a click event firing other than a
          slight extra demand in processing, which probably wouldn't cost 1/3rd of
          second in any case.

          > (Generally, functions are preferred
          > to be located on the HTML side, rather than CDATA in the svg, in
          > order to facilitate troubleshooting and maintain a seamless
          > development environment).

          I fail to see why this is really the case, since all you're really doing is
          adding complication to the development environment and adding potential
          sources of errors, an external script escapes the need for having CDATA
          sections.

          > The site is more for an Intranet environment rather than something
          > for the general public. It is not intended to be accessed by
          > nonconforming environments or operating systems.

          I guess being in an environment without strong disabled rights legislation,
          for me that certainly wouldn't be an option (discriminating against an
          employee or potential employee isn't a good idea.) Also of course being in a
          situation where your application is so important to the environment that
          you'll have the power to dictate the environment, and prevent MS upgrades -
          as you note parent/top behaviour changed with the IE6 upgrade.

          Jim.
        Your message has been successfully submitted and would be delivered to recipients shortly.