Curse

I tried Jabob (http://www.curse.com/addons/rift/jabob). Its another Bag Addon. In fact it just makes one big bag out of your bags, there is the same problem with the tooltip postion. It is "solved" there by adding another tooltip at the mousecourser when hover over a item in your bag. So you see two tooltips (One in the upper left corner an one on your courser).

Maybe you can add another tooltip to this addon too? I really love the features of your addon. But the tooltipbug  is really annoying and keeps me of from using this great addon.

I dont have any knowings in making addons and I have no idea if its even possible for your addon too add another tooltip. Just an idea :)

K finally located the source problem which prevented incremental variable storage in

C:\Users\Owner\Documents\RIFT\Interface\Saved\SavedVariables

See this thread for starters

http://www.riftui.com/forums/showthread.php?t=169

On my computer, some windows 7 update in the last few months (since about January 2013) has blocked user programs from writing data into the "Program Files <x86> directory or lower, or, it has never been possible but has somehow been bypassed by some unknown combination of features of  RIFT/Windows 7 until recently. 

I noted the post at the end of the thread linked above which stated it is simpler just to move the RIFT Game directory to a neutral location.  That simpler procedure did not work for me, presumably because the Rift game installation teaches the game itself something about the directory structure it lives in at install time.  I DID have to fully re-install the game in a neutral directory; then saved addon variables began to appear in and operate normally from

C:\Users\Owner\Documents\RIFT\Interface\Saved

and subdirectories thereunder.  This re-installation fix also fixed Super Meter, Simple Meter, ConquestTracker, and so on.  All these addons failed to save variables until I moved RIFT game.  This also solved the issue of twin RIFT sessions interfering with each other (if they ever did), they both now independently save their variables without cross-infection.

The upshot is, this bug can affect any windows 7 Rift addon installation at any time depending, probably, on having Rift in Program Files directory, having Win 7, possibly 64-bit, some absolutely arcane combination of OS updates or maybe just one critical one, and lord knows what else.   I have no idea atm how addon developers can deal with it.

Airtoad

How do you move the tooltip?  Whenever I cursor over an item or click on an item the tooltip appears in the upper lefthand corner of the screen.  Is there a way to move it to where you would like?  

See post above yours.  My "tooltip in the upper left corner of screen" problem, also present for months, disappeared after the solution discussed just above.   Ok, I know it is silly.  But, the cranky misplaced tooltips are now well behaved.  No idea why things are better, unless Rift game itself has user program issues writing into its home directory structure, which I don't believe for a second.  Warning, I was messing around with a LOT of stuff, including massive permission changes throughout "Program Files <x86>"; so if you try to move Rift and it doesn't fix anything, reserve surprise :p.

Airtoad

Quote from airtoad »

See post above yours.  My "tooltip in the upper left corner of screen" problem, also present for months, disappeared after the solution discussed just above.   Ok, I know it is silly.  But, the cranky misplaced tooltips are now well behaved.  No idea why things are better, unless Rift game itself has user program issues writing into its home directory structure, which I don't believe for a second.  Warning, I was messing around with a LOT of stuff, including massive permission changes throughout "Program Files <x86>"; so if you try to move Rift and it doesn't fix anything, reserve surprise :p.

Airtoad

I have Rift installed in a "neutral" place. But the Tooltip is still in the upper left corner >:

Ok, did some work on the two account problem, or, phenomenon possibly.   Here is what I was able to get to happen using my workaround.  It is distinctly possible that if the addon was able to work with the built-in rename of imhobags.lua.new --> imhobags.new, what follows below might not occur.  But what IS true is, this behavior in various forms has been true since January when I began using two accounts.

Account A.  Log in toon 1, do stuff, log out.  Log back in toon 1.. establishes baseline imhobags.lua.. do no activity whatever, so that imhobags.lua in terms of account A is unchanged.  Toon 1 just standing there.

imhobags. lua = 297 kbytes.

While account A is logged in, Start Account B.  Login toon 1 account B.  Do stuff, log out toon 1 account B.

imhobags.lua = 315 kbytes.

Account A continues to be active.  Login toon 2 account B.  Do stuff, log out toon 2 account B.

imhobags.lua =327 kbytes.

Account A continues to be active.  Login toon 3 account B.  Do stuff, log out toon 3 account B.

imhobags.lua = 343 kbytes.

Logout Account A, toon 1.

imhobags.lua = 297 kbutes.. (the same as it was when account A baseline was established.)

Login Account A, toon 1.    All updates to imhobags.lua from the recent account B activity are lost.  No material from the Account B toons, of the sort that is common to all toons on both accounts, is showing on behalf of Account B toons as it would be expected to be.

This appears to be an issue of the sort where a database (imhobags.lua) is shared, but the sharing parties (Rift session #1, and Rift session #2) are unaware of each other's activity, and each assumes it has full ownership of the database.  That said, if the issue of why, at least in my computer, the automagic rename of imhobags.lua.new to imhobags.lua is resolved, it could well alter this behavior.  But I suspect it won't because it appears that imhobags.lua is picked up at the beginning of a session, and if another session picks it up later, alters it for its own purposes, and puts it back, the first session has no knowledge of this.

Hope this info helps.  This is really an interesting set of behaviors!

Airtoad. 

April 9, 2013 - can't get Bags to show the items from any toon on the account other than the one logged in.  This worked well in January.  Tried uninstall, swept C: for all .lua(s) and removed them, fresh install, etc.  Only clue I can give is, when the character icon is queried on any Bags GUI, the only character name shown is the one logged in.  Tried rebuilding Friend's lists, relogging all, etc.  I sure do miss that feature; and hope it isn't my setup that's broken.

Airtoad.

Last update on the original problem.. unable to see any toon's items but those of the one logged in.  Diagnosis to date (April 22, 2013) is that when a toon session ends, Rift+addon are not creating ImhoBags.lua from the temp file ImhoBags.lua.new, in the working directory:

C:\Users\Owner\Documents\RIFT\Interface\Saved\SavedVariables.

 It appears that the .new file is properly created, and if it is manually copied to become a fresh ImhoBags.lua, and this manual operation is done each time another toon session ends, the entire addon function appears normal.   The key, so far as I can figure, is that the means by which Rift+addon determine that the write of ImhoBags.lua.new has been successful (required to then write ImhoBags.lua proper), is/are failing, probably silently.   I guess silently because the addon does not print an error message.  It might be possible to dig further into this if the addon was able to see anything coming back from Rift or Windows, and print a debug error message?

The solution I'm using now which results in apparent seamless and proper function is to install a symbolic link in the working directory.. the link named ImhoBags.lua simply points back to ImhoBags.lua.new.   I can see all toons stuff on both accounts, guild bank works, etc.  Great addon, major when you have 6 master tradeskills.  Thanks to Imhothar for putting up with this and for creating the tool for us.

Airtoad