CQC User Group Webinar: Sat, 11/29, 8:30am PST

IVB

Senior Member
I'll post login details tomorrow, you'll need both a computer and a telephone as all audio will be done via telephone.

No specific agenda, these user group webinars are typically "what do the folks that actually show up wanna talk about?"
 
does it makes sense to join the webinar if I haven't worked with QCQ yet and don't really have any questions yet, but would like to start getting familiarized with it?
 
Typically user group webinars are slightly more advanced. But, let's see what mustangcoupe has to say on that since he joined without any prior knowledge.

We also have Intro to CQC 101 and Interface Editing/Automated Events 201 webinars, there's recordings in my sig, that would help too.
 
I did think the webinar was informative. but I think the basics of the system needs to be more hands on, with the CQC-101 and a live box (trial license) and some hardware I think you'd be able to get the most of it... I do have some programming background so I pick things up kinda quickly and with the point and click interface it lookes easy. I know today's was "not topic" but a more structured shorter session may be better. or maybe 2-3 shorter sessions back to back with a specific topic, and tune in for the one you want for the basics then the free for all for more advanced sessions.

Thank You IVB for the discussions and samples, I do not know if the money manager (WIFE) will let me consider purchasing at this time, but it is a very good package with (I believe is) a minimal learning curve.
 
My pleasure. Thanks for showing us all how Powerhome works, it's also a very interesting solution.

BTW, I just finished re-uploading the CQC101 webinar recording, it got screwed up when I transferred hosting providers 2 weeks ago (along with my site).

I'm re-uploading the CQC 201 as we speak, it'll be another 20 mins for that to complete.
 
I did think the webinar was informative. but I think the basics of the system needs to be more hands on, with the CQC-101 and a live box (trial license) and some hardware I think you'd be able to get the most of it...

I think that's exactly what i'll do. My plans are forced to slow down a little though due to the unstable situation in south east MI and me and my wife working for automotive suppliers right now!!!

hope you guys had a good webinar!
 
FYI, we'll probably have another webinar in a few weeks as the latest beta has quite a few changes in it. Hopefully a few of us can attempt to use it, and share our lessons learned. That might be a little too advanced for a complete newbie, but you could attend to see if anything soaks in.
 
FYI, we'll probably have another webinar in a few weeks as the latest beta has quite a few changes in it. Hopefully a few of us can attempt to use it, and share our lessons learned. That might be a little too advanced for a complete newbie, but you could attend to see if anything soaks in.

A "What's New" one would be excellent.
 
FYI, we'll probably have another webinar in a few weeks as the latest beta has quite a few changes in it. Hopefully a few of us can attempt to use it, and share our lessons learned. That might be a little too advanced for a complete newbie, but you could attend to see if anything soaks in.

A "What's New" one would be excellent.

Technically, Dean provides that in the release notes. But yeah, figuring out what this means in english and 'splaining that would be nice.

Here's what he said about the latest drop. This is v.16 in the beta, so there's been 15 other ones like this.

Dean Roddey said:
OK, thousands of years in the making, involving the deaths of thousands of slave laborers and beasts of burden, 2.4.17 is finally here. This one involves very large improvements to the interface system that significantly increase its power, and your ability to create dynamic, adaptive interfaces. Though, as always is the case with such large changes, quirks and bugs could have been introduced. So be sure to save your existing system before you upgrade.

Since the bulk of changes are in the interface system, any glitches are likely to be there, not fundamental system killing sorts of things. It's always possible that you did something that depended on unintential side effects that are no longer present. This version tights up things a bit in terms of not allowing things that could be difficult to support moving forward or that were never intended to be allowed. But nothing that couldn't pretty easily be done another way.

It could be a little while before the DNV is available for this version, so don't upgrade if you depend on the DNV more than you are willing to give up to get the new goodies.

It may also be a while before the beta web site is updated to reflect these changes, which are huge in terms of the impact on the documentation. We will probably put off those updates until a few more major bits are done (the bits that have to be done for 2.5.)

The changes are:

  • The changes in .16 to add per-item user data to the static list browser can cause an index exception if the list is empty and an action is invoked which requires getting the RTVs from the browser. It doesn't deal with the fact that the list could be empty.
  • In addition to the new method to set individual user data values on the items in a static list browser widget, provide a command that takes the whole list as a quoted comma string as with the actual values. And add a command to set both lists at once.
  • Update the MyMovies driver to support the latest version, which runs under WHS but which has some database changes. In theory it should still support the old format as well. If under the new scheme, the Cast value is also being filled in correctly now.
  • Add an Error image to the boolean image class, so it can display some specifically if in error.
  • The SendEMail action command isn't setting the authentication type.
  • Allow manual entry of IR receiver data, where a remote will not work correctly for learning directly via the remote itself.
  • The variables target GetText() method is set up to be a conditional command but returns nothing. So make it available as both forms, and for the conditional form let it return true if the value gotten is not an empty string.
  • Backport some stuff from the new Omni driver to the old one, since the new one won't really be reliable for everyone until the 3.0 firmware comes out. Add support for the area arming modes, add a new per area boolean field that's true when in the arming countdown, else false. Add user action events for UPB link and X-10 unit on/off changes (it already supported the macro button press event.) Also the Bypass/Restore area stuff wasn't working.
  • The IR client driver doesn't protect itself against an exception if you double click a command to test it in the blaster tab.
  • Implement a driver for the Global Cache IRL, the blaster learner, so that you can learn IR codes directly in for blasting from the GC-100.
  • Get the updated Lumagen Radience driver into the build
  • The SMTP class isn't dealing with non-ASCII characters that might be in the body of the text. SMTP doesn't support non-ASCII text so there's an ASCII text converter used, and it barfs if it sees somethign that can't be represented. So replace these characters with a space during the processing of the body lines.
  • Change the logo image widget to allow any sort of field. As long as the text formatted value of the field mapps to a valid image name, that's good enough.
  • Completely rewrite how value driven interface widgets relate to the value that drives them, so that they are not hard coded to work just with fields. This will require extensive work because that association was heavily coded into the fabric of the interface system and will require now the polling engine is interfaced to a well.
  • Given the previous change, update many of the field based widgets to support both fields or variables as the source of their driving values. This will require extensive work as well. We'll need to make variables more like fields, with types and limits and such, and all those classes affect will have to be refactored into a bass class plus derivatives for field and variable based ones. Not all of them make sense as variable based, but most do.
  • Given the previous change, some other widgets can also have a static variant now, since it just requires another derivative of the new base class, so make some more static ones as well.
  • Allow the values in the mapping list of a mapped image be moveable up or down, to get the ordering correct. This doesn't change the order of the list in the Images tab, just the list of expressions (and therefore their evaluation order.) The image list order change will have to be done later.
  • Create a new OnPreload event on the Template class which will allow a limited set of action commands to be invoked before the template is loaded. Then move the current Xlat stuff over to that OnPreload event. This will be a far more open ended way of doing such things. Add new LinkToField() and LinkToVar() action commands, which can be called to set new field or variable associations on widgets that are associated with them. This will allow that Xlat functionality to be done in that Preload event.
  • Given that we now have LinkToField() and LinkToVar() action commands, and given that the new way that widgets relate to their source values, we can allow these to be called at any time now to change the field or variable associated with a widget. This will allow for a lot of flexibility for creating dynamic interfaces.
  • There are a few bugs in the Elk M1 client driver interface. The voltage display values update when any list selection is made, not just the volage list. And there's an index error when you try to edit any PLC unit from N.1 and up.
  • The action editor doesn't protect itself from illegal commands being pasted into the current action. So it should go back and check when saved to make sure all the commands are kosher.
  • Update the action editor to allow separate command filtering on a per-event basis, instead of once for the whole invocation of the editor window. We need to filter separately in order to prevent dangerous or meaningless commands.


Dean Roddey said:
So, just a quick overview of what to expect and how to get the most out of this new drop, in lieu of real docs for a while:

Variable Based Widgets

Most of the widgets that can be associated with a field can now be associated with a variable. Variables can have a type and limits now just like a field, and in those places where the type and limits would prevent a field from being used with a widget, so it will prevent a variable. I.e. if you want a variable based slider, it has to be a numeric type and have a range limit.

So, for those variables you want to use with widgets, best to create them up front on load (on pre-load actually, see below), and insure that they have the correct type and limits. Otherwise, if you do something later that implicitly forces the variable to be created (i.e. the set the value of it), it'll be a string type and no limits.

There are a few important reasons why this was done:

  • The implicit ability for widgets in an overlay to affect something in the main template. So if you want to display some image in the main template, based on what overlay is loaded, you can create variable-based mapped image, and then no matter where you set the variable, the image in the main template will update accordingly, i.e. even if you change the template loaded into the overlay from within the overlay itself, and that kind of thing.
  • The ability to have things like check boxes that light up based on which one was last selected. You'd set up a set of 'radio-button' style check boxes just as with a field, but drive them from a variable. Each one just needs to set the value of the variable to its value, and it will light up and the others will go off. This will massively simplify many types of interface designs.
  • A way to get values out of popups using things like sliders. You can now create a slider in an interface that's variable based, let the user slide it to something, and the variable will be updated to reflect that, then when the popup is closed, you use the value it was set to.

I'm sure you can find other useful things to do with them as well.

On-Preload Action

On the template there is still the OnLoad, but there is also an OnPreload. OnPreload offers a very restricted set of commands that can be done. Mainly variable manipulation, hide/show of widgets, setting of colors, and importantly the new LinkToField and LinkToVar commands that field and variable based widgets supports.

These allow you to do what used to done in the Xlat tab of the Template. That tab is no longer there and any previous contents will have been automatically transferred over to the OnPreload. This is far more flexible and powerful since you have all the variable manipulation stuff available to you, and conditional logic, to build up the names of the fields and variables and assign them to the widgets.

OnLoad is still there to do stuff that isn't allowed in the OnPreload, such as write to fields, system commands and all that.

LinkToField and LinkToVar

Though these were created specifically for the OnPreload above, they can now be called at any time. So you can change the field or variable that a widget is associated with at any time. The field or variable has to be of an acceptable type for the widget, or it'll go into error state of course.

So, in some cases, where before you'd have had to reload an overlay (which would run the Xlats, and now the OnPreload), if you just have a small number of widgets to update, you could just directly change their associated fields instead. The benefit of the reload and OnPreload, is that the logic is done one time, whereas in the direct setting, each button would set a different set of fields. But still, in some cases it would be the more convenient way to go.

Action Editor Filtering

The action editor used to be a little lax about allowing questionable commands, like loading an overlay on the OnDrag of a slider or something like that. It's now much more strict about these things. It's unlikely that anything you were doing before has been disallowed, since mostly it only disallows stuff that would be pretty unworkable. But, it's theoretically possible.

It won't stop working, but the next time you edit the command it will not let you save it until you fix the no longer allowed commands.
 
Wow! Am I reading an episode of "Lost"? The Dharma Initiative had moved the xlats to OnPreload but hadn't anticipated an invasion of variable based widgets loading an overlay of static variants. I think I need to watch the first 15 episodes to understand what this one is all about. :)

That screenplay isn't exactly "For All Audiences" and is more for "Mature Audiences" of CQCers! :)
 
Wow! Am I reading an episode of "Lost"? The Dharma Initiative had moved the xlats to OnPreload but hadn't anticipated an invasion of variable based widgets loading an overlay of static variants. I think I need to watch the first 15 episodes to understand what this one is all about. :)

That screenplay isn't exactly "For All Audiences" and is more for "Mature Audiences" of CQCers! :)

Agreed, but it is a good summary of "what's new" which is what the request was for. That's the downside of Dean adding so much stuff to CQC so quickly - you can either tailor threads & webinars to newbies, or to advanced folks, but rarely to both. Obviously having that much additional power in just one subpoint step in a beta is a good thing, it just means that the users will have to figure out how to best incorporate that into our systems.

It also serves as a proof point that the $95/year license fee was a good move for both sides. Dean doesn't have to artificially inflate releases, (what you read was between beta 2.4.15 and beta 2.4.16. You should see betas 2.4.1->2.4.15), and the user community doesn't have to wonder whether any given upgrade is worth a few hundred $$. We can all focus on how to best uplevel our capabilities.
 
Back
Top