Is there a limitation to [Active Touch] using Chameleon images?
dthorson
Junior Member
I have a TP file where I'm using chameleon images for buttons that overlap.
The buttons touch style is set to active touch. So I'm expecting that only the visible parts of the button would be 'touchable". This is not the case, so my overlapping buttons that look well do not touch so well.
If I use a static bitmap with a fill color of transparent, all is well.
I'm assuming that since the chameleon images use a fill color of some value this is causing a problem with how active touch works. Even though parts of the button look transparent, the active touch doesn't see it that way.
Anybody have a work around? I'd really like to stick to the chameleon images with palettes for my GUI design.
The buttons touch style is set to active touch. So I'm expecting that only the visible parts of the button would be 'touchable". This is not the case, so my overlapping buttons that look well do not touch so well.
If I use a static bitmap with a fill color of transparent, all is well.
I'm assuming that since the chameleon images use a fill color of some value this is causing a problem with how active touch works. Even though parts of the button look transparent, the active touch doesn't see it that way.
Anybody have a work around? I'd really like to stick to the chameleon images with palettes for my GUI design.
Comments
-
Transparent Buttons
I have found that the "draw order" parameter can cause issues like this.
Sometime, even though you cannot see something visually, TP4 still believes it is there.
Typically, I have to make sure that my border is set at the top, or near to the top of the stack. -
I do not believe the firmware will use just the chameleon image for its active touch region in the absence of a bitmap. So, without a bitmap or a border, the button's touch area is its bounding box.
-
Check out this Wiki:
http://en.wikipedia.org/wiki/Mask_(computing)#Image_masks
Chameleon imaging, you must understand, is a form of masking, the only difference is that TPD4 is also tossing in a couple of variable colors (fill and border) when drawing the image in its entirety (in fact you can even change the draw order). But however the color properties are introduced, when drawing the bitmap the framework is simply referring to the Chameleon (Mask) image for bitwise operations of "should this pixel be drawn, and at what opacity in relation to the color its being drawn to?"
With that said, a mask doesn't exist in the same way that a bitmap does; it's not referred to for figuring the actual dimension of the graphic, but only for its rendering purposes.
Hope this helps.
Categories
- All Categories
- 2.5K AMX General Discussion
- 922 AMX Technical Discussion
- 514 AMX Hardware
- 502 AMX Control Products
- 3 AMX Video Distribution Products
- 9 AMX Networked AV (SVSI) Products
- AMX Workspace & Collaboration Products
- 3.4K AMX Software
- 151 AMX Resource Management Suite Software
- 386 AMX Design Tools
- 2.4K NetLinx Studio
- 135 Duet/Cafe Duet
- 248 NetLinx Modules & Duet Modules
- 57 AMX RPM Forum
- 228 MODPEDIA - The Public Repository of Modules for Everyone
- 943 AMX Specialty Forums
- 2.6K AMXForums Archive
- 2.6K AMXForums Archive Threads
- 1.5K AMX Hardware
- 432 AMX Applications and Solutions
- 249 Residential Forum
- 182 Tips and Tricks
- 146 AMX Website/Forums