Addon system bug reports

[dOxxx]

I have a Mask frame (ScrollView) with another Frame (ScrollBar) parented to the ScrollView frame and located inside the ScrollView frame. I've attached handler functions for LeftDown, LeftUp, LeftUpoutside and MouseMove to the ScrollBar frame. When I left click and drag inside the ScrollBar frame, if I move the mouse out of the ScrollBar frame into the ScrollView, I get correct X and Y parameters in the MouseMove handler. However, if I move the mouse (while dragging) outside of the ScrollView frame, I get X and Y values of -1000000000 in the MouseMove handler.

Is this intended behaviour?

[dOxxx]

LRW_TestWindow = UI.CreateFrame("RiftWindow", "LRW_TestWindow", context)
LRW_TestWindow:SetPoint("TOPLEFT", UIParent, "TOPLEFT", 100, 100)
function LRW_TestWindow.Event:LeftDown()
  print("LeftDown")
end

This prints nothing when I click in the RiftWindow frame.

I've worked around the problem with a translucent frame on top of the RiftWindow frame which gets the events and moves the RiftWindow frame.

[Levva]

SetLayer showing odd behaviour. I'm trying to create a tooltip and have it on top of bars however the order the layers are shown is not honoring what is set in code. see http://forums.riftgame.com/beta-addo...-setlayer.html

I'm not entirely sure what the common factor is that determines how the ordering works. However there definitely seems to be a bug with the way a fixed layer frame is displayed when overlaid over another frame. SetLayer should be forcing things with a higher layer number to be in front of a frame with a lower number but this isn't always getting honored.

[ZorbaTHut]

LRW_TestWindow = UI.CreateFrame("RiftWindow", "LRW_TestWindow", context)
LRW_TestWindow:SetPoint("TOPLEFT", UIParent, "TOPLEFT", 100, 100)
function LRW_TestWindow.Event:LeftDown()
  print("LeftDown")
end

This prints nothing when I click in the RiftWindow frame.

I've worked around the problem with a translucent frame on top of the RiftWindow frame which gets the events and moves the RiftWindow frame.

The issue here is that RiftWindow has two children windows, the Border and Content, and the Border is set by default to trap mouse events. Either modify the events on :GetBorder() or do what you did

[dOxxx]

The issue here is that RiftWindow has two children windows, the Border and Content, and the Border is set by default to trap mouse events. Either modify the events on :GetBorder() or do what you did

I can't seem to modify the events on the border:

local testWindowBorder = LRW_TestWindow:GetBorder()
function testWindowBorder.Event:LeftDown()
    print("LeftDown")
end

Gives me an error "Unknown event LeftDown".

EDIT: Seems to work on PTS though.

[dOxxx]

This is a minor nitpick, but comparing the spacing of default UI windows such as the Quest Log and Character windows, it looks like the Content frame of the RiftWindow frame is a little too close to the border. Could probably stand to come in a few pixels. Otherwise, if you have a frame which fills the content frame, it overlaps the border art slightly at the top and comes too close at the other edges to look nice.

[dOxxx]

RiftWindow Border frame doesn't have GetParent function. Or perhaps the "self" implicit variable in an event handler attached to the Border frame is not correct.

  local window = UI.CreateFrame("RiftWindow", "LW_Window", context)
  local border = window:GetBorder()

  function border.Event:LeftDown()
    self.leftDown = true
    local mouse = Inspect.Mouse()
    self.originalXDiff = mouse.x - self:GetLeft()
    self.originalYDiff = mouse.y - self:GetTop()
  end
  function border.Event:LeftUp()
    self.leftDown = false
  end
  function border.Event:LeftUpoutside()
    self.leftDown = false
  end
  function border.Event:MouseMove(x, y)
    if not self.leftDown then
      return
    end
    self:GetParent():SetPoint("TOPLEFT", UIParent, "TOPLEFT", x - self.originalXDiff, y - self.originalYDiff)
  end

I worked around this by using 'window' as an upvalue in the MouseMove function instead of self:GetParent().

[ZorbaTHut]

I can't seem to modify the events on the border:

local testWindowBorder = LRW_TestWindow:GetBorder()
function testWindowBorder.Event:LeftDown()
    print("LeftDown")
end

Gives me an error "Unknown event LeftDown".

EDIT: Seems to work on PTS though.

Ah, yeah, forgot about that - the Border and Context elements were kind of hacked in on the live server. The PTS has a major cleanup of that code. On live, the overlay is going to be the only way you can accomplish what you want.

[Rumil]

I created parser to generate a LUA Table from the Rift Items.XML file. It looks like this:

RiftItems = {

["AAE6838D0201AEC0D6C9072C78"] = { 
	["ItemKey"] = "AAE6838D0201AEC0D6C9072C78",
	["English"] = "Venerable Hammer of the Warfront",
	["Value"] = "937",
	["Rarity"] = "Rare",
	["Icon"] = "item_icons\1h_mace_079",
	["IsAugmented"] = "False",
	["Slot"] = "OneHand",
	["WeaponType"] = "1h_mace",
	["MinimumDamage"] = "18",
	["MaximumDamage"] = "33",
	["Speed"] = "2.700000",
	["Range"] = "3.000000",
	["Strength"] = "7",
	["Dexterity"] = "5",
	["Endurance"] = "4",
	["RequiredLevel"] = "20",
	["RunebreakSkillLevel"] = "1",},

["B6BBBD1F01D2D6F7D805663C"] = { 
	["ItemKey"] = "B6BBBD1F01D2D6F7D805663C",
	["English"] = "Templar's Bow of the Sinister",
	["Value"] = "2350",
        ....

As you can see it parses the different item types and generates the specific properties for armor, weapons, etc. The resulting file is 23K (nice slimdown compared to the 500K XML).

When I tried to load this file into a Rift addon, I had a rather unexpected surprise:

http://www.imgplace.com/viewimg593/7...addonerror.png

ERROR: Object has more than 65536 constants

I realize people probably haven't thrown many large tables at the addon system yet, I'd just like to know if this is a fixable limitation or are we stuck at 65K variables? Imagine writing an auctioneer addon with a limit of 65K table entries

A zip with the Lua table is available here

For more details on why I'm creating this table, see this thread

[Naifu]

ERROR: Object has more than 65536 constants

Good old unsigned integer. Modern IT runs into the same old problems forever

Cheers
N.

[dOxxx]

Yeah that may be a limitation of the LUA implementation. You'll probably have to split the tables into subtables, grouping by the first N characters of the original string ID.

[dOxxx]

When in a group and you logout and login again, the Unit.Available event fires with both player and group unit IDs. However, calling Inspect.Unit.Detail for the group IDs while in the event handler function returns a table with only name, player and role fields. None of the other fields like calling, etc. are set.

[Snowreap]

the following code doesn't work as you'd expect on first glance:

local SV = {}
MyAddonName_SavedVariables = SV

on the surface, the intent is fairly obvious: publish "MyAddonName_SavedVariables" to the global namespace so that the RIFT addon loader can read from and write to it, and also create a shorter local name for internal addon use.

what's not obvious is, when the RIFT addon loader sees that you have a SavedVariables file, it reads that file into a new table, then changes the "MyAddonName_SavedVariables" binding to point to that new table. but your addon's local "SV" binding remains unchanged, pointing to the old table.

there are two unfortunate outcomes here:

1. unless you correct for this by either avoiding the use of a local alias, or making sure you update it, then saved variables won't work. updating the alias isn't hard (just a matter of putting "SV = MyAddonName_SavedVariables" somewhere where it will run after your saved variables are loaded), but you have to know to do it.

2. when you test or release a new version of an addon, you can't add new entries to your SavedVariabiables table with default values and expect them to stick -- any default values your addon defines are used only if there is no save file at all. but if a save file exists, all your defaults are discarded and a new table is loaded containing only what was in the save file and nothing else.

this may be another "not really a bug, but needs to be documented better" situation. I can guess why this is happening, and a "fix" may be more trouble than it's worth -- a shallow table copy isn't good enough, if you consider a case like this:

MyAddonName_SavedVariables = {
  UI = {
    MainWindow = {
      TitleBar = {
        DefaultColor = {
          r = 0,
          g = 0,
          b = 0.5,
          a = 0.5, -- this value is new in this version, and addon title bar won't appear without it
        }
      }
    }
  }
}

-ken

[dOxxx]

RiftButton seems to include innate spacing around the actual drawn edge of the button. At the top and left this seems to be ~6. At the bottom, it seems to be ~12.

It would be nice if the height (and width) of the frame were to better represent the actual drawn button. This makes automatic widget layout code easier to produce nice looking results.

[Levva]

2. when you test or release a new version of an addon, you can't add new entries to your SavedVariabiables table with default values and expect them to stick -- any default values your addon defines are used only if there is no save file at all. but if a save file exists, all your defaults are discarded and a new table is loaded containing only what was in the save file and nothing else.

I've noted this behaviour and my solution is as follows :

		
    BossReady.SetDefaults()
    if BossReady_Settings then
        for k,v in pairs(BossReady_Settings) do 
            BossReady.saved[k] = BossReady_Settings[k]
        end
    end

First call copies BossReady.saved with default values ie: same as your SV. I prefix everything in my code with the addon name to give AddonName.value or AddonName.function. This ensures that the code is not leaking to global space.

BossReady_Settings is the table loaded by RIFT addon loader. So the effect is to fill the table of used values ie: BossReady.saved with all the defaults including any new ones in this release. Then to overwrite the defaults with the values from the users saved variables if they exist. This means that you DO get all new defaults + old saved variables.

Save routine remains unchanged as

BossReady_Settings = BossReady.saved

Hope this helps. Not ideal I know but easily fixed with the above solution.