Code driven page jumps.

Jeff Lockyear

I'm looking at changing my ways from having my page jumps in TPD to having them in code. I've done a little here and there, but I'm starting to run into cases where the panel design I want to use doesn't really support page jumps in TPD; at least not easily.

I was wondering if anyone had any tips to point me in the right direction before I hare off and start whacking out code.

I typically try to have my panels work the same way and have the same design, but inevitably there are differences that make the panels individuals. Never ask a client for their opinion....

Thanks.

PhreaK

Welcome to the light side . A good practice to get into (at least, this is what I've found) is to try and abstract your GUI code as much as possible. This is not just for you, but for the sanity of anyone else who adds to, modify or attempts to wreck the job in the future. When everything is handled from TP design its nice and easy to open up the panel and have a look at what interface guff is associated with each button and get a general feel for how it all fits together; not so much when you have a mass of code with 'PAGE-x' commands strewn throughout.

Jeff Lockyear wrote: »

Never ask a client for their opinion....

Why are they paying for a custom system then?

TurnipTruck

Jeff Lockyear wrote: »

I was wondering if anyone had any tips to point me in the right direction before I hare off and start whacking out code.

What got me started in doing page flips in code is the ability to send exactly the same UI file to all panels in one system.

If you have multiple panels, each in their own room, you would probably have a unique lighting page for each room. Rather than only having the control page for room one in the fie for panel one and the control page for room two in panel two, put all the pages in all the panels.

I would then name the pages something like Lighting1, Lighting2, etc. This way you can use a simple variable table to flip to a certain page from a certain panel with something like SEND_COMMAND dvPanel,"'PAGE-Lighting',ITOA(variable_derived_from_code)"

vining

There's always somethings that should be code driven as TT illustrated. I beleive in the combination approached and will generally always drive pages through code so I can regulate FB but once on a particular device page the pop ups may be driven directly by the TP buttons. Although things like error pop up, warnings and any pop ups that need dymanic driven VT for lists, etc.

I could conceive doing everything in code but lazziness always prevents it.

ericmedley

I've been on the 'panel navigation driven from code' for a long time. I think doing systems with high numbers of touch panels just necessitates it.
The only time I use the panel's navigation is for shutting off "Are You Sure?" popups.

Jeff Lockyear

TurnipTruck wrote: »

If you have multiple panels, each in their own room, you would probably have a unique lighting page for each room.

That's exactly what started me on this path. I can make all the music and general control (HVAC, Spa, etc) common among all the panels, but it's always lighting that splits them up. I didn't consider putting all the lighting pages on all the panels and just sniping the one I want for a given panel.

jjames

Here's what I did with the lighting pages on a recent job. Quick scope: 18 panels. ~140 Litetouch keypads in the house. Some panels take the role of more than one zone sometimes.

Solution: Put the keypad & layouts in the code. I have an array that shows & hides buttons based on how many buttons there are. If there's only three on a keypad, buttons 2, 5 and 8 are shown. If there are six buttons on a keypad buttons 1,3,4,6,7 and 9 are shown up. (1 being upper left, 9 being bottom most right; 3x3 configuration.)

I have 9 buttons on each page, then hide & show accordingly. All buttons have dynamic text. Makes it nice to have a common page. Just changes via code.

Jeff Lockyear

How about sending the page flip trigger; channel or string from the button?

jjames

What exactly do you mean by sending the page flip trigger? If you're asking me, in my situation there was only one popup called by code in a function that determine what should be displayed after selecting a category.

DHawthorne

I still take a hybrid approach. Some page flips I leave in the panel, but very few. The main advantage of code-driven flips is that it provides a true indication of what the system is doing, not what the panel thinks it's doing. In a multi-room, multi-panel system, it's indispensable, and changing the room the panel is controlling automatically can flip to the page that is appropriate to the current state of the room. I also liberally use ^SHO to hide and display buttons that are appropriate so that as you navigate from room to room, options that aren't available simply don't appear (for example, it's common for us to distribute most sources from a central location, but still have a local source, like a game console, that is only available in one room).

The kind of flips I leave in the panel are the ones where a source might need several pages, and the panel handles those. That's pretty much about it. I used to keep almost all my flips in the panel, and still have jobs out there where that happens, but it's not something I do on a new job anymore.

Jeff Lockyear

Perhaps I'm still thinking old school.... When a user presses the "Climate" button, that panel needs to get to the climate page. I figured the "Climate" button would need a channel number or a string output to tell my program that it has been pushed, and hence needs to go to the climate page.

With audio page flips I would have a channel trigger the switcher programming, so I could send page commands based on that. It's buttons that are purely for navigation that I'm wondering about.

jjames

Ahh - yes. There needs to be a button event associated with a flip.

Navigational buttons to me sometimes are more difficult than controlling or selecting a source. I mean seriously, how difficult (after a while) is it to send a PLAY command? Or to turn a TV on? It's easy to control a device. It's the logic that goes into the GUI that can make or kill a project. If the user is having issues getting to a place in the panel, it doesn't matter if something isn't working. As programmers we are responsible for A LOT in a job - making it easy for the user to understand and use is part of it, and that includes getting them to where they need.

I group all of my buttons in arrays: transport, power off, source select, categories and special buttons. Everything except the transport (and sometimes the special ones, i.e. presets, etc.) buttons call some kind of page manipulation.

Quick question for you Jeff - are you using lots and lots of pages, or a few pages and lots of popups?

Jeff Lockyear

I currently use a few base pages and lots of popups (love those slides and fades).

I'm also a big fan of arrays for channel numbers.

HARMAN_icraigie

I've got a couple of programming models where the UI have considerably end user configuration options. Other than closing notification popups all page turns are driven from code.