+- Charmed Quark Systems, Ltd. - Support Forums and Community (https://www.charmedquark.com/vb_forums)
+-- Forum: General Discussion (https://www.charmedquark.com/vb_forums/forumdisplay.php?fid=3)
+--- Forum: Beta Discussions (https://www.charmedquark.com/vb_forums/forumdisplay.php?fid=12)
+--- Thread: Official 5.3 Beta Discussion Thread (/showthread.php?tid=10397)
RE: Official 5.3 Beta Discussion Thread - Dean Roddey - 01-29-2018
A toolbar widget makes for a good menu. What exactly are you trying to achieve?
RE: Official 5.3 Beta Discussion Thread - lleo - 01-29-2018
I mean something like this
https://www.w3schools.com/howto/howto_js_off-canvas.asp
click the buttons...
RE: Official 5.3 Beta Discussion Thread - Dean Roddey - 01-29-2018
You can't move the existing content. But the easiest way is to just use a popup to achieve that kind of thing. You can actually do it as a popout so that, on any Windows IVs it'll slide out. On RIVA it'll just pop up. Make a selection or hit a close button to close it.
RE: Official 5.3 Beta Discussion Thread - Dean Roddey - 02-01-2018
I've been pounding away on the Z-Wave driver yet more. Now that the other bits are sort of worked out, I'm concentrating on how to structure all of the handling of the various ZW command classes and such, in order to have as much flexibility as possible with as little redundancy and busy work as possible. I think have a fairly clever scheme, and I've been banging the code into that form. Hopefully I should get that reasonably working tomorrow. Once I prove that out, I think all of the major cypherin' on architecture will be done and it'll be a matter of going on to deal with the details, and the client side interface.
RE: Official 5.3 Beta Discussion Thread - Dean Roddey - 02-02-2018
I almost got all of those changes done today. Good thing I limited the number of unit handlers I'd done, since this involves adding a whole new layer of abstraction to it all. But, if it works, and it better, then a lot of the unit specific and generic handlers may be just creating these small, fractional bits and setting them in a list on the base unit class, and mostly then it's just forwarding things to them. The option is still there though of course to do something completely custom where that is necessary. But this allows for a lot of stuff to be very custom in terms of knowing what bits and pieces a given unit supports, but fairly generic in handling that functionality once the right handlers have been gen'd up.
RE: Official 5.3 Beta Discussion Thread - Dean Roddey - 02-03-2018
And I finally got the code changes made. That was a good bit more than I'd expected. But, so far at least, I'm feeling all pleased with myself because it's looking to be a really good compromise between flexibility and re-usability. Of course tomorrow when I start trying to make it work and find out it's completely wrong I may not feel so great about it. But I think it's going to be quite good, and much cleaner.
RE: Official 5.3 Beta Discussion Thread - Dean Roddey - 02-04-2018
So far, so good. I need to deal with some multi-end point stuff that I never dealt with before, mostly associations with multi-end point devices, and support that in the auto-config. I'm starting testing with just a dual outlet module, and I ran up on that when I got the code in place to handle notification msgs. But, overall it looks good so far.
RE: Official 5.3 Beta Discussion Thread - Dean Roddey - 02-05-2018
Well I came up with another very good idea today which required another change around of how information is passed down through the hierarchy of classes that implement the support for a unit. I spent the day working on that and almost have it done. The big thing that drove it is to try to make dealing with non-listening devices almost transparent. Some code during replication and scanning of the network need to be aware of it. But once up and going the unit oriented code won't have to much worry about it. That is going to make things much nicer, at the cost (as usual) of some more complexity in the driver itself. But a good trade off.
And I also get the stuff in place to hold the auto-config information from the device info XML files, which I'd not done yet, and the sending out of the necessary messages. And getting support for multi-end point units into the auto-config.
I also have the issues of multi-end point units pretty transparent now as well. The unit support classes just build their msgs as normal. As part of the above work, which requires funneling all msg output from the unit classes through a specific place so that they can just be queued up for non-listeners instead of sent immediately, that also allows for the msgs to be automatically adjusted to be end point oriented msgs based on unit configuration. So that just gets rid of a lot of fussiness wrt to those multi-end point type units.
It's gotten pretty complex but basically the hierarchy is:
1. Unit info object, which contains all of the discovered and user provided info about the unit. It also will, at run time, create and manage the actual handler for for the unit. The driver just keeps a list of these, representing the known units. Each of them will be in some state at any given time. If enough info is available, it is able to be used. Else that unit info object tries to gather information about himself. If enough is gotten, and we get manufacturer ids, and we have device info for that type of unit, it's set up and can be used.
2. The unit object which handles the actual processing of the msgs and such at run time. The ones that have device info can create one. This guy can just handle all of the msgs himself if it's some odd beast, but mostly he just creates 'command class implementation' objects, each of which handles some specific aspect of one of the ZW command classes the unit supports.
3. So that CC impl objects just get created and added to a list. The unit object mostly just redistributes incoming msgs and field writes and some other housekeeping calls to any of them that were created, and let's them handle their own business. Each one is told if he is on an end point or just a regular unit, so that allows for automatic adjustment of msgs based on the end point of the CC impl object.
There's complexity with getting them all the information they need, and it means that there's a good number of methods that are defined at each level, so if a change is made it ends up having to be changed in a lot of places. But, this division of labor really is working out well wrt to allowing for both flexibility and reusability.
RE: Official 5.3 Beta Discussion Thread - Dean Roddey - 02-06-2018
I got a lot done today. I got fooled by something and wasted some time, but that's par for the course. I got the stuff above worked out, and it's pretty clean (at least by Z-Wave standards anyway.) It may actually now move forward to completion in this basic configuration, since I can't see anything fundamental at this point that it's not going to be capable of dealing with pretty reasonably.
RE: Official 5.3 Beta Discussion Thread - Dean Roddey - 02-08-2018
And another day of steady progress. Though I just wasted an hour. I had made some changes to try to deal with one of the more stupider things about the Z-Wave replication process, and suddenly I started getting failures on my one test unit that I've been using while doing all these changes. I couldn't figure it out and couldn't figure it out. Finally I looked around and realized I'd unplugged it earlier in order to look at the product id on the back.
Sigh... Partly it was due to some slightly backwards trace log output that didn't make it obvious what was going on.