Awesome - duh me didn't even think of trying that!

np, i was also thinking about filesystem restriction, but testing without PeterK's it does work,
on the same partition.
i hope Peter will be back and does some investigation :)

Peterk: Could you reconsider support for a HAM? Upcoming amiga reloaded will have 14mb/s buss speed, so 1280x640 workbench is about a 4x more useable with it. With AGA mapping icon's colors with HAM would be only possible solution to get high color icons.

@Kernel and emufan
I could reproduce this "Couldn't lock dir"-error under OS 3.9 with my library 46.4 and also with original icon.library 45.1.

Then I tried BetterWB (OS3.1): The same error again with my library, but it works correctly with the original icon.library v40.

Ok, I will do some investigation on the next days.

@ultri007
Some weeks ago, I thought at night about your HAM-request. Conclusion: it's not impossible, but it would require a completely different colormapping and chunkytoplanar routine, because every pixel can have its own color and not just one out of (up to) 255 colors and transparency. In my eyes, only HAM8 makes any sense, because HAM6 needs LowRes, which looks terrible.

Maybe, in a few months I will think again if it's worth all the trouble. ;)

Peter, just to wish you a Merry Christmas and thanks a lot for your work :xmas

Thank you, Retrofan, but I'm a nonbeliever, I don't believe in Santa Claus and all these old stories... ;)

Anyway, have some nice days.

What Santa Claus ®? The one created and sponsored by Coca-Cola? :D

You should start believing in the Three Wise Men (Kings) :bowdown

welcome back and thnx for looking into it :)

I have more strangeness to report.

I took the advice emufan gave and made the path shorter. The tooltype went from

EYESPICTUREFILE=PROGDIR:PointerEyesImages/MagicWBEyes

to

EYESPICTUREFILE=PROGDIR:PEI/MagicWBEyes

I still get the lock error and the path is still malformed . See attachment.

I changed the path to a direct SYS:WBStartup/PEI/MagicWBEyes and that works.

Given this, I believe there are two issues happening here... one with the length, and the other with the PROGDIR tooltype not working as expected.

Then again, I could be way off...

NOTE: Incase you already read this before my EDIT and saw I mentioned a GURU... I edited that out because I found it was due to something else. When MCP's NewToolTypes option is enabled, and icon.library is in the startup sequence, I get a guru.

Hi Kernel,

if you just remove PROGDIR: from the path then it works. :)

Update to icon.library 46.4.444:

A lot of optimizations in the zlib decoder for the PNG and OS4 icons:

The useless cyclic 32 kB buffer has been removed together with all his pointer ping-pong management.

The two static Huffman tables are now generated on the first call to inflate() instead of uncompressing them from gzipped data. The 17 bitmasks are also generated.

All together this saves more than 1 kB space in the 68020 version. The 68000 version also uses my zlib code again. It's 1.5 kB larger, but both libraries should be a little faster as before.

The remaining buffers for the dynamic Huffman code tables are now protected by using semaphores for the inflate() function.

Last but not least, I would like to say Thank You to Keir Fraser (Kaffer@EAB) for all his help and explaining the Huffman coding secrets to me. :) I still have to cleanup the dynamic Huffman decoding subroutine a bit, but that's rarely used for icons.

Actually, that is not a silver bullet. Whenever not running icon.library, it would work without issue. When icon.library is enabled, I got the munged path and I removed PROGDIR and yes it worked as long as I shortened the path further.

I was working on setting up all my icons as MagicWB at the time so I had left icon.library disabled, but this week I finally started moving beyond them to GlowIcons and PNG.

Yesterday PointerEyes started complaining again about it not being able to lock the directory. I just traced it to me having replaced the icon with a PNG from Kens Icons. I just reverted back to a MagicWB icon and it started working again.

What can I do to help troubleshoot this further?

Also, a completely separate question and probably dumb, but your icon.library basically makes the entire NewIcons archive - programs, library, etc - unneeded correct? Or are utilities like DefIcons still required? If I'm missing some documentation, feel free to point me to it - thanks!

Yes, I know that my answer is not what you want to hear from me, but simply make a decision:

Use PointerEyes or icon.library, but not both together if they have a conflict! :crying

On OS 3.0/3.1 without a workbench.library v45 you would only need the NewIcons patch for making icon backgrounds transparent (as it is done in my IconDemoADF) or if you want to support DefIcons (icon.library only supports the basic types like Tool, Project, Disk, Drawer, Trashcan).

I do not accept your decision! I want BOTH! :)

Ok so not to be a dullard, if I didn't have V45 of workbench.library, I need the newicons patch running and not just the library available on disc? And as for DefIcons, are you saying it isn't needed with V45 of the workbench.library or it's needed regardless if we want the additional niceties of that it offers?

OS 3.9 has its own DefIcons tool for the WBStartup drawer and its own Prefs/DefIcons and ENVARC:DefIcons.prefs. And the workbench.library v45 should better work with the OS 3.9 versions than with the old versions from the NewIcons package.

If you think that I should fix every bug in the OS, you have to wait for long. ;)

Thanks for the info on NewIcons/DefIcons - definately enlightening.

As for the bug - LOL not at all - it's just curiosity at this point... I would just like to know what it happening i.e., with he library enabled and a normal icon, it's working fine, but when I change it to a NewIcon/GlowIcon/PNG it starts breaking.

Sorry Kernel,

but I can NOT reproduce your problem with PointerEyes and PNG or OS 3.5 icons here after changing the images with CopyIcon from Stephan Rupprecht.

Of course, I've removed "Progdir:" from the path before doing that (EYESPICTUREFILE=PointerEyesImages/MagicWBEyes). That always works, no need to shorten the path at all.

I've been able to narrow this further. It's definitely a challenge tracking down weird stuff like this. Note that I'm using workbench.library 45.132 (04/04/2007) and icon.library 46.4 (68020) via the LoadResident command per your docs - I'm not sure if the versions matter or not with what is happening.

1) To the points made previously, removing "PROGDIR:" and specifying the full path to the eyes file works. This is only an issue when icon.library is loaded - if I remove the code that loads workbench.library and icon.library, "PROGDIR:" works fine.

2) I've actually traced the malformed path issue further down to occurring when both icon.library and TLSFMem 1.4 (10/28/2007) are used at the same time. If I disable TLSFMem and just have icon.library enabled and use the full path to the picture file, PointerEyes loads fine. If I leave TLSFMem enabled and disable icon.library, PointerEyes loads fine (even with "PROGDIR:").

If it wasn't apparent before, I agree with you and don't expect you (or any other developer for that matter) to be able to address every issue that pops up between programs. However, I am a big fan of figuring out why something isn't working so that others can bypass the struggles that someone else has already endured which is why I tend to keep digging until I'm happy with the results.

Thanks for a great piece of software and I appreciate the feedback you and everyone else has provided while I was troubleshooting this.

It is more or less known that TLSFMem can cause problems. This might be not TLSFMem itself but faulty working programs. At least you should use enforcer, mungwall or muforce and muguardianangel to catch possible problems.

I don't recall where, but I had heard that TLSFMem was one of those "must have" patches... and you are correct that it's technically not TLSFMem, and technically not icon.library, and technically not PointerEyes but rather a specific combination of them that allow the problem to expose itself.

I prefer the combination of icon.library and PointerEyes rather than TLSFMem and PointerEyes so I can live without it for now. However, I will look into the utils you mentioned since I like learning new stuff.