 |
History
| Log In
|
|
|
|
[
Permlink
| « Hide
]
Lauren Park - [12/17/07 12:54 PM ]
PFR.
Changed SystemManager.docFrameHandler from private to mx_internal. This will allow developers to subclass SystemManager and register the DragManagerImpl instead of the NativeDragManagerImpl.
I uploaded a workaround to force the application to use the DragManagerImpl class instead of the NativeDragManagerImpl class.
This workaround will only work on build 191577 or later. The comps.FlexDragSystemManager class subclasses SystemManager and overrides the docFrameHandler function to register the DragManagerImpl class before the super class performs the registration. The comps.FlexDragWindowedApplication associates the FlexDragSystemManager as the root class of the application. In listDrag.mxml, we use FlexDragWindowedApplication as the root tag of our application. This workaround works. I tested Jason's bugfiles with build 161651. Closing bug.
With the release of 3, (build 3.0.194161) I just tried this workaround on my project using your files attached to this bug. It seems to work so far, but probably worth noting that the workaround causes a number of flex components to move name space notably in my app...
<mx:states> <mx::transitions> are now both in the comps name space and must be written... <comps:states> <comps:transitions> Hi,
Thanks for this workaround. I was able to get it working, but I've run into a problem when I open new "Windows". When I attempt to close them, I get the following error: TypeError: Error #1034: Type Coercion failed: cannot convert mx.managers::DragManagerImpl@73e8039 to mx.managers.NativeDragManagerImpl. at mx.managers::WindowedSystemManager/http://www.adobe.com/2006/flex/mx/internal::cleanup()[E:\dev\3.0.x\frameworks\projects\airframework\src\mx\managers\WindowedSystemManager.as:1684] Any way to get around this? I dont want to be rude or anything but personally i disagree about the resolution of this issue. I think it is not resolved in anyway. Suggested workaround seems to me is hacky and also there is no way for a beginner Flex/Air developer to understand this hack. It is kind of essential to have both functionality in many Air application and i like to see a better approach from Adobe for this kind of issues rather than call it resolved and not providing better solution.
I reproduced Mario's problem where you get a RTE when closing a <mx:Window>. I'm re-opening the bug so that we can find a suitable workaround.
Looks like there is a bug in WindowedSystemManager:cleanup(). The drag manager instance shouldn't be cast to a NativeDragManagerImpl when checking the type.
this: if (NativeDragManagerImpl(Singleton.getClass("mx.managers::IDragManager").getInstance()) is NativeDragManagerImpl) should be: if (Singleton.getClass("mx.managers::IDragManager").getInstance() is NativeDragManagerImpl) Since this code is in WindowedSystemManager, you'll have to do the same trick of subclassing Window, specifying a new WindowedSystemManager subclass in the Frame metadata and overriding cleanup() in your WindowedSystemManager subclass. There are multiple problems here:
1. Inability to select the DragManager implementation (like DragManager.doDrag(..., implementation)) 2. The hack for problem #1 doesn't work since cleanup also needs to be hacked (can someone upload a patch for that) 3. Even if we apply these 2 patches, we don't have a guarantee that it won't crash somewhere else The are multiple reasons why I would like to use the Flex drag implementation instead of the AIR one: It serializes complex objects to stick them to the clipboard. Since it doesn't ignore properties like document, I end up serializing my whole app and crash in the process. I was the original submitter of this issue on flexcoders. I've posted some monkeypatch code here for 3.2.0:
http://code.google.com/p/andrewwestberg/ It seems to work fine except for a couple of issues. In a child mx:Window, the mouse cursor doesn't show up while dragging. It works fine on the main WindowedApplication window. It also can't drag/drop between windows using the flex drag manager. I don't think it was ever designed for this though. If anyone has something to add to the monkeypatch code, just ask me for committer access and maybe we can get something better to hand off to the SDK team for the next release. This bug is definitely a big one, and doesn't seem to be getting addressed. I'm using Andrew Westberg's "monkeypatch", and finally have a functioning drag implementation. Adobe's solution is laughable. If its the best the Flex team can come up with, someone higher up should be looking to hire a few programmers like Andrew instead...
Please, please don't close this bug! Fix it until its usable to the average coder! Adobe, take a look at Andrew's code... somebody needs to make sure this is done the right way. I agree with Owen. My monkeypatch is kind of hacky. Someone that understands the dragmanager architecture better than I do should really address it. I pretty much just copied code between the AIR and Flex impl and modified UIComponent until it was working the way I wanted it to. It's working for me and a few others, but I'd like an architect to really dig into what was patched to make sure every use case gets covered.
As explained in the attached file, I have no claim to having fixed this problem, but I do have a documented use case in which I am able to get the two Drag Queens to stop fighting so that I can use both sets of drag-drop operations effectively. I hope this information will be of some help to someone, even as your various postings aided my trouble-shooting and lead to a workable resolution.
Yeah,
i didn't actually know i had a problem, but i couldn't get the dragproxy semi transparent. And later looking on a pc i saw more strange behaviour. I want the flex dragmanager back too! :-) On windows some nice animations are also gone now (animating back the proxy to the start when dropping on a not accepted drop target.) So user experience is less good and that's what flex/air is all about right? BTW running air 1.5 Thanx everyone who submitted a patch / hack. I'll give those a spin while adobe is fixing this. Hope more people wil vote on this one as it is an important one and it's totally not transparent that you get the Air dragmanager by default. My import say import mx.managers.DragManager, so i expect the good old flex one, not some under the hood changed one. I think Adobe is pretty good at listening to user feedback, so this one will be fixed, right? Thanx! Arnoud Oh, almost forgot,
besides the nice feedback animations not working on pc and not being able to set the dagproxy transparency (while the dragmanager says it's ok to do) there is another related bug Changing the feedback cursor doesn't work.... I mean things like: DragManager.showFeedback(DragManager.LINK); if its not meant to work i suggest changing the api or give me a good error/warning. Failing silently does not seem the way to go. I was like WTF? Debugging, making sure the code was reached, etc. etc... Arnoud | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Open
B
Flex B3 DragManager 
