Hi, This appears to be a very handy tool and a very nice piece of work (having gone through the same problem myself multiple times in the past trying to create full icon sets for Windows desktop apps ... last time I settled on using the "GIF Movie Gear" app for doing that successfully).
I downloaded your app zipfile from GITHUB and had no difficultly unzipping it, loading the solution in VS 2017, building the libraries and the app, and running the program. Opening one of my own "hand-made icon files, I see all of the frame sizes from 16 to 256. Nice.
But when I try to create an icon from a .png image, I see the nice square image and all the sizes are checked and 8 BPP selected. (I do not see a 32 BPP option either, like the one show in your animated demo. All I see are 8, 4 and 8+4?) However, when I click CREATE, I only see and can preview four frames sizes (16, 24, 32, 48). Why is that? I expected to see all of the checked sizes and to then be able to save a full icon set. The app will save an icon file with those 4 frames and it will save those 4 frames in a folder. But of course I need all of the frames in the set.
[EDIT] I think I figured out my problem. Apparently the images I was trying to use were saved as 8 BPP images, rather than 32 BPP images. Why that makes a difference in the frames sizes, I really have no idea. (All of those "hand-made" icon files I mentioned above contain all the frames sizes and were created from 8 BPP images, I think ... and seem to work fine. Maybe they would be poor or fail on certain hardware??? I guess I thought using 8 BPP just meant a smaller icon file with fewer colors available? I tend to use indexed color files anyway for icons and simple images. Maybe that is bad?)
PS / Oddly, "exporting" (apparently SAVE saves icon files and EXPORT saves icon images) opens a "Browse for Folder" dialog that shows folders/places to save such as Libraries, Network, Control Panel, and my User Name folder (!?!) as well as ordinary desktop folders and the This PC folder, etc.
This seems to me to be a "poor design" or else a bug in that no one would want to accidentally drop a bunch of image files (or anything else) into those system folders. I suggest this be fixed.
Incidentally I think I just noticed another "bug." When you click EXPORT and the "Browse for Folder window is open, it of course has the focus. But if you then click on your app window, giving it the focus, and then click on the X box to close the app, it does close ... but the Browse for Folder window stays open. That is not good. When you close your application, all of the windows and other stuff associated with that running process should close properly as well.
Hi!
Thanks a lot for your observations! I'll be checking out these things.
I guess I thought using 8 BPP just meant a smaller icon file with fewer colors available? I tend to use indexed color files anyway for icons and simple images. Maybe that is bad?)
Yep, you're right about less colors means smaller files, but, I don't think you're going to have a big difference in the output file size. Plus, most all now days icons uses only 32BPP. While developing this tool, I opened dozen of icon files from internet to have an ideia about some standard. The newer icons have on 32BPP frames.
Why that makes a difference in the frames sizes, I really have no idea. (All of those "hand-made" icon files I mentioned above contain all the frames sizes and were created from 8 BPP images, I think ... and seem to work fine. Maybe they would be poor or fail on certain hardware???
Interesting! I'll be checking this, might be a bug in the encoder.
PS / Oddly, "exporting" (apparently SAVE saves icon files and EXPORT saves icon images) opens a "Browse for Folder" dialog that shows folders/places to save such as Libraries, Network, Control Panel, and my User Name folder (!?!) as well as ordinary desktop folders and the This PC folder, etc.
This seems to me to be a "poor design" or else a bug in that no one would want to accidentally drop a bunch of image files (or anything else) into those system folders. I suggest this be fixed.
Very good observation, I'll add a confirmation dialog!
Incidentally I think I just noticed another "bug." When you click EXPORT and the "Browse for Folder window is open, it of course has the focus. But if you then click on your app window, giving it the focus, and then click on the X box to close the app, it does close ... but the Browse for Folder window stays open. That is not good. When you close your application, all of the windows and other stuff associated with that running process should close properly as well.
Wow, this is insane! I gonna check this out as well
I would like to thank you again for pointing these things out for me!
Anything else you find, bugs, suggestions and whatever are welcome!
Hi. I checked that it was not VS or debug causing the Select Folder dialog to stay open when the main app closes. It did the same when I just ran the release executable. I'm not a WPF expert, but just looking quickly at your code, maybe your calls to:
Evidently the WPF SelectFolder() method has some interesting quirks as well. Googling that, I read this StackOverFlow link. Maybe there is something there to help?
At any rate, thanks for the tip about using 32 BPP for icon images. I read your previous article which confirmed my notion that icon files are so (unnecessarily?) complex that it sure makes sense to depend on somebody who has studied the issues! (And created an app for that! ) For instance, I didn't know that a "proper" icon file should contain 32, 8, and 4 BPI icons. (Still not sure why?)
Apparently the GIF Gear Movie app doesn't do that (it must just convert everything to 32 BPP?)
Hi, yes, I already fixed the FolderDialog issue. That's true, I've setted that thing to null in development and I forgot to change later.
I've already checked most all the issues you related before. Now I'm rewriting the Core library to make it more clear and easy to understand.
While rewriting, I got myself in a really mad strange behavior while saving icons and I'm trying to fix that.
I fixed some other small bugs and I've added a new option to the Welcome Window.
I hope next week I'll commit all the changes to github and publish a new release!
And, yes, these icon files are so madly complex!! I don't understand why a simple thing like this needs to be so complex.
Ha, probably the entire history of graphical interfaces for ancient to modern hardware is embedded in the evolving formats for icon files! Fonts too, I bet. I will sure keep an eye open for your forthcoming new update release. After all, this is one of the fun things about CodeProject. You get good (and poor) suggestions from interested readers all over the world sometimes and other people get to use your creations to solve vexing problems of their own. Thanks again.
You are right! That's why I've posted on Code Project.
With your contribution, I found some other bugs, and also I rewrote the Core library.
Anyway, you can check on github the updated codes and the new release (build 238).
Actually, I simplified the core lib a lot! I erased many classes to have a clearly code.
I debugged that new code a lot. For now, it seems to work perfectly. I tested it different scenarios, trying to open the created icons with the native wpf IconBitmapDecoder and Visual Studio icon editor.
Seems like everything is working fine.
However, there is, still, one boring unexpected behavior. As you might have noticed, 8bpp and 4bpp icons created and opened by this tool, gets a little noisy. I mean, color noise. This doesn't happens
when opening/creating 24/32bpp icons.
It seems to be some issue in the internal Windows Image Codecs.. I have absolutely no idea about how am I going to fix this.
Contradicting what I had said earlier, in my previous article, you do not need to include 8/4bpp frames in your icons. In fact, after researching a lot and opening many icons from microsoft this week, I've realized that they didn't include 4/8bpp frames on Vista+ icons.
I'm sorry about the wrong information on my previous article. Well, you live and learn
I downloaded your latest version, which appears to be much improved and to work very well!
That WPF SelectFolder control now must be closed before you can quit the app. That's good. Too bad that it apparently does not have a "Cancel" button like the OpenFile dialog does, so you still have to click the X to close it. But it is small and you can see the app behind it.
That SelectFolder dialog still shows all sorts of system folders, but maybe there is little to be done for that. (I realize you use this - instead of a SaveFile dialog - because you want to save a bunch of files there. I believe you can obtain the path for saving from the SaveFileDialog too, even after pressing Cancel, but that is probably equally confusing here.)
Your new HELP/ABOUT dialog is great, but it would benefit from a obvious "Cancel" or "Close" button. (Since it is big and hides the app, I was first afraid clicking the X would close everything.) ps / The narrative there could use a bit of proof-reading!
I also liked the way you employ nice tooltips for the button controls in the app (and a bunch of other nice touches). I will raise my vote to a 5.
About "fuzzy" or "noisy" icon colors, possibly/probably there may be some kind of anti-aliasing" occurring. I didn't see much of a problem though with simple icons.
Very nice work. I'll watch for other CodeProject articles you choose to post in the future.
I'll follow your tips, and make all the improvements as possible.
Yesterday, I've just released a very short video for advertising purposes and also an simple road-map for it.
Thanks again for the great help! I'm not a professional developer or designer. For now, these things are just a hobby for me. But I try to make things in the best way!
I did a very cool progress in the development, and that means some new update coming is the next week(s). I've successful opened and viewed all the frames of a Animated Cursor file.
I was starting to think that this would never come to action, but, I'm persistent. After some researches, I finally understood the structure of a Animated Cursor.
For now, I'm not interested on adding a option to build Static and Animated cursors on this tool. But this could come true in the future, because the hardest part is being solved now.