TPD5 Chameleon Images Faulty?
Serk
Posts: 1
It seems TPD5 Chameleons are broken... The red and green no longer affect the image. Only pixels that are NOT black change colour but they still don't scale, it's one solid colour throughout the entire image.
0
Comments
Additionally, from the firmware release known issues list (http://www.amx.com/techcenter/firmware.asp) :
"Some Chameleon Images are not displayed as they are in G4 and TPD5. There is limited support for Chameleon Images in G5, and some forms of Chameleon Images are not rendered in the same manner. These images must be reworked. "
It'd be one thing if I developed it on my own, but I spent multiple weeks less than a year ago redrawing my standard layout using the new images you provided, and now the chameleon stuff isn't working right.
Indeed. I didn't think we'd actually be losing cool features that have been around for years with the new panels. While progress sometimes mean a lack of backward compatibility, I would have thought the new panels could handle this easy task.
Paul
If you want text to change color to show status, all you need do is layer multiple buttons with text in each color, and selectively activate the button with the color you want. Simple. Same with border colors. No more using them to flag active statuses.
These are slightly offset by new abilities to scale bitmaps, so your buttons can be bitmaps instead of borders, and sized as needed. But it's a whole new mindset, and requires massive jumping through hoops to do interesting things - especially if your job requires a mixed generation panel set. Entirely different way of talking to G5 than to your G4 on the same system. This is worse than when G4 replaced G3, G4 was much more nearly entirely a superset of G3.
I thought that was what multi state buttons were for.
Paul
They can be. But we used to be able to programmatically change color, font, border, colors, etc.
So a single panel project could be told, on the fly, to present nearly anything in any manner in any color and font.
G5 requires all that to be pre-composed, and turned on and off like flash cards. So as long as you have already thought of everything you ever want to display, and build it all into the panel in multiple iterations (buttons, multistate, etc.) you are fine. Decide later you need anything different, you merely redesign all the panels and deploy again, as well as write new code to drive it.
This is another barrier to adaptation and change and innovation, and a retreat from comprehensive power that was an earmark of a high-end control system product. I'm not understanding AMX's business plan to offer the world's most expensive Android tablets.
I'll have to look at the G5 documentation. Not having seen one in real life I was unaware that this was the direction they are going, and assumed that this change from G4 to G5 would be similar to the G3 to G4 change, where G4 commands were more or less a superset of G3 commands. I can see how this would impact your design style, since you have one UI that is configured from code, so these new panels pretty much ruin that design paradigm. Most of the labor goes to UI design and changes, so I figured the G5 panels would allow more code driven configuration not less. This would also make projects with both G4 and G5 panels pretty much impossible, or extremely tedious to create, not to mention error prone. Bizarre.
Paul
Perhaps the limited support means that these features are going to be replaced with a more modern solutions?
I hope so anyway...
Thin fonts pixilate and don't render correctly.
-Would like to see this replaced with the Android font rendering engine?
The borders are effectively 8 alpha images pieced together around the button.
-perhaps this will be replaced with a vector stroke / CSS3 type solution like most modern graphics applications?
Text effects pixilate and are harsh.
-perhaps this will be replaced a vector stroke / CSS3 type solution like most modern graphics applications?
On a positive note the collapsable pop-ups are quite handy.
Modern solutions would be fine if (1) no functionality is lost, and (2) it's deployed in a timely fashion. We aren't seeing either yet.
Yeah, chances are you'll spend time to rework code and GUI designs to make things work for now and then once you're done the newer adroid capabilties will get implimented so you'll have to rework code and GUIs for that and still deal with backward compatabilty for any mixed systems.
Paul
Exactly. I'm now spending the better part of this week porting my G4 design to G5, redoing all of my chameleon images into different layouts, and trying to figure out how I'm going to do things like change the color of text on buttons. Meanwhile, since this system also has an iPad in it, I'll still have to support the G4 commands there, plus I can't copy and paste between panels when I'm creating it.
In other words . . . bah. Not impressed. And it's a shame, because there's a lot of good stuff here, just some key things screwing it all up.
I also use this effect often, along with a couple of text effects and borders I have made. Can copy them into the G5 support files, show up in TPD5, but full clean transfer has been removed so I cant download them into to the panel.
scale them in tp5? how?
EDIT...
"scale to fit"
!%@$!%^!@$%
I think there are still so many issues and unsolved tickets from TP4 that aren't fixed in TP5.
Just to mention a few...(both firmware issues and TP4/5 issues here)
-Chameleon images:
(Always centers in the button, no way to position it top/middle and have text below.
Border transparent issue, resize the button larger then the size of the image and you'll have a background color filled area outside the chameleon image filled up to the boundary of the button.)
-Layer order are not the same in TP5 as in TP4 so you have to remake all buttons you copy in from TP4.
-Bitmap Stretch/resize issue.
-Feature to make a group of selected buttons.
-Feature to have G4Web password access from code.
-No Save/read able IP connections list.
-No useful information in the Transfer window (like IP address, time, etc) as we have in Netlinx Studio.
(Try to send to more than 10 or 50 panels and in the run be sure you have not missed any, you won't have any help looking in the transfer history window)
-You can send Unicode text to the panel but you can't read it from the panel.
-Copying a popup from another design will paste at last opened popup/group in destination, not where I place the mouse arrow when pasting.
Why a different program? It only makes it harder for the designer.
You should only need one GUI design program.
The different available edit values should adapt depending on panel choice.
If AMX can't implement the TP4 panel support in TP5, they should have a start choice selecting type either G4 or G5, just make it one program.
What happens now? are the bug support and development for TP4 gone?
We as programmers, designers and companies must have support from AMX that last even after they stop developing/selling the panels.
The clients who buy the panels will have them for many years and we must be able to give them support.
/Dennis
Isn't this still just for DYNAMIC images, not local.
Edited:
Ok I tested scale to fit and it works fine with local pictures :-)
One addition: AMX doesn't have a viable wireless panel (800x480 out of the MVP-9000 just doesn't cut it when the other panels in your system have much higher resolutions, the graphics look horrible). Mostly I think this is because iPads have replaced wireless panels. However, TPControl is in no hurry to develop the ability for their app to read TP5 files, which leaves me with 2 options.
1) Use all v4 panels whenever I need an iPad in the system (disappointing because there are new features both I and clients would like to use)
2) Build your files completely separately whenever you need an iPad (since there's no copy paste between TP4 and TP5)
I don't like either of those options. I prefer the AMX development environment to the competitions by a long shot, but I'm doing more non-AMX systems lately because of all the hassle with getting stuff to play nice together.