We have detected that cookies are not enabled on your browser. Please enable cookies to ensure the proper experience.
Results 1 to 7 of 7

Hybrid View

  1. #1

    Lotro scrollbars and MouseDown

    Okay, here's an odd one. Bug?

    I create a Turbine.UI.Lotro.Scrollbar. Works fine. Then I want to grab certain values at the time when the user clicks it. (i.e. MouseDown() event).

    So I write a MouseDown function for my scrollbar which does my code, then passes control on to Turbine.UI.Lotro.Scrollbar.Mou seDown().

    My routine isn't called. When I click on the scrollbar, it goes straight to the scrollbar's implementation.

    This isn't the case for other methods - e.g. MouseEnter and MouseLeave work just fine. (That is to say, my 'override' methods receive the events).

    So how do I intercept the MouseDown() before the lotro scrollbar grabs control? I could 'fudge' it with MouseEnter/leave or with ValueChanged, but this will be visually obvious to the user and won't always generate the right results. I really need to grab some environmental variables at the *precise* moment at which the user clicks on the scrollbar.


    The only thing I can think of is to put a transparent control *over* the scrollbar, intercept the MouseDown() there, do my stuff, and then pass the MouseDown() command to the lotro scrollbar.

    But the default lotro.scrollbar() has all its routines hidden away behind a "user implementation" type. So I *CAN'T* call its MouseDown() routine. Nor does (despite the documentation) GetThumbControl() return the thumb control (I thought maybe I had to send the MouseDown to it?).

    So while I can intercept the MouseDown with the invisible lay-over control, I can't find any way to pass that MouseDown event to the underlying scrollbar.

    Is there some way to re-post the mousedown event? Then I could intercept it, do my processing, set the overlay control to MouseVisible(false), re-post the mousedown event (this time the scrollbar would catch it), and then restore MouseVisible() once the scrollbar was doing its processing.


    ... more and more complicated kludges.

    Am I right that this is a bug in the Lotro.Scrollbar class... and where does one report such thing to get them added to the list? (I know that lua development is sporadic and slow....)
    Last edited by Eddenwulf; Apr 01 2014 at 12:24 PM.

  2. #2
    Join Date
    Mar 2007
    Posts
    1,155
    This is partly covered in the "Slip sliding away" scrollbar sample post of the thread:
    https://www.lotro.com/forums/showthr...95#post5857895

    Scrollbars have two modes, bound and unbound. If you bind a scrollbar to a control then the client handles all scrolling functionality and you lose access to the events, methods and properties associated with scrolling, including the MouseDown event. If you do not bind the control then you will have full access to all of the events, methods and properties but you will have to provide all of the functionality as well. Can you better describe why you need to receive MouseDown events for a bound scrollbar and to what kind of scrollable control the scrollbar is bound?

  3. #3
    The scrollbar *isn't* bound.


    I've got bound scrollbars elsewhere, behaving properly. (And your slip-sliding post was helpful when first tacking those.)

    But this scrollbar is UNBOUND.

    I'm already intercepting the ValueChanged() event when its thumb or buttons are used, and handling that just fine. As well as setting min and max and value and all that good stuff when using an unbound scrollbar.

    What I want to do now is to detect, when the mouse is pressed on the scrollbar, whether Shift or Control (or both) are being held down. I thought it would be a straight-forward case of defining a MouseDown() routine which did that check, then passed control on to Turbine.UI.Lotro.ScrollBar.

    But my instance of the control never receives the MouseDown() event - that interaction simply goes straight to the parent (class) routines.

  4. #4
    Join Date
    Mar 2007
    Posts
    1,155
    Quote Originally Posted by Eddenwulf View Post
    The scrollbar *isn't* bound.


    I've got bound scrollbars elsewhere, behaving properly. (And your slip-sliding post was helpful when first tacking those.)

    But this scrollbar is UNBOUND.

    I'm already intercepting the ValueChanged() event when its thumb or buttons are used, and handling that just fine. As well as setting min and max and value and all that good stuff when using an unbound scrollbar.

    What I want to do now is to detect, when the mouse is pressed on the scrollbar, whether Shift or Control (or both) are being held down. I thought it would be a straight-forward case of defining a MouseDown() routine which did that check, then passed control on to Turbine.UI.Lotro.ScrollBar.

    But my instance of the control never receives the MouseDown() event - that interaction simply goes straight to the parent (class) routines.

    Ah. I'm surprised I never noticed that before. The control is only firing MouseDown when you click on the scrollbar background, not on the Thumb Button or Increase/Decrease buttons. That does seem like a bug and should be reported via /bug using the Type of Bug "Plugins / Lua".

    Fortunately, in your particular case there is a simple solution. To determine if Shift or Control are down when the value changes, you can simply call the scrollbar:IsShiftKeyDown() or scrollbar:IsControlKeyDown() methods in the ValueChanged() event handler (or anywhere else that you need to know whether they are being pressed). This may actually be better than using a MouseDown handler if you want to know if the user releases the Shift or Control but continues to slide the scrollbar.

  5. #5
    Ah, I shall so report it then.

    I'd only seen half the equation too ... I knew it didn't work with the thumb/buttons but hadn't seen that it did with the background.

    It looks as if (I'm guessing for protection/limitation reasons) the scrollbar first does its own functioning, then calls the instance's routine (if any). So I don't have to call the scrollbar's MouseDown() command, as that's already been processed before I receive the MouseDown event.

    Meaning it's probably a case where that call was omitted in the code that handles the scrollbar's buttons?



    Your suggested solution, unfortunately, won't work.

    I wanted to use a single scroll-bar control to set several values. The state of the shift and control keys, when the scrollbar was clicked, was going to determine which value was being changed.

    The state of those keys after the click (e.g. when the value is being changed) is unhelpful - the user could click, release keys, and then move the thumb.

    It looks like I"m going to have to do the clunkier way: get the value of those command keys in a MouseEnter/Hover command (which does work for lotro scrollbars), and having multiple scrollbars which I show/hide accordingly.

    Which will probably work - it just means yet more code bloat and processing time, which I was hoping to reduce through this little trick.

    With the bugged scrollbar, though, I can't think of any way to make that work. So back to the multiple-scrollbar plan.


    thanks!

  6. #6

    bug report

    Finally remembered to submit the bug report

    -----


    There's a bug in the lotro scrollbar class.

    When a user clicks on the thumb or buttons of a lotro scrollbar, control bypasses all the object-orienting / inheritance / superceeding commands and goes straight to those 'hidden' controls.

    There's no callback to the scrollbar object itself when the lotro.scrollbar is clicked in those fields.

    As a result, any mouse command (e.g. MouseDown) defined for a child object of Lotro.Scrollbar will *NEVER* receive a mouse event if the event occurs within (and is capturd by) those buttons.

    MouseDown() and so forth *are* properly called if the even happens in the regions of the lotro.scrollbar outside those thumb/button controls.


    Ideally, the lua script would be changed so that users could capture the mouse events *first*, and then pass the 'click' on through the usual inheritance command (e.g. Turbine.UI.Lotro.Scrollbar.Mou seDown(self,args)) ... but I realize there's probably concern over automation with this.

    Still, at the very least, the user-defined MouseDown (etc) need to be called in a callback when the lotro.scrollbar intercepts them.


    An improvement:

    A neat solution to avoid the 'automation' concerns but still provide a closer approximation to true inheritance in these cases would be to let the user-defined commands (e.g. MouseDown()) return a boolean where 'false' would tell the lotro control not to process the event.

    This would allow 'overwriting' [the child object says 'I've got this - don't process it'] while continuing to prevent users from directly calling the lotro interface itself.

    This could apply to all such commands, not just the scrollbar.


    discussion here:
    https://www.lotro.com/forums/showthr...-and-MouseDown

 

 

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

This form's session has expired. You need to reload the page.

Reload