I have fixed the remaining issues in the branch today. As far as I’m concerned, I’m ready to merge it in.
Before I do, feel free to let me know if there’s any problems with my code… BTW: It should be very straight-forward to add mouse wheel event properties to the MouseEvent now. HTML has both x and y properties as opposed to Flash which has only y scrolling. That brings up some implementation questions, but nothing major. > On Jul 26, 2017, at 12:51 PM, Harbs <harbs.li...@gmail.com> wrote: > > I agree with everything you write. > > I think BrowserEvent was created to just be a proxy to the goog one, but the > work to make proper MouseEvents and KeyboardEvents was not really finished > until now. > > Please check out the current state of the browser-event branch. I think it’s > working pretty well right now and it should address all of these issues. > > Thanks, > Harbs > >> On Jul 26, 2017, at 12:27 AM, Peter Ent <p...@adobe.com.INVALID> wrote: >> >> I feel like I'm not grasping some concept. Seems to be that >> >> a) you would want at least two points in a MouseEvent: the screen position >> and the local position that is relative to the event.target. You could >> derive one from the other but why go through that hassle when both >> platforms provide that, as far as I can tell. >> b) you would want to know other conditions such as which button is used, >> if it is up, down, or moved (either with or without a button pressed), if >> any keyboard key was also pressed at the same time. >> >> I don't see why computations need to be made unless some value in one >> platform is unavailable and needs to be calculated, but I don't see any >> that fall into this category. >> >> Having FlexJS MouseEvent extend a platform event class seems to have it >> drawbacks, but it also makes the event work in the current system, so I >> would let that go. >> >> What's disturbing is that events like Mouse and Keyboard and pretty >> fundamental and it seems very late in the game that we are discussing >> this. I can probably do what I need to do with DnD with what's there, but >> it is just exposing a fundamental issue to me. >> >> ‹peter >> >> On 7/25/17, 3:08 PM, "Harbs" <harbs.li...@gmail.com> wrote: >> >>> I¹m personally not sure that MouseEvent actually works. Any case of >>> MouseEvents in the Framework actually dispatch BrowserEvents. The only >>> exception to this case that you will currently find is in TLF where there >>> is code which generates MouseEvents from points. >>> >>> Check out my browser-event branch for my attempt to make MouseEvents and >>> KeyboardEvents behave the way you¹d expect. >>> >>> I¹m currently struggling with figuring out how to make artificially >>> created MouseEvents behave properly. Maybe we should compare notesŠ >>> >>> Harbs >>> >>>> On Jul 25, 2017, at 9:49 PM, Peter Ent <p...@adobe.com.INVALID> wrote: >>>> >>>> I've been doing work with Drag and Drop and that involves mouse events. >>>> I'm wondering if someone could give me a history on the Apache FlexJS >>>> MouseEvent? Specially, its use of localX/Y and screenX/Y. >>>> >>>> I'm wondering why the platform implements do not simply assign their >>>> version of screenX/Y as the screenX/Y values instead of the screenX/Y >>>> being getter functions? >>>> >>>> I've run into cases where the localX/Y == screenX/Y in the FlexJS >>>> MouseEvent but the original event had different values. >>>> >>>> Why would we not want the FlexJS MouseEvent to reflect the platform's >>>> mouse event values? >>>> >>>> SWF: flexJSMouseEvent.screenX = swfMouseEvent.stageX; >>>> JS: flexJSMouseEvent.screenX = jsMouseEvent.pageX; >>>> >>>> Thanks. >>>> Peter Ent >>>> Adobe Systems/Apache Flex Project >>> >> >
