Bug Mall Purchase GUI "search" fails after timein

[Veracity]

This has bothered me for a long time.
Now I can easily reproduce it, so...

Go to Purchases
Enter seal tooth as Item to Find
Hit the Search button
(You get a list of stores with that item on sale)
Force a timein
Enter turtle totem as item to find
Hit the Search button
KoLmafia does another search for a seal tooth.

I have also seen it clear the Item to Find text field and do a search on, essentially "all items".

 

[MCroft]

I've absolutely seen the latter.

I don't know what to do about it, except maybe not allow searches for every item from the gui.

 

[MCroft]

What are your steps to recreate? I've been looking at this and it's acting annoyingly correctly.

There is also unexpected behavior around the field related to selection. I can't select all (CMD-A) in the Item to Find field. Is it filtering out keypress. I can copy and paste, and if I shift-arrow it selects, but I'd like to use cmd-a/type to clear and start my search over.

I have no idea if that's related (yet).

 

[Veracity]

How to make the MallSearchFrame look for "every item":

Run KoLmafia
Login
Go to the Mall Search Frame
In the "Item to Find" field - which has keyboard focus - hit the "return" key.
(You get a list for all items in the mall.)

Something else I noticed:

I have "cachedMallSearches" set to true. This controls the Purchase frame's "searchField".
That means that every time I do a search, it adds it to the "Item to Find" combo box, which is an EditableAutoFilterComboBox
If false, that would be an AutoHighlightTextField

The gCLI has an "entryField" which is an AutoHighlightTextField

Both the gCLI and Purchases frame have a "FocusListener" which will select their respective input fields when they get focus.

Ii stuck in logging for MallSearchFrame and AutoFilterComboBox for focusGained and focusLost


From AdventureFrame, select the Purchases tab:

Focus gained
NameInputListener focus gained
NameInputListener focus lost
NameInputListener focus gained

Go to Terminal window to copy the output:

NameInputListener focus lost

Go back to KoLmafia GUI (Purchase tab is selected)

NameInputListener focus gained

Go to gCLI tab

NameInputListener focus lost

Go back to Purchases tab:
[

Focus gained
NameInputListener focus gained
NameInputListener focus lost
NameInputListener focus gained

That is just what you (I'd) expect: The Purchases frame detects when it gains or loses focus and so does its input field.

Back to gCLI tab:

NameInputListener focus lost

execute "timein"
Back to Purchases tab:

Focus gained

Whoah. The "Item to find" field is still selected - blinking cursor - but it did not get a focus event.

I typed in "stolen accordion". I also was logging "key events" - and none were logged.
I ended with the "return" key - and instead of executing the search, it cleared the input field.
I typed "stolen accordion" again again and hit the "search" button:
It cleared the Item to Find field and the following logging in the Purchases frame:

Action Confirmed on search field
eac.getSelectedItem() = null
eac.getText() = null
eac.getSelectedItem() = null

The EditableAutoFilterComboBox widget was no longer connected after the timein; it did not accept text, it did not handle the "return" key, and when I had text and used to "search" key, that button got a "null" for the text and decided that meant it should search for all items.

I'm going to try the same thing with "cachedMallSearches" set to false.

 

[Veracity]

And the result is: the AutoHighlightTextField works just fine.
I put in logging for that and switching back and forth between the gCLI and Purchases logs "focus lost" and "focus gained" just as expected, and when I do a "timein", going back to Purchases works fine and the AutoHighlightTextField is handling focus and input just as before.

I conclude that this issue happens only if "cacheMallSearches" is true and an EditableAutoFilterComboBox is involved.
Easy workaround for ME is to set "cacheMallSearches" to false, since I never even use that combo box.
But fr those who do use it, we should fix it.

At the moment, I can't even imagine how the widget would simply get disconnected. Timing in will reset and reload preferences - temporarily setting "cacheMallSearches" to false (its default) and back to true, but that should have no effect on the already constructed MallSearchFrame.
Right? Surely not?

 

[MCroft]

I do (or used to) use that frame, but the bad behavior drove me away. I'd also like to get it fixed.

So, afaict, this.searchField gets based on the preference when the panel is instantiated, which I think would mean that its not getting changed if the user changes the preference (so, that is a "requires restart" pref?)

 

[MCroft]

Given the improvements in Asym's serving capacity, maybe the caching was a compromise we can decide we've grown out of. Not sure if that was the main reason, the comments from that time are not helping me figure it out.

 

[fronobulax]

Given the improvements in Asym's serving capacity, maybe the caching was a compromise we can decide we've grown out of. Not sure if that was the main reason, the comments from that time are not helping me figure it out.

Once Upon A Time it was a stated design/implementation goal to "reduce server hits". That was usually understood to mean if a user could do something with KoLmafia there would be fewer KoL server hits than if the same thing was done manually. So caching mall prices was NOT a compromise based upon server performance but a deliberate decision to reduce server hits.

Years later and on a practical basis it seems that most users and scripts tend to avoid using cached prices. There is a belief that prices are volatile enough decisions must be made on the most recent information. So if cached prices are causing other problems I'd consider eliminating them. Before doing so I would try and get some feedback because there have been cases where similar improvements destroyed the KoLmafia experience for unstable, unreliable, slow, laggy or metered connections.

 

[Veracity]

You misunderstand. We are not talking about caching mall prices. We are talking about caching the search strings you type into the “Find an Item” search box on the Purchases frame.

Without cacheing:

Type “seal tooth”
Type “turtle totem”
Type “seal tooth”
…

With caching:

Type “seal tooth”
(The search field, which is a combo box, has one entry.)
Type “turtle totem”
(The combo box has two entries.)
You can now select “seal tooth” from the dropdown, instead of typing it, if you wish.

The issue is the widget which handles that - adding new entries to the dropdown when you make new searches.

This has nothing to do with server hits. It is purely a GUI issue.