• 0

    posted a message on What's the proper way to submit a patch for an existing issue?
    Done and done. Thanks!
    Posted in: General Chat
  • 0

    posted a message on What's the proper way to submit a patch for an existing issue?
    While working on one of my own addons, I ended up needing to add a feature to the AceGUI-3.0 EditBox widget, one which it turns out has been requested before. I'd like to submit my changes to the Ace-3.0 team for consideration, but I can't seem to find docs on the "proper" way to do this. There's mention of submitting a patch via the issue tracker, but it also says (paraphrased) "one ticket per issue".

    So how's best to submit my patch? Inline as a comment on the original issue? "Duplicate" issue? Attachment here on the forum?
    Posted in: General Chat
  • 0

    posted a message on AceConfigDropdown-3.0?
    I see the folder for it in the repository, and and the "dropdown" uiType in AceConfig-3.0, but of course the repository folder is empty and the include is commented out. There seems to be little to no info on the site or in the forums, though (that I've found, anyway). Has this library been canceled? Or has development just not started yet?

    I don't actually have any pressing need for it at the moment — I just wanted to make sure my options table worked reasonably with all uiTypes. I take it, though, that I shouldn't worry about dropdowns for now?
    Posted in: Libraries
  • 0

    posted a message on Adding AceGUI widgets to Blizzard frames?
    Well, I ended up digging into the AceGUI source. :D

    I turns out that sliders, at least, don't use their "parent" property, so I was able to attach one to a raw frame just by using the "SetParent()" method of its frame:

    local slider = AceGUI:Create("Slider")
    slider.frame:SetParent(CompanionModelFrame)
    slider:SetPoint("TOPRIGHT")
    slider:SetSliderValues(0,5,1)
    Posted in: Lua Code Discussion
  • 0

    posted a message on Adding AceGUI widgets to Blizzard frames?
    I'm trying to add a slider control to the Pet tab in the character frame. I'm already using AceGUI to put my addon's settings in the Blizzard options frame and the AceGUI widgets are considerably easier to work with than the raw Blizzard widgets, so I'd prefer to go that route, if I can.

    However, the AceGUI tutorial only covers adding widgets to AceGUI frames, specifically via the :AddChild() function, which isn't present on raw frames. Before I go digging in to the AceGUI source, does anyone know if there's a simple way to use AceGUI widgets with raw frames?
    Posted in: Lua Code Discussion
  • 0

    posted a message on Using the Blizzard error frame?
    Heh, couldn't find it for lack of an "s" (I was looking for UIErrorFrame).

    Thanks! ;D
    Posted in: Lua Code Discussion
  • 0

    posted a message on Using the Blizzard error frame?
    I'm getting back into addon development after a very long hiatus (pre-2.0), and can't figure out / remember how to use the built-in Blizzard error frame. (The one which displays, e.g. "Not enough mana", "You can't mount here", and so forth.)

    I've poked around on WoWWiki and in the Ace documentation (my addon is using Ace-3.0), as well as searching Google and the forums, but I can't seem to find any info. I suspect I'm not searching using the right terms; at this point, my best guess it that it isn't really called the "error frame". ;)

    Can anyone point me in the right direction?
    Posted in: Lua Code Discussion
  • 0

    posted a message on InfiniBar-2.0 - Official Thread
    Quote from DarkRyder »

    • add a DogTag which allows a button to be addressed based on the name of its bar and its position on that bar (e.g. [font=monospace][FreeSlots(BtnRef("Bag Bar", 1))][/font]). This has the additional advantage of not being affected by changing UIDs and feels a lot less klugy.


    Okay, I finally got off my lazy butt and coded this, too. I've started using it instead of [font=monospace][BtnUID][/font] on my bars and it feels a lot cleaner.

    DogTag:AddTag("InfiniBar2", "BtnRef", {
    	code = function(barname, btnnum)
    		for i = 1, #InfiniBar2.barList do
    			local bar = InfiniBar2.barList[i]
    
    			if bar.bardata.name == barname then
    				return bar.btnList[btnnum].btnname or "Unknown Button"
    			end
    		end
    
    		return "Unknown Bar"
    	end,
    	arg = {
    		'barname', 'string', "",
    		'btnnum', 'number', 1,
    	},
    	ret = "string",
    	static = true,
    	doc = "Returns a reference to the specified button. This can be used with other IB2 tags to get information about buttons other than the current one.",
    	example = '[BtnNum()] => "1"; [BtnNum(BtnRef("Main Bar",4))] => "4"',
    	category = "Information"
    })
    Posted in: General AddOns
  • 0

    posted a message on InfiniBar-2.0 - Official Thread
    I've been playing with my InfiniBars today and ended up coding an extra DogTag that I found very useful ? [BtnUID]. The idea is to expose IB2's internal UID for a button so that it can be referenced in another button's text substitutions. For example, I have the following text substitution on my backpack button: [font=monospace][FreeSlots - FreeSlots("IBBag Bar_1")][/font] "Bag Bar" is the name of my bag bar, of course, and 1 is the UID for the button displaying my soul shard bag. This way, the free slots count on my backpack ignores empty slots in my shard bag (which can't be used for anything else). The DogTag call I used is as follows:

    DogTag:AddTag("InfiniBar2", "BtnUID", {
    	code = function(btnuid)
    		return string.gsub(btnuid, ".+_", "") or "?"
    	end,
    	arg = {
    		'btnuid', 'string', "0",
    	},
    	ret = "string",
    	static = true,
    	doc = "Returns the unique ID of the button. This can be used with other IB2 tags to refer to other buttons. To do so, pass \"IB<bar>_<UID>\" as an argument.",
    	example = '[BtnUID()] => "1"; [ItemCount("IBbag_bar_1")] => "14"',
    	category = "Information"
    })


    I then have [font=monospace][Alt and BtnUID][/font] in the default substitutions for each of my bars, so that I can see all the UIDs by holding the Alt key.

    Pros:
    • Allows the display of buttons to be linked together in a variety of ways.
    • UIDs are consistent across reloads.

    Cons:
    • UIDs are not necessarily consistent before and after configuring buttons (you have to [font=monospace]/console reloadui[/font] to stabilize them).
    • It's a bit kludgy.

    Alternatives:
    • Display the button UID in the tooltip.
    • add a DogTag which allows a button to be addressed based on the name of its bar and its position on that bar (e.g. [font=monospace][FreeSlots(BtnRef("Bag Bar", 1))][/font]). This has the additional advantage of not being affected by changing UIDs and feels a lot less klugy.
    Posted in: General AddOns
  • 0

    posted a message on Automaton
    Quote from Jesamyn »

    Bags & Merchants does this and nothing else.


    And it does the job admirably. Still, I prefer to avoid having hordes of infrequently-updated mini-addons when well-supported consolidated ones exist and thought the feature would fit well with Automaton.
    Posted in: General AddOns
  • 0

    posted a message on Automaton
    Great mod! A couple of suggestions for the future:

    1. Set it up as a Package so that modules can be disabled from the AddOn window.
    2. Add an optional (customizable?) message for refusing invites/duels/etc. I currently use DeclineDuels rather than Wuss because it /tells the other person "I do not wish to participate in duelling." Thus, they do not spam me with duels trying to figure out why they're rejected so quickly. ::)
    3. Add a module to automatically open all (or all non-special? non-ammo?) bags when visiting a bank/vendor/mailbox/AH/...
    Edit:
    4. Perhaps add an option to Sell for getting rid of soulbound stuff which can't be used? (e.g. soulbound Plate rewards for cloth-bearing classes &c.)

    Thanks for writing this! A lot of these are things I've always wished for, but didn't know could be fully automated.
    Posted in: General AddOns
  • 0

    posted a message on DogTag-1.0 suggestion -- callback functions
    I'm writing an addon which uses DogTag-1.0 and I find myself wishing there were some way for my addon to be notified whenever DogTag updates my frame's FontStrings. I briefly scanned the DogTag code before work this morning and it looked like it might not be difficult to set up callback functions. Ideally, one would be able to register a callback on a unit, frame, FontString, or even an arbitrary string of code, e.g.:

    DogTag:RegisterCallbackCode("[CurXP]/[MaxXP]", "player", func)
    
    DogTag:RegisterCallbackFrame(myframe, func)
    
    DogTag:RegisterCallbackString(myfs, func)
    
    DogTag:RegisterCallbackUnit("targettarget", func)


    Does this appeal to anyone else?
    Posted in: Libraries
  • 0

    posted a message on DogTag-1.0 unit registration
    I'm curious how DogTag-1.0 handles strings which reference multiple units using [tag#unit] when :RegisterFontString() only allows you to specify a single unit for registration. For example, would something like the following (no guarantees it's valid -- I'm new at this ;D) update correctly when the player's level changes?

    dt:RegisterFontString(myfs, myframe, "pet", "[Level:~IsEqual([Level#player])?Text([CurXP]/[MaxXP] ([Level]/[Level#player]))]");
    Posted in: Libraries
  • To post a comment, please or register a new account.