I just noticed that if you want to assign an icon to an audio file, it has to be an icon-type graphic file like .ICO, .EMF, or .WMF; unlike (for example) a custom LINK graphic in a playlist, or a custom Player button graphic.
I presume the requirement for an ‘icon-type’ file for an audio file icon is a requirement/limitation of an ‘icon’ column in a Virtual Treeview component? I was just curious to know!
Also, I have not tried it yet, but if an audio file which has its own icon defined (in the file’s Properties) is loaded into a Cartwall Player, is the file’s icon displayed or not?
The file types supported are those which can be handled by Delphi’s TGraphic component.
The PNG library I use for the (manually drawn) playlist icons etc. has an option to add PNG support to TGraphic, but it makes mAirList crash under Windows 98/ME, so I have disabled it recently.
Icons are not displayed in any player. Perhaps we could introduced this once I start the long-planned redesign of the player component.
To create a custom default Playlist item icon, you need a PNG file; to Select a custom icon for an individual Playlist item in its Properties dialog, you need (for example) an ICO file.
I know you said that the Delphi component you use in the Properties dialog for a Playlist item’s Icon cannot use PNG files, but:
I think most people who want to use custom icons will set up a full set of icons for everything, plus a few extra ones for (e.g.) pre-recorded interviews (say, a microphone icon), station jingles (maybe an icon based on the station logo), etc. and put all of them in one folder.
By the way, when you select an icon for an Playlist item, the file select dialog should IMHO default to \images ;).
So, having most probably created your icons as PNGs to replace the defaults plus have some other ‘approved’ selectable ones for other types of items, it’s a pain to have to convert those to another format like JPG or whatever as well. (Needless to say, I personally started with grabbed ICO files and converted those to PNGs, but you get the point, I hope! ;D)
Having two separate sets of the same graphics increases the chance of mismatched PNG/ICO versions of the ‘same’ graphics. Is there no way you could allow the use of PNGs in that Playlist Item Properties dialog? That would be the nicest way to solve the problem, because everything else in mAirList uses PNG. Maybe replace the component in the dialog with a different one that supports PNG?
For the internal icons, I will continue to use the other library (PNGDelphi) which offers full transparency (alpha channel) support, unlike GraphicEx. So if you want to replace any internal icons or buttons, these still need to be in PNG format.
None of my existing audio files (using MMD files) are showing their custom icons ;( I can set them and recall them, but if I have to do that to the songs, jingles and ads on the Phoenix FM PC - I’ll be there all day!
I suppose that GraphicEx does not recognize the image files previously stored with Delphi’s internal file format handlers. Can you please send me one of the MMD files for reference?
Unfortunately, Delphi does not provide any functions for saving or loading pictures (of an arbitrary supported format) from/or to strings so that they can be included in custom files (just like MMD files). In order to achieve this, I have used a trick found found in some newsgroup. Basically, it works by first writing the name of the graphic class (in terms of object-oriented prorgramming) and then its data. The output is then encoded as base64 and included in the XML file. When the MMD file is read, the name of the class is extracted from the string, the class is located and instantiated, and then its “LoadFromStream” method is called in order to retrieve the data. The problem is that the data written this way by the old PNG library (used in pre-v.41, and unfortunately incompatible with Windows 98/ME) cannot be read from the respective PNG classes from the new library.
It seems to be impossible to work around this problem.
The only clean solution in order to avoid this problem for the future is to store the image data in a different way, i.e., storing the file type or extension instead of the class name, and storing the raw input file data instead of the data returned by the class-specific SaveToStream method (which might be incompatible to other image libraries, even for the same file type).
Furthermore, I could add the option that only a reference to an image file is written to the MMD instead of the image data. This makes it easier to replace the icons.
As soon as I have decided on a solution, I will provide a batch converter so that you can convert your existing MMD files to the new format.
Well, the new implementation is finished, and it is much more flexible as the old one. It stores the icon data in its original format, plus the original file extension.
Additionally, I will now add the ability to store only references to icons. Then you only have the filename inside the .mmd file, and the icon file is read from disk when the item is loaded.
Charlie, how many different icons do you use at Phoenix FM?
Attached are my 4 icons plus the 2 “Link” images that I made. Copy the contents of these ZIP files to \mAirList\icons and \mAirList\images respectively…
Isn’t it the case that that icons and images should both be copied into \mAirList\images? Custom Icons in that directory are identified by their name (icon_something.png). That was my understanding when I asked Torben about it.
Here’s a little script which loads a custom icon into all items of the current playlist, and then saves it to the MMD files:
[code]var
i: integer;
begin
for i := 0 to CurrentPlaylist.GetCount - 1 do begin
CurrentPlaylist.GetItem(i).GetPicture.LoadFromFile(‘c:\test.png’);
CurrentPlaylist.GetItem(i).SaveMMD;
end;
end.[/code]
This script can be used in order to batch-upgrade your MMD files to the new image format used.
No, definitely not. You’re probably using v.41, but this script needs v.42. Just because the new XML storage mechanism for icons (and its corresponding script commands) has only been introduced in v.42.
For reference:
v.40 and below: Old graphic library, old storage mechanism.
v.41: New graphic library, old storage mechanism (which, as it turned out, fails to load the images saved with the old graphic libraries).
v.42 and up: New graphic library, new storage mechanism (which stores the images as raw base64 data, thus independent from the graphic library used).
Regarding transparency, the new graphic library cannot handle certain PNG features. Can you please send me one of the icons?
