WoW:UIOBJECT GameTooltip: Difference between revisions

m
m (This revision and previous are available under: CC BY-SA 3.0. See list of authors in previous history below.)
Line 1: Line 1:
{{widget}}
{{widget}}
UI Lua API for a GameTooltip frame type. WoW also creates a default game tool tip frame named "GameTooltip' using this type, which displays the regular in-game tool tip. See also [[XML/GameTooltip]].


== Introduction ==
== Summary ==
Tooltips are notoriously difficult to handle in WoW UI code, as the interaction of GameTooltip methods can be quite complicated. This page has some examples for the use of tooltips, and a collection of advanced points to note about the finer details. For an indepth analysis of GameTooltip methods, see [[Tooltip Pseudo Code]] for a Lua-ish pseudo code representation of every GameTooltip method. See [[Widget API]] for a reference list of all GameTooltip methods.  
Tooltips are notoriously difficult to handle in WoW UI code, as the interaction of GameTooltip methods can be quite complicated. This page has some examples for the use of tooltips, and a collection of advanced points to note about the finer details. For an indepth analysis of GameTooltip methods, see [[Tooltip Pseudo Code]] for a Lua-ish pseudo code representation of every GameTooltip method. See [[Widget API]] for a reference list of all GameTooltip methods.  


Line 9: Line 10:
The game engine assumes that there is a GameTooltip object called GameTooltip, and that it has a number of known fontstrings in it. The GameTooltip:Set___() methods manipulate the object and its children directly and then show the tooltip object. When you mouse over things in the game world, the game engine internally calls the equivalent of :Set____() - not the actual Lua method. In particular, this means that hooked GameTooltip methods will never trigger for engine-generated tooltips. Hooks will however catch all other tooltips generated from the UI itself. For non-item/unit tooltips you will even see :AddLine and :AddDoubleLine calls.
The game engine assumes that there is a GameTooltip object called GameTooltip, and that it has a number of known fontstrings in it. The GameTooltip:Set___() methods manipulate the object and its children directly and then show the tooltip object. When you mouse over things in the game world, the game engine internally calls the equivalent of :Set____() - not the actual Lua method. In particular, this means that hooked GameTooltip methods will never trigger for engine-generated tooltips. Hooks will however catch all other tooltips generated from the UI itself. For non-item/unit tooltips you will even see :AddLine and :AddDoubleLine calls.


=== GameTooltipTextLeft''<num>'' ===
=== GameTooltipTextLeft<num> ===
Each line of text from the game tooltip is represented by one of these objects, replace <num> with the appropriate line number (from 1 to the number of lines returned from GameTooltip:NumLines()). To obtain the text of a line call the [[API FontString GetText|GameTooltipTextLeft''<num>'':GetText()]] function.
Each line of text from the game tooltip is represented by one of these objects, replace <num> with the appropriate line number (from 1 to the number of lines returned from GameTooltip:NumLines()). To obtain the text of a line call the [[API FontString GetText|GameTooltipTextLeft''<num>'':GetText()]] function.


'''Warning''' - this is currently bugged. When a tooltip has 9 or more FontString GameTooltipTextLeft9 and GameTooltipTextRight9 do not exist. These FontStrings are incorrectly named GameTooltipTextLeft1 and GameTooltipTextRight1 duplicating those of the first line. The only reliable way to get the information out of the tooltip is to iterate through its child regions with GameTooltip:GetRegions().
:''Important: this is currently bugged. When a tooltip has 9 or more FontString GameTooltipTextLeft9 and GameTooltipTextRight9 do not exist. These FontStrings are incorrectly named GameTooltipTextLeft1 and GameTooltipTextRight1 duplicating those of the first line. The only reliable way to get the information out of the tooltip is to iterate through its child regions with GameTooltip:GetRegions().''


==== Example: Looping through all tooltip lines ====
;Example
<pre>local function EnumerateTooltipLines_helper(...)
Looping through all tooltip lines
<pre>
local function EnumerateTooltipLines_helper(...)
     for i = 1, select("#", ...) do
     for i = 1, select("#", ...) do
         local region = select(i, ...)
         local region = select(i, ...)
Line 26: Line 29:
function EnumerateTooltipLines(tooltip) -- good for script handlers that pass the tooltip as the first argument.
function EnumerateTooltipLines(tooltip) -- good for script handlers that pass the tooltip as the first argument.
     EnumerateTooltipLines_helper(tooltip:GetRegions())
     EnumerateTooltipLines_helper(tooltip:GetRegions())
end</pre>
end
</pre>


=====Macro Equivalent=====
;Macro Equivalent
<pre>/run for i=1,GameTooltip:NumLines()do local mytext=_G["GameTooltipTextLeft"..i] local text=mytext:GetText()print(text)end</pre>
/run for i = 1, GameTooltip:NumLines() do local mytext = _G["GameTooltipTextLeft"..i] local text = mytext:GetText(); print(text) end


==== Notes ====
;Notes
* The tooltip displayed when the mouse is hovering over players and/or NPCs on the minimap is such that all the units being displayed are actually only on the first tooltip line.  So, if the tooltip showed 4 players, the names are all in the first tooltip line, delimited by "\n".
* The tooltip displayed when the mouse is hovering over players and/or NPCs on the minimap is such that all the units being displayed are actually only on the first tooltip line.  So, if the tooltip showed 4 players, the names are all in the first tooltip line, delimited by "\n".


=== GameTooltipTextRight''&lt;num&gt;'' ===
=== GameTooltipTextRight&lt;num&gt; ===
 
Some tooltips have both left- and right-aligned sections. In order to get at the right-aligned section, use one of these objects instead of a GameTooltipTextLeft. Otherwise, the functionality is identical.
Some tooltips have both left- and right-aligned sections. In order to get at the right-aligned section, use one of these objects instead of a GameTooltipTextLeft. Otherwise, the functionality is identical.


Line 43: Line 46:
The definition of the tooltip in your XML should look like this:
The definition of the tooltip in your XML should look like this:


  <GameTooltip name="MyScanningTooltip" inherits="GameTooltipTemplate">
<GameTooltip name="MyScanningTooltip" inherits="GameTooltipTemplate">
    <Scripts>
  <Scripts>
      <Onload>
    <Onload>
        self:SetOwner(WorldFrame, "ANCHOR_NONE");
      self:SetOwner(WorldFrame, "ANCHOR_NONE");
      </Onload>
    </Onload>
    </Scripts>
  </Scripts>
  </GameTooltip>
</GameTooltip>




When actually using the tooltip in your code, you need to do:
When actually using the tooltip in your code, you need to do:


  MyScanningTooltip:ClearLines()
MyScanningTooltip:ClearLines()
  MyScanningTooltip:SetX(arguments)
MyScanningTooltip:SetX(arguments)


where SetX could be SetInventorySlot, SetBagItem, SetAction, SetUnitBuff etc. The explicit call to MyScanningTooltip:ClearLines() is necessary becuase a SetX call usually doesn't clear the tooltip if called with invalid arguments, e.g. an empty bag slot or nonexistent buff. Care must be taken so that MyScanningTooltip:Show() or MyScanningTooltip:Hide() doesn't get called at any time, otherwise the tooltip becomes unusable. Note that the way SetOwner was called, the tooltip will never be visible on the screen, and therefore it's not necessary to hide it.
where SetX could be SetInventorySlot, SetBagItem, SetAction, SetUnitBuff etc. The explicit call to MyScanningTooltip:ClearLines() is necessary becuase a SetX call usually doesn't clear the tooltip if called with invalid arguments, e.g. an empty bag slot or nonexistent buff. Care must be taken so that MyScanningTooltip:Show() or MyScanningTooltip:Hide() doesn't get called at any time, otherwise the tooltip becomes unusable. Note that the way SetOwner was called, the tooltip will never be visible on the screen, and therefore it's not necessary to hide it.
Line 62: Line 65:
Instead of the above, here is an alternative solution. It is sufficient to have this in your XML:
Instead of the above, here is an alternative solution. It is sufficient to have this in your XML:


  <GameTooltip name="MyScanningTooltip" inherits="GameTooltipTemplate"/>
<GameTooltip name="MyScanningTooltip" inherits="GameTooltipTemplate"/>


Each time you want to use the tooltip however, you must explicitly set the owner like this:
Each time you want to use the tooltip however, you must explicitly set the owner like this:


  MyScanningTooltip:SetOwner(UIParent, "ANCHOR_NONE")
MyScanningTooltip:SetOwner(UIParent, "ANCHOR_NONE")
  MyScanningTooltip:SetX(arguments)
MyScanningTooltip:SetX(arguments)
  ... extract information from the tooltip ...
... extract information from the tooltip ...
  MyScanningTooltip:Hide()
MyScanningTooltip:Hide()


This solution is safer and more robust to potential changes to tooltip behaviour in future patches. However, this solution incurs significant performance penalty. Repeatedly calling MyScanningTooltip:SetOwner in an OnUpdate handler can cause significant frame-rate drop. Hence this solution is recommended for tooltip scans that occur in response to for example key presses, whereas the previous solution is recommended for repeated, frequent scans.
This solution is safer and more robust to potential changes to tooltip behaviour in future patches. However, this solution incurs significant performance penalty. Repeatedly calling MyScanningTooltip:SetOwner in an OnUpdate handler can cause significant frame-rate drop. Hence this solution is recommended for tooltip scans that occur in response to for example key presses, whereas the previous solution is recommended for repeated, frequent scans.
Line 108: Line 111:
* Showing the parent of the tooltip causes Show to be called on the tooltip.
* Showing the parent of the tooltip causes Show to be called on the tooltip.
* It is therefore recommended practice to not set a parent to your tooltip, and especially not UIParent.
* It is therefore recommended practice to not set a parent to your tooltip, and especially not UIParent.
* A tooltip that has a parent="<parentname>" specified in its XML definition can't call SetOwner in the tooltip's <OnLoad> handler. (unconfirmed, seems to be true in some cases, so best avoid it)
* A tooltip that has a parent="<nowiki><parentname></nowiki>" specified in its XML definition can't call SetOwner in the tooltip's <nowiki><OnLoad></nowiki> handler. (unconfirmed, seems to be true in some cases, so best avoid it)