LUA Error when using the saved searches drop-down while there's a running search
  • in SearchUI, there's a possibility to trigger a LUA Error by opening (and clicking on items in) the saved searches drop-down while a search is running. (this usually means that the progress bar in the middle of the SearchUI interface is visible).

    this has been bugging me for quite a while, but since it never happens if there is no actively running search... it is easily avoidable by not using the saved searches drop-down until the search finishes...

    Date: 2015-09-06 12:07:35
    ID: 1
    Error occured in: Global
    Count: 1
    Message: ...uc-Advanced\Modules\Auc-Util-SearchUI\SearchMain.lua line 1220:
    Usage: SearchUiSaveName:SetText("text")
    [C]: ?
    [C]: SetText()
    ...uc-Advanced\Modules\Auc-Util-SearchUI\SearchMain.lua:1220: onsel()

  • Wierd - It's actually fetching a value from the wrong dropdown menu.

    E.g. if you're running a Resale search, and you click on the nth item in the Saved Searches menu, it instead returns the nth value from the Price Model dropdown (market, Appraiser, etc.).

    I can't see how it's doing it, yet :(
  • 1. i use the classic UI not the CompactUI... (does this matter though?)

    2. it usually happens when using the General searcher of the SearchUI and i rush to change the search profile while a search is running. Also i've had it happen while in Arbitrage mode or EnchantMats mode, so i think it can happen when using any searcher module, not just the General one.

    i have searches saved for:
    - Ore/bars (type: trade goods, subtype: metal&stone, min. ilvl 50)
    - Leather (type: trade goods, subtype: leather, min ilvl 80),
    - Cloth (type: trade goods, subtype: cloth, min. ilvl 86)...
    and a few other saved searches in there...

    I think it's easier to use the General searcher than the other search modules because it has that "whirlwheel" button to send a fresh search query to the server - the other search modules do not have it and instead rely only on locally-cached data obtained from scans.
  • I think I've figured out what is happening at the end: if you have a SelectBox menu open, and another thread refreshes/redraws a different SelectBox control, the control tables for the first/open SelectBox get overwritten. This is a flaw in the Configator/SelectBox design :( Gonna take some reworking.

    What I haven't figured out is how SearchUI's Search routine is triggering so many repeated refreshes/redraws of the other controls - I'd really like to figure that one out, as we're probably wasting a lot of CPU time doing that!
  • what i noticed in the General searcher is that if i change one of the text input fields while a search is running (e.g. i type something else for item name), and if the other selectors match for items i typed (item type/subtype) the search results immediately reflect what i type in the text fields, even if the text fields contained something COMPLETELY different when the search was started.... so i think that the General searcher and any of the other searcher modules, must be querying ALL the search parameters for EACH and EVERY item when doing the match/comparison tests for search.

    SearchUI should probably use a cached state snapshot of all the search parameters as they were when the search/whirlwheel button was pressed (and clear that cache when the search finishes or is stopped/aborted) but what i noticed that it actually does is that it queries the CURRENT state of the search parameters, and does this query for EVERY item when evaluating whether to include it in the search results or not.

    Querying the current state probably forces a refresh/redraw too, and it should keep doing this, imho - this is why a cached state snapshot of the search parameters is needed.

    When doing a General search with very few restrictions/search parameters set, and the realm AH has over 30 thousand items listed that come back as possible search results - that's going to be a TON of refreshes for ALL the controls (30+ thousand multiplied by the number of the search parameter controls/fields)

    to see this better you should split the SearchUI tab in a separate window and keep the AH window open on the main page, to see the search results in real time as they scroll by.

    e.g. Ore/bar searching mode, using the General SearchUI searcher:
    a) General search parameters: type: trade goods, subtype: metal&stone, min. ilvl 50, max ilvl - use default one (on the left sliders set), nothing typed in the item name text field.

    b) press the whirlwheel button to start a fresh search

    c) while the search is running type "black" (without quotes) in the item name field of SearchUI and do not press enter or click any other buttons

    d) wait a bit for the AH data to refresh, and then notice that the already-running search starts to return only results with "black" in the item name. (the search results in SearchUI)
  • I've updated SelectBox to fix the underlying flaw (Libraries SVN r396).

    Looks like the Refreshes come every time the Results scrollsheet gets updated: actually whenever the scrollsheet is re-sorted SearchUI saves the sort column and direction values. Saving any value to the config forces a refresh.

    Changing settings during a search is unsupported and somewhat unpredictable. Really the whole SearchUI config system needs an overhaul :(
  • would it not be simpler then to just disable / grey out / lock settings change and sort order while the search is running and then unlock them when the search finishes?

    maybe also add a button to force unlock them (with a warning) if the search ending becomes somehow bugged and won't unlock them when it finishes.
Start a New Discussion

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion

norganna's addons network · tf2 warehouse · scrap warehouse · auctioneer addon · gatherer addon · addon forums · rdrct