So what's the problem really? popupmenu.library or x1ktemp.docky?
Because problems arised (for me) when I created a 2nd amidock to put the new dockies from Guillaume. Since one year now, with x1ktemp.docky and others, I never had a guru like this.
To Be A True Adventurer, You Ought To Play Real Text Adventures
X1kTemp has his own flaws for example if you constantly hide/show the dock where it lies it will crash. The only reported case was by one user in conjunction with AutoDock by Tuomas. But the crash is totally different as X1ktemp is clearly indicated as crashed.
For now on I can't produce the problem on my system, but looking at the crash log the bug is related to popupmenu.library and lies in AmiDock (not in X1ktemp.docky not in CPUDock).
Italian translation from Samir 'Samo79' Hawamdeh German translation from Thomas 'TommySammy' Blatt Spanish translation from Javier 'Jabirulo' de las Rivas Greek translation from Anthony 'Phantom' Iliakis French translation from Guillaume 'zzd10h' Boesel
* Solved INFO_WINDOW position when it goes outside of the screen in BW, DR and DL mode Thanks to Alex 'abalaban' Balaban for this bug report
* Added "How to make a Workbench titlebar docky" at the end of this ReadMe
* Thanks to Niclas 'Nicsoft' Eriksson and to Hubert 'Raziel' Maier for there tests on this version
Especially for CPUDock : * Added PA6T cpu picture from Thomas 'TommySammy' Blatt
* Corrected Pegasos 2 detection. Thanks to Francisco 'Kyle' Lemmi for the bug report.
Especially for NetDock :
* New Hubert 'Raziel' Maier's set of pictures for MINIDOCK correcting missing right border
X1000 users of x1ktemp.docky :
* it seems that public version of PopupMenu.library causes a crash in AmiDock when CPUDock and x1ktemp are both used...
Betatest version seems to fix this problem Waiting for a public release...
Regarding FastCompress, it`s more of the native compress tools issue than the gfx interface, here are some things that I`ve noticed lately: I`ve tried to compress some .txt files in the WookieChat/Logs/ directory, specifically the IRCServer_#Channel logs. 7zip & zip did well, lzx exit with a null file and lha looped indefinetly. I think this has to do with the way native wildcards in filenames are handled (the # before tha channel name).
It`s very easy to replicate the problem. Rename your "RAM Disk:au.log" (could be any file) text file to "AmigaWorld_#amigans" (Workbench, RightAmiga&R) and try the various tools on it using the ContextMenu.
Sure. On AmigaOS # (amongst other things - see the ParsePattern AutoDoc for a full list) is a wildcard. It matches repeating patterns.
LhA parses the commandline using ParsePattern, so all wildcards are translated and then matched to files.
Hence, "#test" matches "test" "tttttest" etc, but not "#test". You can see it yourself using list.
To negate the wildcard, a single quote character can be used. "'#test" will then match "#test".
8.RAM Disk:> list #test tttttest 6 ----rwed Today 16:53:26 1 file - 6 bytes - 2 blocks used 8.RAM Disk:> list '#test #test 4 ----rwed Today 16:48:37 1 file - 4 bytes - 2 blocks used
So, all you need to do is translate the filenames to put a single quote in front of any wildcards*, before sending those filenames to LhA or LZX. It doesn't affect 7za or Zip because they aren't decent AmigaOS ports and hence don't support AmigaOS wildcards (or file comments, or attributes**)
* Specifying -Qw may be enough for LhA.
** In fact, the OS4 versions of Zip and/or UnZip completely screw up the attributes when compressing/decompressing.
@zzd10h Ah nope. I don't use any of them as i have peg2. But i use all other dockies almost all of whic handle rmb : netdock, mixer.docky, kms, ram/gfx dockies and datetime docky.