MHo 2009-11-20: I noticed that the method described in http://www.equi4.com/wikis/equi4/267 does not work anymore with starkits 8.5.8 downloaded from http://www.patthoyts.tk/tclkit.html . Does anyone have an easy solution? It seems that the format of the embedded icons changes from time to time, as a look with reshacker shows.
Duoas 2009-11-20: Take a look at Custom Icons For Win32 Starpacks - The Real Story . Hope this helps.
MHo Thanks. But it should be possible the old way too - just copy the appropiate tclkit.ico to the root of the vfs and enverything else should go automatically. I just couldn't figure out how the iconset is organized. My guess is:
The size of the .ICO is 57022 bytes. But if I modify some Icons inside such an icon set and try to wrap my starpack again, sdx complaines about wrong sizes like that:
customizing tclkit.ico in executable icon 64x64/256: replaced icon 48x48/256: replaced icon 32x32/256: replaced icon 24x24/256: replaced icon 16x16/256: replaced icon 48x48/256: NOT SAME SIZE icon 32x32/256: NOT SAME SIZE icon 24x24/256: NOT SAME SIZE icon 16x16/256: NOT SAME SIZE icon 48x48/256: NOT SAME SIZE icon 32x32/256: NOT SAME SIZE icon 24x24/256: NOT SAME SIZE icon 16x16/256: NOT SAME SIZE
What sdx is saying seems to be wrong. There is, e.g., no 64x64/256colour icon in the icon set. Maybe sdx isn't up to date...
Duoas No, JCW's method has never been too reliable. If you take a look at the code in SDX to replace icon files, you'll notice that it is very simplistic and makes some assumptions about the replacement icon. It should be possible, but it seems that JCW has other things to think about before implementing code to do everything necessary to replace Win32 resources in a UPX compressed file without limitations.
Why not just use UPX and ResHacker ? It doesn't add any significant complexity to your build process, and works perfectly every time.
MHo Here is a variant of the batch from the link mentioned above which works for me now:
@echo off
rem based on: https://wiki.tcl-lang.org/10922
rem %1: name of the executable (without .exe)
rem requires: .ico named after the executable
attrib -r "%1.exe"
copy "%1.exe" "work1_%1.exe"
upx -d "work1_%1.exe"
reshacker -delete "work1_%1.exe" , "work2_%1.exe" , icongroup,,
echo TK ICON "%1.ico" > "rc_%1.rc"
rc "rc_%1.rc"
reshacker -add "work2_%1.exe" , "work3_%1.exe" , "rc_%1.res" , ,,
upx "work3_%1.exe"
copy "work3_%1.exe" "%1.exe"
attrib +r "%1.exe"
erase "work1_%1.exe"
erase "work2_%1.exe"
erase "work3_%1.exe"
erase "rc_%1.rc"
erase "rc_%1.res"From http://code.google.com/p/tclkit/issues/detail?id=6#c1
Reported by [email protected], Mar 05, 2010 I know this has been an ongoing issue, I finally rolled up my sleeves and dug into the sdx code. I figured out what the underlying problem and solution is for replacing custom icons using tclkit / sdx to wrap starkits. Pat Thoyts, please consider putting this fix in the sdx code as soon as you can.
The problem: when replacing the tcl icon with a custom icon in a starpack using the latest tclkit (8.5.8), you will likely see the following messages:
icon 48x48/256: NOT SAME SIZE icon 32x32/256: NOT SAME SIZE icon 16x16/256: NOT SAME SIZE icon 48x48/256: NOT SAME SIZE icon 32x32/256: NOT SAME SIZE icon 16x16/256: NOT SAME SIZE icon 48x48/256: replaced icon 32x32/256: replaced icon 16x16/256: replaced
This causes the icon in your starkit exe to only be partially replaced (3 of the 9 images). I got to thinking, why does the 256 keep repeating.
The explanation:
I unwraped the sdx kit and took a look. It turns out that in the sdx code, the 256 represents the number of colors. However while opening the ico file and inspecting the contents, if the sdx wrapping code sees 0 it sets the number of colors to search for 256. However, according to what I found on wikipedia 0 represents true color, which of course Vista / 7 (and I presume at least XP / 2003) support. I suppose this was a holdover from when the starpack solution was first created.
The starpack code create an array of images found in both the original icon and the new icon with the array element name of width X height X numberofcolors. It then tries to match the array in the original with the same one in the new icon file. If it finds one it checks the size. Since the number of colors is incorrectly set to 256 for those above 8 bits, the sizes will not match.
The solution:
1. unwrap sdx.kit
2. navigate to the wrap.tcl file
3. in the procedure decICO, change the line
lappend result ${w}x${h}/$cc $imageto
lappend result ${w}x${h}/$bc $image(bc is the bits per pixel ... http://en.wikipedia.org/wiki/ICO_%28file_format%29 ). We'll use the bits per pixel as part of the array index as opposed to the number of colors.
4. rewrap sdx.kit
5. rewrap your application.
You will see the following output when you rewrap your app (assuming you have the correct images in your ico file:
customizing tclkit.ico in executable icon 64x64/32: replaced icon 48x48/32: replaced icon 32x32/32: replaced icon 24x24/32: replaced icon 16x16/32: replaced icon 48x48/24: replaced icon 32x32/24: replaced icon 24x24/24: replaced icon 16x16/24: replaced icon 48x48/8: replaced icon 32x32/8: replaced icon 24x24/8: replaced icon 16x16/8: replaced
I hope this ends this longstanding issue once and for all. Pat, please let me know what you think.
Thanks, Patrick
Comment 1 by patthoyts, Mar 09, 2010 I checked this wrapping up the curent tclkit 8.5.8 with a custom icon for tkchat which has 64x64/32 and others and it now works perfectly. Patch applied - thank you very much.