Tags overwritten

Please check the FAQ (https://www.xyplorer.com/faq.php) before posting a question...
Post Reply
Ajibandi
Posts: 2
Joined: 13 Dec 2017 15:24

Tags overwritten

Post by Ajibandi »

Hi,

Not sure if this this is a bug or if it is working as intended. If the latter, any suggested workarounds?

I work with multiple virtual desktops, so have different instances of xyplorer on different desktops. If I set any tags in one instance and close it, those tags are overwritten (removed) in tags.dat when I close a second instance that was opened before the tags were set in the first instance.

Suggestions?

Thanks

highend
Posts: 13309
Joined: 06 Feb 2011 00:33

Re: Tags overwritten

Post by highend »

Welcome to the forum.

This is not a bug, therefore I'll move this thread to questions and answers

If you have either (or both) of these settings checked:
Configuration | General | Startup & Exit | Autosave settings after this many minutes
Configuration | General | Startup & Exit | Save settings on exit

Then your "second" instance will overwrite what the first (closed) wrote to the tag.dat file
because no instance reads in any changes automatically.

The only workaround is: After one instance saved any amount of tags, you need to execute
this menu command on all other still running instances:
Menu - Favorites - Reload Tags Database

Or use a button with a command id if you want a one click action:

Code: Select all

#887;
Apart from that: An utility that would watch all instances of running XY processes
and when one closes it would send the #887; command to all other running ones...
One of my scripts helped you out? Please donate via Paypal

highend
Posts: 13309
Joined: 06 Feb 2011 00:33

Re: Tags overwritten

Post by highend »

Try the attached tool...

Extract the archive
Open the .ini file with a reasonable text editor
Put the absolute path to YOUR tag.dat database file into DB_Path=
Make sure that:
- You save the file with UTF-8 BOM encoding
- It has the same base name as the .exe file

Execute the .exe now. When you want to close it,
left or right click the tray icon, choose "Exit"

What it does?
It monitors the last modified date of the the tag.dat file.
Whenever this changes it looks how many XY instances are
currently running and compares it to the last value (on
the last tag.dat change). If there are less XY instances
it will send the script "::#887;" to every still running XY instance,
effectively forcing them to reload the tag.dat database...
Attachments
XY_Tag DB Watcher_v0.1.zip
(80.58 KiB) Downloaded 20 times
One of my scripts helped you out? Please donate via Paypal

bdeshi
Posts: 4249
Joined: 12 Mar 2014 17:27
Location: Asteroid B-612 / Dhaka
Contact:

Re: Tags overwritten

Post by bdeshi »

on the other hand, tags updated in the still running instances will be forgotten. :ninja:

it's a can of tangled worms!
Icon Names | Onyx | Undocumented Commands | xypcre
[ this user is asleep ]

highend
Posts: 13309
Joined: 06 Feb 2011 00:33

Re: Tags overwritten

Post by highend »

Ofc this requires the user to not "run around" with unsaved tags in more than one instance :mrgreen:

Even if we had another param for get(), e.g. get("unsaved") which would return a binary combined
value from what savesettings accepts, I could only display a message that there is more than one
instance that has tags to save. Although, each instance could export it's own new tags, reload the
db and reimport their previously unsaved tags. But still...

The tool was written only for this specific need (closing instance -> all others don't reload the tag.db)
but ofc it could be done to monitor the tag.dat and on each update, all other instances reload the
db, only the one (topmost XY window) that saved it, is excluded...
One of my scripts helped you out? Please donate via Paypal

Ajibandi
Posts: 2
Joined: 13 Dec 2017 15:24

Re: Tags overwritten

Post by Ajibandi »

Thanks so much for the tool!!

It fits my use case perfectly since I don't switch between instances setting tags but almost always close out a window after messing with tags within it before interacting with other instances (residing in other workspaces).

Post Reply