I got the new lock today. Haven't even unboxed it yet though. I banged away on the code and made some good progress, so hopefully in a couple days I'll be back to the point of being able to try it.
In other news Thug Rose Namajunas upsets heavy favorite Joanna Jedrzejczyk. I called it exactly on about five different YouTube videos and got abused badly for that. Should have bet a bunch of money on it.
I am doing a new system for a friend and while doing the interfaces I have come up with a few new requests for discussion.
Group Variables - With lighting there is a lot of repetitive work, button, slider and progress bar.  all need to be tied to the same single field.
Placement is always the same relative to each other.  What I would like to see is the ability to assign a variable to the widgets (a local variable) and then group them together and then assign a local variable to the group that has an assigned value.  in this case I would have a local say LVar:FieldName and that would be assigned where ever the moniker.field needs to be used.  When I group them I then assign that variable to the group and give it a value Lighting.Kitchen (for the kitchen light).  This would speed up deployment significantly.
Groups - when you select a group, there is nothing to edit in the attributes.  On the other systems I work in, when a group is selected the widgets of that group are still able to be edited without having to break the group - this is invaluable.  See the attached screen shot.  The layout is similar to what we have here, but there is a tree structure of all the widgets on the IV above the attributes that allows this to be made possible. (Group can be renamed as well)
Multiple selection of widgets - if you select more than one widget, it would be great to be able to change attributes on all of them at once.  Lets say you have text on the screen and they are three different colours and you want them all the same colour.  You should be able to select them and then the attributes pane shows all common attributes only and attributes that are different are blanked out.  In this case the colour would be blank, but I could select it and change the colour and they all would take on that change. (Its a simpler version to the copy attributes feature)
More attributes - add more attributes like width, height, position etc so that they can be accurately entered.  Set size on the right click really needs to be in the attributes pane.
Toolbar - When editing an IV the tools needs to be in a toolbar so you don't have to switch tabs to use them.
Widget List - A widget list so that you can select a widget that is underneath another widget.  Goes hand in hand with the grouping request.  AT the moment, I have to move the top widget so I can select the bottom widget and then re-align everything after the changes have been made.
Colours - A small swatch of the selected colour adjacent to the field would help in quickly understanding the colour that is being used - at the moment it is just a number.
Attribute Variables - Another option to consider is introducing user variable for interfaces that represent stuff - such as a colour.  I could create a colour (198, 198, 198) and give it a name PBFill (Progress bar fill) and then use that new colour as an attribute (av: PBFill).
In one of the system I work in its called an expression variable (ev) and you create an ev and then assign its data type (color, Boolean, String - about 30 different types).  The ev can then be used in all valid data type properties/attributes.
Attribute expressions - I asked this before and you have commented on it, but I'll put here again.  The ability to put expression s in attributes would be awesome.  e.g.  If field.moniker > 15 then av:red else av:green.  This is in a color setting attribute and used the above mentioned attributes variable to make it more readable and faster to code and can allow simple colour changes based on a field changing value.  Nested if else statements and regular expressions can make it a very powerful graphics editor.
Anyway, that's enough for now, just my wish list based on my experience with graphics creation.  I do this professionally so I get to play with a few different systems and CQC is getting close to one of the better ones - my favorite is still the ABB 800xA graphics editor, which a lot of this is based on - but you are very close to how it works now.
Mick
On the lighting thing, consider using the dynamic content generation capability. That could save you a lot of time, and make it more flexible moving forward.
On the covered widget selection, you can drill down through the layers to select a specific one. If you go to:
/Tools/Admin Intf/Customize/Interfaces
in the help, and check the hot key list there it's documented there. You can only select a single one at a time that way. But, once selected you can arrow it around to move and size it and modify its attributes and such.
You can change the size and position of widgets in the attribute bar. Just edit them in place. For position, either a point or the origin of an area, you can also, while it's selected in the attribute editor, hold down Alt and use the arrow keys to adjust the x/y as well.
The group attribute editing thing is tricky, which is why it's not been done. It would require finding all of the attributes that are common and only showing those. It's already on the list to be done.
I was under the impression that dynamic content generation was for V2 drivers - which the C-Bus driver is not.
None of the lighting fields appear so I think that's the reason.
Alt-click selects the widget below
I mis-interpreted the Area attribute, but now I can see that its x,y,w,h
The other issue I find is trying to work out what type of widget I am working on.  It would be nice if at the top of the attributes it had a title for the widget type.
You might be able to load a v2 driver, generate the templates and then do a find and replace to switch it to the cbus driver.
(11-05-2017, 03:34 PM)znelbok Wrote: [ -> ]The other issue I find is trying to work out what type of widget I am working on.  It would be nice if at the top of the attributes it had a title for the widget type.
I ran into this one today too.  It would be very nice to see the widget type easily.
I also can't get used to how you have to click into a text box in the editor fields, type new text then hit the Enter/Return key to update.  I don't know how many times I retyped fields today after just clicking on the next item in view without hitting enter first. Would be nice if text saved without that extra key press.
The enter gives you a chance to back out, which you wouldn't otherwise have. That could be very useful in many cases.
The widget type is in the status bar at the bottom. The active tab controls the status bar and displays info there if it has any to display. If it's a template tab then the currently selected widget type, id, and area is displayed down there, along with the full path to the template now I think as the last value.
Auto-gen is V2 drivers only. I'm talking here about the ability of overlays to dynamically generate content of a repetitive nature on the fly. It can be very useful for the kinds of things you are talking about. See the docs for the overlay widget.
Well, in a lot of ways the internet is a big ball of fecal matter, but this is one of the amazing things itÔÇÖs created. ItÔÇÖs ridiculous that kids this age are developing these types of skills so early. They see other people not much older than them doing it so they start doing it even earlier. I clicked on it expecting an ÔÇÿawwÔÇÖ type clumsy but cute moment, but then she ripped it up.
https://www.youtube.com/watch?v=yyIfWL2FGNA
BTW, the reason for using another tab for the alignment and other tools instead of a bar is that people were already complaining about how much real estate is being eaten up by the non-content parts of the window and a tool bar would be another chunk gone. It wouldn't need to be a big chunk necessarily, but still more gone. And if other tools show up, we'd have to have some place to put them, and doing them as tabs allows for a lot of tools to fit in one space.
So, I was bogging down in the new Z-Wave standalone library, and starting wondering if this was worth it. And I also started thinking how bad it would be if I did all that work and I STILL couldn't get it working right. So I went back to the driver again for a test with the new lock, and it's the same. So I'm pretty sure it wasn't the lock but something I'm doing wrong.
Whatever it is, I can't figure it out with the information I have, and I've wasted a ridiculous amount of time on this. I think I'm going to just bail out on it and do another VRC0P based one instead. I'll take the new driver and replace the stick with the VRC0P, which will require throwing out some code because it won't be doable anymore. But, otherwise it can basically stay the same. So it'll still have almost all the new driver's benefits.
I won't build msgs in the VRC0P form, but continue to do them as raw Z-Wave msgs, and just do a wrapper class around the VRC0P that will expose the msgs in that raw Z-Wave form. That way, later, it won't be too hard to go back to a native interface if we can get ahold of the information required to make it actually work. I could also use my own security stuff as well if I wanted to, but that's easy enough to hide whether I'm doing it or the VRC0P is, so I'll probably just let it do it.
* But I could do V2 security myself still when that becomes available, since the VRC0P won't understand that. At first I thought I couldn't drop back to the VRC0P for that reason, but there's nothing preventing me from doing myself. So we won't get left out of V2 security based devices when/if they start arriving.
And all the benefits of the new driver wrt to being able to handle more types of units and such will still be there, since it'll be the new driver just based on a different Z-Wave network on-ramp. We lose some ability to do so some low level (non command class) stuff, but I have noticed that more of that than used to be the case is now supported via new command class interfaces, so it won't be as much as I'd originally thought.
Oh well, what can you do. At the end of the day, we need the info and we don't got the info, and it's just to complex to get right without it. Did I mention that I loath Z-Wave?