It may be a problem with the previous version of ImageMagick... (Support requests)

by Robert , Thursday, March 30, 2017, 12:55 (2584 days ago) @ acaballero

>Checking the exception you pasted: I can see that it says "Wrong JPEF library version: library is 80, caller expects 62".
[quote]I wonder if the other ImageMagick version was properly removed, because seems like a collission between files in the environment's path.[/quote]

The PATH is not the issue because I had already changed it, and I was confident that all of the old version of ImageMagick had been removed; only the new version of ImageMagick was in the PATH.

I used a tracking Install and Uninstall program to ensure all traces of the old version of ImageMagick were removed. Uninstall programs commonly seem to fail cleaning up the PATH when their program is un-installed. Likewise, the Uninstall monitors also fail to monitor the PATH after an uninstall. Before installing the 6.9.8-3 version, I checked the environment variable for the PATH. The old version of ImageMagick was still in the PATH, so I knew that I should and would remove it, but I decided to leave it there until I installed the new version of ImageMagick.

Next, I installed ImageMagick version 6.9.8-3, and again checked the PATH. The new version had been added to the PATH at the very start as expected, and the old version was second in the PATH. I removed the second directory since the program files were no longer on the disk at that location, but even if I had left it in, the directory no longer exists. Any program accessing the PATH environment variable to find ImageMagick would use the first one in the path, and the program should verify that the program actually exists where the PATH says it does.

Even if the old ImageMagick version directory were still in the PATH, it would be second in the list, and since the old version of ImageMagick is not on the disk, no program can access any of that version's features (or have a conflict if the program is no longer there). Therefore, the problem has to be the program that utilizes the ImageMagick library features is not aware of the ImageMagick change. Icomancer is expecting the old version because at this point, it is not aware of the new PATH data and new version of ImageMagick.

It is not uncommon to have the PATH environment variable contain directories that no longer exist, but since they do not exist, any program that blindly uses invalid PATH data can't blame it on the PATH. The big issue with the PATH is that the length of the PATH is not unlimited. Back in the days of DOS and short file names, the PATH did not generally get very large. Today, too many programs add long directory strings to the start of the PATH, making older entries fall off at the end, and they do it without warning or informing the user; that is a bad practice. I have to monitor my PATH constantly to ensure new installs do not mess things up for me.

These days, programs should not depend on the PATH data to interact, start, or utilize other programs. The data in the PATH they expect could be the one that has fallen off the end after other programs have been installed. When that happens, how will icomancer handle that?

Anyway, the icomancer program was now able to start after installing ImageMagick 6.9.8-3. I was able to create an account, and I was able to download the oxygen and ten folder templates. To incorporate those libraries, icomancer needs to restart itself, and then starts working on processing the libraries using ImageMagick. There is when the library conflict showed up. When I noticed the library conflict statement (80 vs. 62), I knew that icomancer was not aware of the ImageMagick change for some reason. That problem existed even though the PATH had the correct data. Apparently, icomancer does not re-acquire the PATH data when it restarts itself.

Even though I had changed the PATH environment variable correctly, it does not mean that all programs will be aware of that change, icomancer being one of them. The way icomancer works now, for icomancer to re-acquire the new PATH data, the computer needs to be restarted. Normally, that is part of the initial install process. If you start an XP Virtual Machine, then essentially, you are closer to doing a re-boot of the OS than I was. I expect that is why yours worked. After rebooting my computer, icomancer also works.

>If there's more than one ImageMagick entry in the path, then that's where the conflict is
It is not whether there are multiple ImageMagick directories in the PATH, it is whether icomancer knows and uses the first one in the list. To further back that up, I re-edited my PATH variable, and put it back like it was when having both directories of ImageMagick. After a reboot, I started icomancer. If your statement is true that when both entries are in the PATH, it will be where the conflict is, icomancer should have the same problem, but it does not because icomancer used the first one in the path. It does not matter that an incorrect directory is also in the PATH. What matters is whether icomancer re-acquires the PATH data when it restarts itself. Try adding the other ImageMagick directory back into your PATH, and you will see that icomancer will still work.

Granted, it is a rare case and few will encounter this same problem, but if you make icomancer re-acquire the PATH data when it restarts itself, this problem will not happen for other users that need to change ImageMagick.

Now that I finally got icomancer started, my greatest disappointment is that it can only change one folder at a time. I have several folder icon changers that already do that on XP and on the Windows 7 and 10 OSes. I wanted a program that can change all of the subfolders to the same icon on the XP OS. Several competing folder icon changer programs do this already. I even have one that runs under the XP OS, but the problem with it is that it does not complete the job. Somewhere along the way, it stops, leaving a lot of subfolders not changed. It is a real hassle to have to go through every subfolder to see what remains to be done. I was hoping for a better solution.

There are quite a few Open Source folder icon programs that can change one folder. I hope you will consider adding subfolder changes to iconmancer. Without it, there is too many alternative programs that do the same.

My PATH:

but it also works with both directories in the PATH: