8 Replies Latest reply on Dec 6, 2010 4:48 PM by WordRad

    CursorManager == CurseInstigator?

    WordRad Level 1

      Its become a sisyphean just to try and display a busy cursor properly.


      I started with a simple objective of replacing whichever cursor was visible in my app with a  busy cursor whenever a specific event occurred and then restoring the original cursor later.  So the first thing I ran across in Adobe was this page on using a busy cursor and it said to use CursorManager.setBusyCursor and removeBusyCursor. I tried that and it displayed the busy cursor when it was supposed to, but didn't remove the other cursor, so you had the original cursor with the a little clock floating around and chasing after it.  This is of course unacceptable and completely nonstandard.   So then some more searching on the internet and I found others commenting on this same bizarre behavior, but no remedy was provided.


      In that original tutorial page above they did provide another method for displaying a busy cursor as well. It said:


      "The busy cursor has a priority of CursorManagerPriority.LOW. Therefore, if the cursor list contains a cursor with a higher priority, the busy cursor does not appear until you remove the higher-priority cursor. To create a default busy cursor at a higher priority level, use the setCursor() method,"


      Well the behavior they describe  wasn't exactly what I encountered - the busy cursor was displaying, its just that the original cursor wouldn't go away.  But  I tried setCursor method they describe anyway,  but the result was the same.


      So subsequently I discovered that UIComponents have they're own cursorManager property, so I tried this.cursorManager.setBusyCursor, as well as the cursorManager properties of the individual UICompoenents on the page (various Text controls).  No Change.  I also tried calling cursorManager.hideCursor, removeAllCursors first (before trying to set the busy cursor) but to no avail.


      It would be pointless to provide code samples because I have duplicated adobe's own samples and they don't work properly and then I have tried countless reasonable iterations of them and nothing works correctly.


      The last thing I tried was simply txt1.cursorManager.removeAllCursors; txt1.cursorManager.hideCursor; for a Text control on the page   and that had no effect whatsoever - The text control's bar and link cursors still display as normal.  I also have tried calling all of the aforementioned methods from an event handler whenever the mouse moved, and same behavior as originally described.


      So really, my only question to Adobe, or whoever, is SHOULD i be able to just display a normal busy cursor?  And what do you base this assertion on?  Are there actual flex apps anywhere on the web that display a normal busy cursor?  Is there any documentation any where on the web that has a handle on what's going on with Flex cursors and how to make them work?



        • 1. Re: CursorManager == CurseInstigator?
          WordRad Level 1

          Just to simplify this, the very last thing I tried was to just make a control's cursor just go away.  As I said, for a Mx:Text control I tried txt1.cursorManager.removeAllCursors(); txt1.cursorManager.hideCursor() and that had no effect whatsoever.  Anyone know why.


          (The first remark in the OP should have read "sisyphean ordeal"  I had such a hard time spelling sisyphean  that I neglected to add "ordeal" on the end.  Actually, finding the spelling for sisyphean was kind of a mini-sisyphean ordeal.)


          Maybe Adobe should have a busy cursor of Sisyphus endlessly pushing a rock up a hill.

          • 2. Re: CursorManager == CurseInstigator?
            Flex Rock Level 1


                    This is not complex as much as what you are expecting to be. Instead of removing busy cursor for each component you can remove the busy cursor for the whole appliaction like this.





            • 3. Re: CursorManager == CurseInstigator?
              WordRad Level 1

              Jayagopal, I just tried that - it accomplishes nothing.




              I tried CursorManager.removeAllCursors.


              Guess I'll try this.cursorManager and Application.application.cursorManager as well.

              (Note - this is on Flex 3 But I recompiled under 4 with same result.)

              • 4. Re: CursorManager == CurseInstigator?
                WordRad Level 1

                Jayagopal -


                Did you just see RemoveAllCursors listed in the documentation or have you actually used it.

                • 5. Re: CursorManager == CurseInstigator?
                  Flex Rock Level 1



                            I have used it in Flex3 and Flex4, it is working for me. I think you might have done some other mistake. Can you post your code here so that i can able to verify.




                  • 6. Re: CursorManager == CurseInstigator?
                    WordRad Level 1

                    As a first step, I'm just trying to make *a* cursor anywhere dissapear and stayed dissappeared;


                    I have tried




                    and also the same as above for


                    this.cursorManager  (for the application)




                    txt1.cursorManager (where txt1 is a Text control in my app)



                    I have tried calling all of the above only after all controls are completely loaded and also from a mouse event handler, where they're getting called every time the mouse even moves -nothing will make a cursor dissappear. 



                    There is a slight complication as my application is set up to replace itiself in its entirety with a modified version of itself by calling SWFLoader, but right before I call SWFLoader.load I attempt to hide the cursors of the parent App as well as shown above.


                    The program itself is long and unstructured so no point in posting it here.

                    • 7. Re: CursorManager == CurseInstigator?
                      Flex harUI Adobe Employee

                      Is this in AIR?  If in Flash are you using a custom WMODE?


                      Which Adobe example isn't working?

                      • 8. Re: CursorManager == CurseInstigator?
                        WordRad Level 1

                        Flex har



                        This was not AIR, it is Flex 3.


                        The WMODE is normal.


                        However I have solved my problem.


                        Originally I wanted to completely replace any active cursor with the busy cursor. The problem (to review) was that the orignal cursor would not go away, and would appear on top of the busy cursor, and then when moving the mouse, the busy cursor would trail after the original cursor, and the two cursors would kind of join up again. So it was really annoying.


                        I did find the following which sort of solved the problem:






                        With the above, the original cursor would go away and stay gone, *once the mouse was moved*, leaving only the busy cursor. Why it was necessary to move the mouse, I have no idea. So this as well did not completely solve the problem (but came much closer).


                        Here was my final solution:

                        First of all, I had not noticed previously that the standard busy cursor in the browser keeps the original pointer, and just offsets an hourglass to the right of that pointer by a fixed distance.  Don't know why I had not notice that before.  So all I had to do was


                        csr_busy = CursorManager.setCursor( StyleManager.getStyleDeclaration("CursorManager").getStyle("busyCursor"),1,20,0);


                        at one place, and then to remove it later,




                        That's it.  the '20' parameter just keeps the busy cursor (an animated clock) 20 pixels to the right of the original cursor (whatever it happens to be at the time - a pointer, a hand, etc.), which from my experience is impossible to completely remove anyway, so I don't try.  But it looks good as I have it now, and contrary to what I originally thought is consistent with the Browser's own busy cursor.