inventory update misfiring

Does anybody know if the Lindens have acknowledged the case where a notecard type of inventory seems to fire the change event whenever its edit box receives focus? I realize they are busy folks, but this is really starting to annoy me, and the Known Issues page is getting stale.

Is there any possible workaround? I'm doubting it but why not ask

zk

eww your right. Open a notecard and close it. causes change type of inventory. Bad Bug. Reporting

EDIT: and can not think of a work around.

Not only just open and close it but it you open it, switch focus and switch back to the notecard. It is a major pain with one script of mine beccasue I open the card, the script starts because of inventory change, I edit and have to wait until the script stops to save the card and it will read it again.

so it is Minimize, Closing and Change of Focus that triggers this. Woohoo hammer the data server!

Ziggy was the first to notice it and post it here on December the 14th. Here is the thread:
/54/d0/154810/1.html

Does it just fire the changed inventory event, or does it change the actual key of the note-card (what I presumed the changed inventory event used to determine when it should fire).

if the case is such that the key does *not* change, you can write a script that keeps track of note-card keys within the object's inventory, and if the key happens to change when the inventory event is fired off, you'll know that it's a real update to the note-card, and not just a false signal.

I have o acess to SL until the 2nd, so I can't test for myself :\

unfortunately the Key is not chaging

Very annoying, I have a vendor that contains a lot of items and needs to update if the inventory changes, it can't easily just do a quick pass to see if it needs to update or not either, so here we had a vendor updating loads, it loads it's notecard, starts up fine, I close the notecard and it switches off again to reload, bah =(

It doesn't even seem to just be the focus either, if you have an item from an object's inventory open then it seems to cause the object inventory (if visible) to refresh constantly on the client's end. Object inventory is an absolute pain at the moment as well, change one thing and you have to wait for the whole inventory to refresh (usually twice) before you can do anything else. Suddenly setting a texture in an object to copy/no-transfer is horrifying, and that's if you've only got one or two to do.
What happened to the client just assuming it's change went through and correcting itself if it didn't? That way was much better and didn't lock up your ability to edit an object's inventory and quadruple the time it takes to do anything with object inventory. ARGH!

the notecard isssue is almost as bad as object recieving large inventory transfers in packets or bunches.
for any object i have that needs to process the inventory as a whole, for things such as duplicate deletion i end up using a combination of changed() and timer().

default {
      timer() {
            llSetTimerEvent(0.0);
            do_somthing();
      }

     changed(integer change) {
           llSetTimerEvent(0.0);
           llSetTimerEvent(15);
     }
}

even noticed times less than 15 secs betwwen timer rounds will fail to be long enough to account for object inventory delays in slower sims.

as far as the notecard issue goes, you could have your items look not just fora changed event, but an acual change in the inventory count, or count of object types
it's only a few more bytes to store really, since count return an integer value.
or, like i did, have inventory handled by a seperate script that uses linked messages to tell the main script when to act.