Icons, custom characters

Aug 11, 2011 at 7:41 AM

I have decided to use the Icon tag to display an icon instead of Mode.

After using the volume screen and its $Bar function, the icon vanishes. Looks like $Bar takes over the custom characters

Can mce_dll make sure to re-appropriate them each time ?? Or provide a compatible $Bar function ?  whichever is simpler...

Thanks for looking into this.



Aug 11, 2011 at 3:39 PM


      the code looks like it always sends out the custom character definition followed by the character code so I don't see how this is happening although I do remember some issues mapping the custom character to the code which is a bit convoluted in Smartie. What version of MCE_dll are you using? One possible explanation is that for the mode status the code outputs a single character bar with the height reflecting the volume. It may be this piece of code that's not working. I'll check when I get home on my LCD.


Aug 11, 2011 at 4:48 PM

A couple more findings...

At some point in MC startup sequenece, DisplayMode=Volume and the volume screen displays, which is normal. This initial display of the volume screen does not affect the icon.

I also made a screen which shows both the Icon tag and my own custom character. If I set my custom char to position 1, Icon character is replaced with my own custom character. I have set it to position 8 instead and it works now. Well, that is until the volume screen messes it up !

I wonder what it would do if I set Mode tag values in MCE_dll.cfg to custom character strings then call the Mode tag to show my icons... I'm up to some more testing tonight.


Aug 12, 2011 at 6:12 AM

I have found the problem. Nothing wrong custom characters or $Bar...

When DisplayMode=Volume, it also replaces the Icon tag with a blank icon, since there is no icon for volume changing. If it is on Mute, the icon becomes the mute icon. Once the StatusCounter is done and my previous screen re-enables, DisplayMode still reports Volume, hence the no icon, or the mute icon.

Of course the initial appearance of the volume line does not affect the icon, this icon is the NotMute icon !

The solution I come up with is to split up the DisplayMode tag and associated Icon. Let's say with a VolumeDisplayMode which I would use to enable the volume screen, and its matching VolumeIcon, and a TransportDisplayMode with TransportIcons, for Stop/Play/Pause/rew/ff, unaffected by any volume change. This in turn would require generating two custom icons at once, I don't know how difficult this would be...

Another solution would be to be able to disable changes to Icon for Volume and Mute DisplayMode values.

Aug 12, 2011 at 9:27 AM

Hi, I've uploaded change set 8273 (v0.9.18.15) which should resolve some of this. There was an issue with the volume custom character which I think was using the wrong character code. I've changed this so that it uses character 1 (176) as the others do. So your position 8 should not be messed up by the volume icon any more. Mode no longer includes Volume or Mute and the Icon (and display mode) revert back to the mode after the timer completes. I've increased the storage size for tag values so you can use 2 icons if that's your want :-)) and changed the way it stores the custom character definition so it's the complete string rather than just the bit definitions. This solution is slightly different to your suggestion but Mode should be your suggested TransportDisplayMode and DisplayMode should enable your volume screen.

Aug 15, 2011 at 5:38 AM

Merely updating the dll with this new version was sufficient to fix all icon display issues. No other modification needed. It wouldn't be honest to time pretend this solution does not work exactly as I want :-) Ultimately it implements my second solution and Volume no longer updates Icon. This new "auto fallback" behavior also means leaner action lines which is very welcome.

If Mode=Play (whatever is playing) then I start audio playback, Mode=Stop. It does that only with audio, if I start any other media it correctly switches to Stop then Play again. Looking at the tracer output makes me suspect there is a missing Stop message when enabling audio as compared to other types yet I find it odd that the last message is Play=True while Mode is stuck on Stop. Pressing play once audio is playback is started updates Mode correctly.

Also, when Recording stops, Mode updates to Stop. Recording should not touch to Mode.

Otherwise I've been looking quite extensively for error conditions and have yet to find something else wrong.