Question - Reliably closing ItemDisplay

[rouneq]

Writing for MQ2 (Next eventually, but not ready to switch yet).

Having a devil of a time to always get an ItemDisplay window to close. Should be simple. /invoke ${Window[ItemDisplayWindow].DoClose} The problem is there are times (often) where MQ doesn't recognize said window is, in fact, open. /echo ${Window[ItemDisplayWindow].Open} reports FALSE when one is plainly visible. Alternatives like /notify ItemDisplayWindow 0 close which are in the doco (https://www.redguides.com/docs/projects/macroquest/reference/commands/notify/) just flat out do nothing (certainly the window doesn't close and no messages are given in the MQ window). Something like /notify ItemDisplayWindow CloseButton leftmouseup should also work, but MQ tells me CloseButton isn't a child of the window. And truly, /window ItemDisplayWindow doesn't list anything resembling a close button. But one is there anyway with a nice little tooltip to click it to close. Even if I had the correct name for the child element, I'm not certain this will work. The only thing that works "always" is /keypress esc. But this relies on the user having not turned off 'ESC to Close. I'm reluctant to rely on this.

What's really puzzling is that if I get data from the window (e.g., /varset itemName ${Window[ItemDisplayWindow].Child[IDW_ItemInfo1].Text}), it's always what is expected. It seems like the UI just gets in a bad state with respect to correctly identifying the presence of this window and will only report properly after a /reload. But since I'm expecting the UI to be in a certain state at the start of my macro, I can't just issue one and wait (plus it would be rude to the user).

Am I missing something here?

 

[kaen01]

itemdisplay window can have up to 6 visible windows and i think brainiac mentioned it has 2 more than that behind the scenes.
what you are experience is that its not properly targeting the correct one for your closing

also use thise for your macroquest documentation, its the newest and most updated, and will recieve more regular updates than the wiki. https://docs.macroquest.org/

try using the windowstate command

/windowstate ItemDisplayWindow close

 

[rouneq]

Thanks. This fed into another question on my mind which relates to cycling through the "open" ItemDisplay windows. Ideally I'd like to only close the ones my macro opens. Currently, I have it going through looking for open windows by checking if the item name has a length and then closing them before I start my main processing. It's not what I want to do (again, rude to the user), but since there doesn't seem to be a way to get all available ItemDisplay windows as a list, I'm left with it as a fallback. If there are non-visible ItemDisplay windows, I'd rather not mess with them either.

 

[rouneq]

And...it's those hidden windows that are causing me grief. Even though I have just opened one, it's still reading data from the older, hidden window. Sadly, /windowstate ItemDisplayWindow close didn't work either. And even /keypress esc failed.

 

[kaen01]

${DisplayItem[0-5]} cycle through those 6, and match the name of the item or itemid with the one you opened

 

[rouneq]

Good info. Can save a bit of work I was doing in the macro to get item ID. However, this corresponds to the info about the item and not the actual window open for the item. And there can be duplicates. In my case, two of the DisplayItem sets were for the same item. Unfortunately, this doesn't help me close the the specific ItemDisplay window opened by the macro. The other bit that concerns me is duplicate names. If I'm iterating through an alphabetical list of items, how do I distinguish the first item from the second (or fifth). I'm trying to get the ID for each item as a mean of differentiating those duplicates.

 

[rouneq]

Last update: kaen, it didn't dawn on me looking at your comment that [0-5] was optional. DisplayItem seems to reliably always be the info for the last window opened. I'm using the data from this TLO to go through and do the processing I'm after.

I'm still having to rely on /keypress esc to close the window, but even if that is disabled, it's only six windows cluttering the screen. I can live with that for my purposes. Hopefully others can as well when I post the macro after I'm finished testing.

Thanks again for the help.