CurseForge and Overwolf are joining forces!
Awesome More Information
  • 0

    posted a message on Detecting Scroll Wheel
    Quote from egingell
    Why do you care? I'm not being rude, I'm just curious.


    part revenge...part insurance
    Posted in: Lua Code Discussion
  • 0

    posted a message on Detecting Scroll Wheel
    Quote from Dridzt
    You said "click" in OP not "scroll" :p

    <OnMouseWheel> is the relevant script handler with self, delta as args.
    (delta > 0 for UP, delta < 0 for DOWN)

    You may need frame:EnableMouseWheel(true) first.


    Well using the scroll wheel to simulate clicking on a macro is what i meant...people need to read what I'm thinking not what I'm saying :p


    Thanks I'll try that out.

    PS: The purpose of this (although it may not be obvious how this question relates) is to detect if somebody is using a bot to click on a button.
    Posted in: Lua Code Discussion
  • 0

    posted a message on Detecting Scroll Wheel
    I'm pretty sure the scrolling up and down on the scroll wheel doesn't count as a "click" which is the entire issue. There is a "middle click" which is an OnClick event when the user clicks with the scroll wheel but that's completely different.
    Posted in: Lua Code Discussion
  • 0

    posted a message on Detecting Scroll Wheel
    Ok say I have a macro that does '/sm test' which runs some test code from my addon. Now say that macro can be placed anywhere on the action bar and I want to know if the scroll wheel is being used to click on the macro and run the test code. Assume the macro will be hit more than a few times.

    What would be the best of doing this? I could go through every key-binding and temporarily unbind the scroll wheel for a half second and then see during that half second the macro is still being pressed but this doesn't seem very optimal.

    Thanks

    EDIT: I'm talking about scrolling the scroll wheel up and down...NOT clicking with it!
    Posted in: Lua Code Discussion
  • 0

    posted a message on AceGUI takes exponentially longer as the number of elements goes up
    Quote from Xinhuan
    This might beg the question.... shouldn't then AceGUI by default internally Pause and Resume when constructing a layout?


    This may not be entirely correct. But I assume AceGUI currently re-does the layout after every new addition to it. This is because AceGUI has no way of knowing how many things will be added and / or when the caller is done adding new widgets / containers.

    One alternative would be to require the user to call DoLayout() when they are done adding things but I can see how the benefit of the user not having to worry about that outweighs the infrequent times where efficiency is important.

    Just my thought anyways.

    EDIT: oops didn't see nev's comment before I made this one.
    Posted in: Ace3
  • 0

    posted a message on AceGUI takes exponentially longer as the number of elements goes up
    To my above question the answer is yes. I just put Pause and Resume calls into the function that does handles all the AceGUI calls and it reduced the time for that one page with 100 groups from 1.7 seconds to 0.31 seconds =D
    Posted in: Ace3
  • 0

    posted a message on AceGUI takes exponentially longer as the number of elements goes up
    Do I need to pause the layout of every child container? Or if I just pause the layout of the treeFrame will it also pause the layout of the scroll frame and then inlinegroups that are added to it.

    EDIT: answered my own question below
    Posted in: Ace3
  • 0

    posted a message on AceGUI takes exponentially longer as the number of elements goes up
    Quote from Farmbuyer
    If you're repeatedly calling :AddChild() then yes it is, by default. The resulting loop is what my undergrad TA used to call "big-Oh of oh-shit".

    If you call :AddChildren() and toss them all in at once, then the layout is only done a single time after they're all added. Using AddChildren isn't always feasible or readable, so the Pause/Resume/Do is another option. And like Nev says, most of these GUIs aren't the kind of thing that will be getting constantly redrawn, so optimization is usually not worth it (cf. Knuth).


    lol I like "big-Oh of oh-shit". I'll try playing around with the layout APIs and report back with my findings.

    Thanks
    Posted in: Ace3
  • 0

    posted a message on AceGUI takes exponentially longer as the number of elements goes up
    Quote from Farmbuyer
    If you know you're going to be doing a ton of widget creation/manipulation, try calling :PauseLayout() on the container object at the start, and then ResumeLayout() + DoLayout() when it's all over.


    Brilliant idea :) I'll definitely give that a shot. That definitely would explain the exponential nature of the times if it's re-doing the layout after every new addition.
    Posted in: Ace3
  • 0

    posted a message on AceGUI takes exponentially longer as the number of elements goes up
    Yea I was just playing around with it and thought it was interesting :) but in the end it wouldn't be practical to have that many things on a single page from a usability point of view even if it loaded in 0.1 seconds.

    Thanks for the response I'll try that when I get home today.
    Posted in: Ace3
  • 0

    posted a message on AceGUI takes exponentially longer as the number of elements goes up
    So I was playing around with AceGUI today and I realized something intriguing. I tested how long it took to load a page with a different number of InlineGroups in it. The InlineGroups are all inside a ScrollFrame. Each Inline group had the exact same thing inside of it. Here is the data I collected:

    25 groups = 0.07 seconds
    30 groups = 0.10 seconds
    35 groups = 0.15 seconds
    40 groups = 0.19 seconds
    45 groups = 0.26 seoncds
    50 groups = 0.32 seconds
    55 groups = 0.39 seconds
    60 groups = 0.49 seoncds
    65 groups = 0.59 seconds
    70 groups = 0.70 seconds
    75 groups = 0.85 seconds
    80 groups = 0.99 seconds
    85 groups = 1.14 seconds
    90 groups = 1.34 seconds
    95 groups = 1.57 seconds
    100 groups = 1.75 seconds

    Not really an issue as far as my addons go...just something I noticed and thought I'd ask about because it's not what I would have expected to see (would expect something linear yet it is more exponential). If it were linear I would have expected 100 groups to take closer to 1 second (instead of 1.75) which is significant.

    Any thoughts on this?

    PS: I loaded each page 3 times and took the average of the last two.
    PSS: The code that does everything up to the AceGUI calls takes less than 0.01 seconds.
    Posted in: Ace3
  • 0

    posted a message on Auction Profit Master *Quick Auctions 3 continued...*
    Still looking for more awesome developers who want to be part of a large project!
    Posted in: General AddOns
  • 0

    posted a message on New Limitations on SendMail
    Quote from Xinhuan
    Try calling SetSendMailShowing(true) before the SendMail(). That's one of the functions that get called when you click on tab 2.

    Clicking on tab 1 calls SetSendMailShowing(false).


    That function doesn't seem to help unfortunately. If I had to guess it's because even if that sets the tab to the second tab it doesn't refresh the mailframe so the second tab isn't actually loaded. When I try /script SetSendMailShowing(true) nothing happens.

    Thanks anyways.
    Posted in: Lua Code Discussion
  • 0

    posted a message on New Limitations on SendMail
    So I guess this isn't a NEW thing...but definitely still there (not an interfering addon). Here is what I did.

    1. Log in with no addons.
    2. Open the mailbox (then don't touch the frame at all).
    3. Try this script /script SendMail("SapuBank", "Hello", "You're awesome")


    ...and nothing happens. Then I manually visit the second tab of the mailframe ("Send Mail") and try the script again and it works.


    PS: QA3 already had some code in to not put the "open all" button on the mailframe if postal was enabled and I have not changed this.
    Posted in: Lua Code Discussion
  • 0

    posted a message on New Limitations on SendMail
    So it seems as if SendMail() is now disabled upon loading into wow until the player loads the "Send Mail" tab of the inbox frame. Anybody know any more information about this change?
    Posted in: Lua Code Discussion
  • To post a comment, please or register a new account.