Posted: February 25 2004 at 22:32 | IP Logged

I have been looking through the PH documentation and saw on page 24 of the present manual a sample Control Panel window that has some features I have not been able to figure out how to duplicate when designing my own.  First, I note that buttons tend to be grouped with darker or lighter colored backgrounds - "button boxes" if you will.  Also, most of the buttons have their descriptive text OUTSIDE the button, rather than inside it.

Are the button backdrops created using bitmap images, or are they created by some creative use of undefined buttons just resized and colored to form a backdrop?

How do you add text labels, or move button labels outside the button itself?

What methodologies were used to create the sample display shown on page 24 of the PH documentation?

Thanks for your help.

Posted: February 26 2004 at 10:00 | IP Logged

Yep, Tony's correct...the way its done is with a background GIF.  I could use a BMP just as well, but then it would'nt be visible in the web based Control Center (It sounds as if you're using version 1.02.2.  In case you didn't know it, the beta and the next version will allow you to see your Control Center ON THE WEB).  By sticking to graphics that are browser supported (GIF and JPEG), I can have my Control Center in both the client and the web.

Ive had requests for being able to add button groups, text outside a button, etc.  but have not worked on it yet.  I could do quite a bit in the client, but would be a little more limited on the web so anything extra I do add would need to work in both.  The next version after 1.03.2 will be a step in that direction as all the Control Center buttons will be moving to their own table.

Another reason why you may prefer the graphic approach even when new controls are available is that it consumes less memory.  Each item in the Control Center is a separate object and consumes its own little bit of memory to track it.  A graphic is a single object.

To create graphics like in QC.GIF, you could work with a simple program such as Windows Paint.

Hope this helps,

Dave.

Posted: February 26 2004 at 13:04 | IP Logged

When I get around to it, I'm going to see if I can create 'dummy' buttons that can be resized fairly large, to serve as backdrops/enclosures for smaller buttons.  For this to work, there will have to be a way for me to create a button that is essentially a NOP when pressed, and, will always give other buttons foreground priority.  I have not tried doing this yet, as I am still trying to learn other aspects of PH programming and setup.  I'll let you know how my experiment turns out once I try it.

At this point, I'm too lazy to install and set up and use a image editor to create custom backdrops for my controls

Posted: February 26 2004 at 21:08 | IP Logged

Mark,

I was curious how this would work out so went into the code to see what would happen as as verify how it actually works.

And.......I don't think its going to be viable.  Theres no way to directly control the front to back order of buttons.  You can indirectly control it however thus: IR buttons are drawn first, then X-10, then Macro, and last Send Keys.  Within these 4 groups, the ID of the button is then sorted next followed by the key number.  So you could create a piece of IR equipment and name it 0 and have its buttons be beneath all other buttons (assuming you didn't have another piece of IR equipment whose ID would be alphabetically below 0).

In the new version, you even can make the border a box, lowered, or raised, so it would not even appear as a button when it is clicked.  You could also set the "Code" field to a "#" (pound sign) and the button would not react.

Now comes the bad news.  Anytime you move the mouse over this "Background" button, the cursor will change to a hand.  The worst part is that when you try to click a button in the foreground, the algorithm for searching what button was actually pressed is performed in the same order that the button is displayed.  In other words, PowerHome will take the X/Y coordinates of where you clicked and search the internal table until it finds a match.  This is going to be the "Background" button.  As soon as it finds a matching button, the search is terminated and that buttons action is performed.  In this case nothing .

Now I could probably fix this in an interim release by just changing the search from back to front so that the "Background" button would be last.

Dave.

Posted: February 29 2004 at 01:59 | IP Logged

Perhaps add a boolean field in the tables that can create CC buttons (e.g. IR, X10, Macro) that specifies whether the button is active or not.  If not active, it is not searched for when doing a coordinate match.  In essence, when this "disable" flag is set (or an "enable" flag is cleared) the associated button would become un-pressable.

Now, what would *really* be cool (something to consider for v2.x, perhaps) would be able to place almost any sort of GUI control (buttons, spinners, sliders, radio buttons, list boxes, drop-down menus, etc) on a control panel page, and somehow tie these into macro execution when the controls are adjusted.  Such functionality is probably overkill (not to mention programmer-killing ) but it would be cool.

Now, what might be more realisitc for future versions would be the addition of the ability to draw certain basic primitives (lines, boxes, circles and such) on a CP page - perhaps by tying these primitives into another table that stored the properties of the object primitives along with what CP tab they appear on.

But for now, the existing ability to import a bitmap image for purposes of creating backdrops and such is a reasonable solution for 'prettifying' the CP pages.