Utility to save desktop icon positions?

[mfilos]

Because it's my CF mounted on WinUAE and these are Windows disks mounted for easy transfer (without disk.info)

[AMIGASYSTEM]

If you want you can make them clearly visible with "IconGhostingOff," which you can find in PeterK's IconLib package

[mfilos]

Yes I know mate. I don't mind having these ghosted though

[EctoOne]

Originally Posted by mfilos

Probably has to do with the filename being 34-35 characters? (I have 50 characters in my Workbench Prefs and filename indeed is correct - checking from workbench or DOpus).

Your guess is as good as mine. DirII is pretty old, so there is a good chance that it can't handle long filenames. LIST doesn't cut off the filename. At least you're getting an error message. And I really don't know if I want to search another alternative which works with long names and kind of ignores wildcard characters. DirII was something I had already used before because it has the benefit of auto sorting the output. Which I needed for a different project and the 3.1 version of List is missing. This is not required for this, so I might try to search through Aminet again.
But I don't know if I actually can properly test it because I never tried the whole long name thing, so I might end up sending you a private message with one or two alternatives. Just to keep this thread a bit cleaner.

[mfilos]

Totally agree mate. I'll try and see what I can find as well

[EctoOne]

Actually give this one a try. DirII was obviously cutting of the filename so I hope the replacement works fine.
I've also merged the two archives. The version number is 9.4.
9 for IconSaver and 4 for PositionSaver. I've also removed the reboot package(MSys-1.2), but the function is still there. If there is an reboot command available of course, and I added that to PositionSaver as well. So, WB3.1 users either have to copy the reboot command from the install disk (I really don't understand why stuff like that and IconPos isn't copied by default) or get the MSys-1.2 package from Aminet.
I also decided that IconPos from the Install Disk gets copied to SYS:C/ since it is an original Workbench command.

I'll keep the old files in my previous post until it's confirmed that this one works.

Edit: File removed. See new version below.

[mfilos]

New version works Fantastic man with no errors on archiving!!! Kudos!!!



Only thing it needs to work ok is to add the actual empty "IconArchives", "IconPosition" drawers as there's the .info without the drawer and if it doesn't exist the script throws an error
Not anything important, but at this elegant solution, one little thing to add!

Thanks a lot for the wonderful job man!

Bellow are some edits to the post after finding issues that thought of sharing to ya:

• Edit: Oops, I found entries with "object is not of required type" inside the created IconPositions script!!! Hmmm time to troubleshoot to report back...
• Edit 2: OK found out that there are .info entries from various programs (like fxPaint, ImageFX, ReqAttack and one drawer icon in RNOTunes which was probably a mistake) that are probably NOT icons although they have .info in their filename (totally weird but it's an actual case - I know it sux but what can you do?). The problem occurs while EXECUTING T:ILIST when ICONPOS can't actually find the position of the icon (as it's not an actual icon) so it outputs the error description in the IPLIST file (instead of the normal IconPos output) Can you just skip these info files instead of writing the output of ICONPOS's error "object is not of required type". Logically IconPos should return some RC if error occurs... Edit: No it doesn't and haven't managed to grab a SnoopDOS entry that can help :S Maybe scanning whole file to see entries of "object is not of required type" and get rid of them?
  
• Edit 3: I also found that one MATCH declaration from the SaveArchives script uses DH1: instead of SYS: (I guess it was due to your tests and needs to be corrected)
• Edit 4: For the first time I tried to run the IconArchives icon to test how the restoring goes. In order not to mess anything, I copied DPaintV from my drawer to RAM: DPaintV and I changed your script instead of SYS: to use RAM: DPaintV/ . SaveArchive script worked just fine and running the produced Icon whether I chose the Copy or IconCopy option I had many errors which was due to the fact that the ILIST entry within the archive had the command wrong. Check how the command is written for example in 1st entry on ILIST
  
  I also tried the IconPositions script to restore the positions and works like a charm!
• Edit 5: May I suggest that in the future, instead of using just SYS: you could add a "RequestDevice" command to grab the selected path instead (it will be a lot easier for testing and troubleshooting as well)
  I personally modified the LAB ARC (for testing purposes) as following (which seems to work rather nice):
  

  LAB ARC
    RequestDevice TITLE="Choose a Device/Drawer path" VAR=ENV:ArcPath
    If NOT EXISTS ENV:ArcPath
      Echo "You haven't selected a Device/Drawer. Script will now exit!"
      Quit
    EndIf
    SET IFILE `fdate "%Y%m%d%H%M%S"`
    ECHO "*nSearching icons...*n"
    MATCH ${ArcPath} TYPE FILE NAME #?.info LFORMAT *"%R*" >T:ILIST
    LHA r -axXH0ND4 -iT:ILIST IconArchives/${IFILE}
    ECHO "*nCreating install script..."
    ECHO ";IconSaver" >T:ILIST
    MATCH ${ArcPath} TYPE FILE NAME #?.info LFORMAT "IF EXISTS *"%R*"*n  *"%p%n*" *"%p%n*"*nENDIF" >>T:ILIST
    REP T:ILIST "\n  *"${ArcPath}" "\n  ${COMMAND} *"RAM:${FILE}/"
    ECHO "*nStoring install script..."
    LHA a -axXH0qQw IconArchives/${IFILE} T:ILIST
    COPY >NIL: IArcInfo IconArchives/${IFILE}.info
    DELETE T:ILIST QUIET
    UnSetEnv ArcPath
    ECHO "*nDone."

  On the PositionSaver script it's not working 100% (I guess due to the quotation marks and variable that needs a bit of troubleshooting but it's not hard imho). Will give it a spin at some point when I have more time

[EctoOne]

Geez, looks like I was to hasty releasing that version. Thanks for reporting. I hoped I have fixed most issues with this one. And yes, I added a Request Device command.
Also IconPos is back to being stored in this folder instead of C.
I moved the template icons into the subfolders to avoid the problem of not having them when extracting this archive. But there's also an additional check in the scripts which will create them if they somehow disappear.

I still have to look into that "object is not of required type" thing, but I wanted to release this fixed version first.

Version 11.06 should fix this. Luckily it's a simple error message that I can delete with Rep. There was also different message if an info file was empty (size 0), that gets also removed.

And now the stored archives/scripts have the device name as prefix to easily see which drive they belong to. Something like DH0-20230606...

Edit: Removed file.

[mfilos]

On a first test both scripts seem to work just fine man! Fantastic!
I saw you use the extra rt_RequestDevice although OS3.2.x has it's own. Then again the external one can only select Drives (which is more appropriate than drivers and drawers).

The only issue atm I'm seeing is some files in my root drive's archive named "unnamed.dat" which ofc are not present in my root drive. Will investigate more and report back.

Thanks for your hard work man! I greatly appreciate it.
( Cheers for the doc mention as well \o/ )

[EctoOne]

Are you sure about the RequestDevice thing being available on 3.2? I only have the ordinary RequestFile. Which I could have used but it would probably be to much work to get just the device name. It probably would even require another optional tool. This was way easier to add. RequestFile could be useful if I wanted to add support to only save certain directorys, but I honestly don't see any need for that.
I recently spend some time messing with RequestFile for something else, and it was annoying to get a function working which was kind of failsafe. And that was just for my personal use, I don't even want to think about implementing this for anyone where I don't know how or what they are trying to select.
I was considering using it to input your own file name, but that also would enable them to save it in a different directory. Which wouldn't work for the archives if CLICon wasn't installed manually.

[mfilos]

Yes you are right. I tried a stock 3.2.2.1 installation and RequestDevice wasn't present (alas I must have got it at some point from my own stash of commands I try over the years).
I totally agree with your way of thinking and rt_reqdevice is safer and easier to use.

Btw, the first time I tried the PositionSave script gave me a bunch of IconPositions/IconPos not present...
I manually copied it from C: to IconPositions/IconPos drawer and worked like a charm afterwards. I checked your script and it's supposed to raise a requester in order to copy it but it doesn't work :S I don't see any problem with the script as well (dafuq).
I erased it again and tried, and still the requester doesn't show...

Edit: Ok if you have IconPos on C: (or in path whatsoever) then the requester doesn't show. If you rename or remove it from C: then it works just fine (and it's logical cause the "Which IconPos" returns as TRUE so it doesn't enter the WARN statement. I guess it needs another "copy IconPos IconPosition/IconPos" declaration in ELSE - but with the source as the path from Which, that you need to store)
Edit 2: Trying to check the "unnamed.dat" entries of the backup but neither ILIST contains entries with "unnamed" neither my SYS: drive contains any "unnamed" entry... WTF?
Edit 3: Ok I found it... I found the unnamed files after unarchiving them and from the contents of the files I assumed it was TurboCalc so I went in TurboCalc's drawer and found under a toolbars drawer that there were some .info files that had "space" on their filename. All of these unnamed files are the files with the "space". I attach them into an archive here to have a look. Can you do something for them as well?

[EctoOne]

Ahh, yes. I try to run IconPos from IconPositions/IconPos when generating the script. Of course that fails. When I rewrote that part I moved IconPos from C. That's why I had no issues. I will change it back to just copy it to C. That would be the easiest solution. Or I either copy it twice or temporarily add IconPositions to PATH. I'll have a look.

I have no idea what's going on with the unnamed.dat files. Maybe it has to do with your weird long names or wildcard characters. And LhA moves them into root because it can't handle them? I don't know.

[mfilos]

I think that best solution is would be to Copy it to C: as it's a WB command that could be used elsewhere.
Also the naming with spaces was annoying in scripts but you always solved that issue with using "".
Sadly I dunno how LhA handles them (but I was rather certain that it supported it).

Edit: OK I managed to bypass the issue by removing the option Qw (that disables wildcards) in the 2nd LhA declaration.
Do you think that this could create other issues? I havent' seen any actual problem so far.

PS. As a sidenote... what does the "4" option do (checking from your first "LHA r -axXH0ND4" declaration). I checked my LhA command and only has referece up to "3" and 1-2-3 are compression version methods.

[EctoOne]

I agree with copying to C. And I couldn't think of a good way to add it to PATH. So I just deleted two lines and changed the target. Done...

I'm not speaking about spaces in names, I was talking about the brackets ([{}]). Like I posted before, the guide says LhA can handle them with a certain option but that didn't fully worked for me. Maybe you have something like that and LhA can't correctly handle the path created by Match. Do they have the same size or any size at all? Maybe you could try to use something like SimpleFind to search your drive for that particular size.

Here's the updated version that copies IconPos to C.

Edit: Just saw your edits. I will look into the files containing spaces. And the 4 in the LhA command is for the D in front of it. It's to show the progress bar window instead of text in the shell window. And I really don't know about the wildcard thing from LhA. I assumed that would help with the other problem I mentioned in the crossed out text. I think without it, LhA won't add files with/from paths with brackets.

Edit2: Umm, I have no issues with the files you uploaded. I have extracted them into a folder in RAM, ran the script and inside the archive they are correctly placed in that folder.

[mfilos]

Yes the files in the archive I attached got screwed (they had space in the filename that was replaced with the underscore _ due to DOpus. If you rename the underscore TO space you can test it out correctly.

New "SavePositions" version still has issues concerning IconPos (if it's already in C:, have to copy it manually from C: to IconPosition/ drawer)

I guess you have to change

MATCH ${DEV} TYPE FILE NAME #?.info LFORMAT "IconPositions/ICONPOS *"%R*" >>T:IPLIST" >T:ILIST

to

MATCH ${DEV} TYPE FILE NAME #?.info LFORMAT "C:ICONPOS *"%R*" >>T:IPLIST" >T:ILIST

May I also suggest putting the names in quotes "" to avoid spaces
Example:

1> ICONPOS DH0:Programs/Productivity/TurboCalc/Toolbar/Create Chart type=PROJECT 239 4
bad number
1> ICONPOS "DH0:Programs/Productivity/TurboCalc/Toolbar/Create Chart" type=PROJECT 239 4
DH0:Programs/Productivity/TurboCalc/Toolbar/Create Chart type=PROJECT 239 4

This is definitely NOT easy as the EXECUTE T:ILIST runs the IconPos and gets the output which has NO quotes. For example:

SYS:Programs/Productivity/TurboCalc/Toolbar/Create Chart type=PROJECT 239 4

...so somehow you need to get the path into quotes and type and coords outside quotes in order for it to work... Dunno how can someone do that... :S
Edit: Now that I thought it it's not that hard... Just replace <space>type= with "<space> type= AND $DEV with ICONPOS "$DEV" with extra caution on the quotes

Concerning the "SaveArchives" and the unnamed.dat files, i'm still under heavy investigation as I have backed up icons with spaces just fine, but these specific unnamed.dat files are due to other filenames... will report back with my findings.
Edit: Ok case dismissed. Turned out to be a second sub-drawer named Toolbars2/Toolbars/ with the same icons that created the issue... dunno if it's due to filename depth or same filename, but once I removed this drawer, the unnamed.dat files went away.

Sorry for busting your balls... it's just that I find this script rather fascinating, and wanted to troubleshoot it as much as I could to make it worthwhile

Cheers man! \o/

[EctoOne]

If I remember correctly the files from your archive didn't have underscores, they had spaces. I might be wrong though but I actually think the path might be too long.

Ahh dang, I must have missed the command line when I tried different methods and just hit undo in my text editor instead of editing the lines.

I don't think the arguments need to be quoted but I agree with adding quotes to the path.

[mfilos]

The arguments indeed don't need to be quoted alas I said about replacing the string adding the Quote from the start up to Type

[EctoOne]

Oops I have misread that. Happens when you think about one problem and start reading the next one.

Edit: File removed.

[mfilos]

I think we're all set my friend.
Just checked the SaveArchive and SavePos scripts and run flawlessly!
LOTSA KUDOS!

I also wanted to check running a stock 3.2.2.1 environment I set in UAE to check dependencies but the experience wasn't as pleasant cause it always failed to backup.
After checking the script and what it does, I realized that everything was extracted correctly so I tried troubleshooting every one of the external commands until I got to rt_ReqDevice which wasn't running for no apparent reason :S
After running SnoopDOS to see what's going on... it showed that it required the ReqTools.library which isn't present in a stock 3.2.2.1 installation.
After getting and extracting the library from Aminet (http://aminet.net/package/util/libs/ReqToolsLib) all went smoothly.

I suggest to include this in the sources as well mate.

Apart from that, everything (including restoring from backups was checked (for both SaveArchive, SavePos) and works as intended! Great job man! \o/

[EctoOne]

Eww for real, it does require reqtools? That sucks. I'm not too sure if I want to add a whole library. Especially one that can be configured.

Did you copy it to Libs: or the IconSaver directory? In case it needs to be in Libs: I could still have it somewhere in the IconSaver directory an make a temporary assign.

Hmpf, I'll look into it but I'm not happy about that.

Thanks for testing everything though.