Not good enough .
if you will see the 4 demands and the final result that should be, you will see why i asked this Q.
** Every user have his own Fav.
** The Fav need to be there for the users also when the session is closed after several days/months/years
** They can add to fav Buyer "b" that don't have or use ID "2222" - they are contradict .
** When they check the Dimensions they are not selected as qv standard, they only add to fav.
** The user need the ability to add ID "3333" to his exist Fav.
At the end the user will be able to select a specific ID or Buyer or all FAV and it will reduce the QVW like a regular selection.
Just like Fav in IE when you have a Folders(Dimensions ) and in it you have the urls(Data-2222/b....)
Excactly for this are bookmarks designed and they could easily handle all your demands unless the selection-status which is quite often necessary to check and more a big advantage then a drawback.
Why creating an own logic and usability? The aim from qlikview is to simplify things but: http://www.brainyquote.com/quotes/quotes/a/alberteins103652.html
I'm not sure if it would be possible to gain a stable solution with your approach - maybe with hidden dimensions and a lot of variables (and bookmarks to save those variables) and set analysis and various trigger to execute actions and/or macros - but I'm sure that the usability would be worser then with bookmarks.
Thanks but ...
This is the simple way for end users to manage their Favourite
It is not simple for the developer.
this is way i need help.