4.5 Official Beta Release Thread

[Dean Roddey]

Version 4.5 is now released, so this thread is closed and is for archival purposes only. A new release thread will be opened.

[Dean Roddey]

OK, 4.4.900 is posted. This is a big one, though almost all of it is in the IV end of things, so nothing that would be dangerous or destabilizing on the back end and whatnot.

Far and away the biggest thing going on here is that we are making the final, final, final transition towards a gesture based world, and the first step towards supporting native scrolling paradigms on all platforms. This one does it for Windows, but it won't happen for RIVA clients until we get a RIVA 2 out, which is a 5.0 thing.

The list of changes is below, but a summary for those who don't want to read through that list.

• Gesture support is always loaded now. The previously used CID_GESTUREHANDLER variable is no longer used. You will either get native MT gesture support or faux gesture support. With a mouse it uses the left button for both clicks and gestures, and of course the same applies to non-MT touch screens which are effectively mice. A click (as with a touch screen) is a quick press/release without moving. This means that interfaces can be built purely for gesture based control without having to worry about portability.
  
• Scrolling is now done via 'inertial drag' type gestures. I.e. the content follows your finger, so you can drag it around, but it's inertial so it keeps moving if your finger is still moving when you lift it. The old 'flicks' are no more. There's just dragging and lifting your finger before you stop moving it, which lets it keep moving based on how fast you were moving.
  
• There are a few exceptions, where things are purely page oriented. The CAB is still page based, so it's just flicks there. If an overlay is scrollable but is in 'page mode' then it works in a flick sort of way. In the media list browser, when going back to the left (to previous a list) that's page oriented, so it's flicky, not draggy. But otherwise, anything scrollable is dragged.
  
• There is no more OnPress/OnRelease, except for those widgets that you hold and drag (see next item below.) On touch screens, you have to do a quick press/release to get a button click type input, so press/release doesn't really mean anything anymore. Any press/release based commands in widgets other than those mentioned in the next item will have their commands moved to the OnClick or OnSelect or whatever it is for that type of widget when you upgrade.
  
• The 'press and drag to set' type widgets (slider, progress bar, volume knob) now work through a drag gesture, though non-inertial of course. So just touch and move. They won't react until you actually move. You can also just click them to move the value to that point. If something is potentially dangerous you may want to add an 'are you sure' popup for values above some specific level, since it's pretty easy to make something happen by touching the screen, though probably 90% of situations won't require such a thing.
  
• RIVA clients of course are still just 'redraw at the new position' type updates in response to flick type gestures, no sliding scrolls, until we get through the RIVA 2 work.
  
• The volume knob no longer uses a rotary drag to set the value. You either just go left/right or up/down to set it, since we don't have any rotary type gesture anymore, and it's easier this way anyway.
  
• The Inc/Dec button is a casualty of this paradigm change. It will still be there, so that it doesn't break the loading of templates that use them. But they won't do anything. They never were particularly good anyway, but we need to find better ways to do whatever they were being used for. In the meantime, if you depend on them, don't upgrade unless you are willing to work around this.
  
• For now at least, any scrolling done via buttons sending scroll commands to other widgets is generally of the 'just redraw at the new position' type movements, without any inertial slide. Generally speaking, gestures are the new way of doing things and there should not be much button driven scrolling moving forward. However, we'll probably put the sliding back anyway in the next drop when we have more time to work on it.
  
• Since we no longer have flicks, there is no longer any such thing as a 'flick at the edge' to do home/end type operations. Gestures are finger tracking, so you'll get an inertial drag no matter where you touch and move. So this probably means that, at least for home/end, you may still use buttons to send list scrolling commands.
  

I'm sure, with all the changes involved, that I probably missed some details. So just let me know if you notice anything that doesn't seem to be reacting right. Also, the amount of inertia can be tweaked if folks feel like it's too much, too little, etc... It should be pretty much like what you'd expect from the native Windows MT built in pan inertia, which is fairly sensitive and has a 'long tail', i.e. it slows down fairly slowly. I think that it works best like this as you get used to it, since you can do flat end of your finger, short swipes to move page type distances, but still move quite a distance if you want to do a faster, tip of your nails type of flick. So you can move through a fairly long list with just a few fast swipes.

I let the horizontal ones have more initial velocity and a longer tail, since moving horizontally generally means moving further to get through a similar number of items. But the difference isn't big or anything. It just reduces movement a bit vertically since vertical content tends to be more compact in the direction of travel.

But anyway, let me know how the inertial feels and we can tweak if needed, or even provide an environmental tweak parameter of some sort if that helps.

[Dean Roddey]

And here is the full list of changes for 4.4.900:

• The new persistence stuff in the Var driver isn't working for string list types since I failed to add the code in that driver callback.
  
  
• Update the Integra driver to support the TX-NR709 model.
  
  
• The h/v browsers aren't showing focus via color. Update them to use Extra1/Extra2 colors for focus. Otherwise it's the normal Fgn/Fgn2 colors.
  
  
• When you add a new button to a toolbar widget in the Intf. Designer, it should be selected as the active one automatically.
  
  
• The fact that overlays might overlap was never taken into consideration, so the hit testing that figures out what widget a click or gesture or whatnot is over doesn't stop looking when it sees that the point is within an overlay, but nothing within that overlay was hit. It keeps looking, which means that the hit can 'pass through' that overlay and hit something under it.
  
  
• Update the Base attribute tab so that it can query widgets for meaningful names for the supported colors, and display those instead of the generic names. This will make it all very much more self-documenting. This is very tedious to get done initially and I probably made a mistake or two, so just let me know if you find one that seems misleading.
  
  
• The previous item brought up the fact that our use of colors in the widgets is not very consistent. So go through and adjust them to be so. We we often using the same color for the border and for one of the text colors, and always using different colors for the shadow/fx color though they can't be used together and it made the previous change above impossible, so fix that as well. This should be backwards compatible because I'm updating the widget colors appropriately.
  
  
• Add support for a new Power device class (prefix PWR#)
  
  
• In the field write action command code, log more info when it fails, so that we can see after the fact what value was written and what the error was as seen by the client side and all that.
  
  
• Make sure that we disable loopback adaptor in the ORB, so that the servers will never bind to that interface. Otherwise it causes problems and sometimes get selected over a legitimate network card.
  
  
• Sometimes, despite the fact that the blanker window, upon being destroyed, does a monitor power on, it doesn't seem to work, maybe a Win8 thing. So, have the blanker force itself forward and then invoke the power on before it destroys itself.
  
  
• Update the IV to support inertial dragging, to replace the existing flick based scheme. We still need to support flicks, for RIVA clients and in some special cases such as the CAB and page mode overlays, but for native Windows IVs we can now do inertial dragging as the primary gesture scheme. This is a big change and involves implementing a lot of support functionality to support inertia both on MT and non-MT hardware and with mice, to integrate dragging and flicking all together in a new and better gesture enigne, and we want to add a lot more functionality to allow hit widgets to know ahead of time what gesture type are looking at and allowing them to indicate how (or if) they will react to them.
  
  
• Now that we have so much better control over gesture stuff, update the faux gestures so that we can use a single mouse button (and hence a single touch screen interaction on non-MT touch screens) for both clicks and gestures. Get rid of the CID_GESTHANDLER= environment variable and just always load gesture support no matter what. This means that interfaces can be fundamentally gesture based without any need to support buttons for sending scrolling commands.
  
  
• Add a driver for the Monoprice 5704 matrix switcher.
  
  
• If a device sends out a constant stream of data, the PDL driver engine won't work because it tries to process all async input before it sends anything. If the input stream never stops, there's always more to read, so it won't ever send anything. So limit the number of asyncs it will process before returning so that other business can be handled.
  
  
• Add support to the Integra driver for the NR1009 model.
  
  
• Remove all of the mouse related stuff from the IV engine now, because it makes no sense anymore. All that's left of mouse input (for gesture based windows like the IV) is the "press/release in place" that we see as a click. Since gestures handle all movement in the IV now, it's crazy to have all that existing mouse tracking code and complexity because we know any click has to just be a press/release without movement. So just have the gesture handlers send out a Click type notification, and have gesture based windows just work in terms of that and never see any mouse stuff. Go through the IV and remove all of that mouse oriented code. It'll be painful now but well worth it long term, because it's so much simple and removes a lot of code.
  
  
• Change all of the 'drag to set' widgets (slider, volume knob, progress bar) to use gestures instead of mouse movement, since we can't support mouse drags anymore. The OnPress, Release, Set/Click, stuff also moves now to the gesture stuff. You can also just do a click on them to set the value as well. When setting via a gesture, they won't change until you start moving.
  
  
• Change the volume knob to work in terms of left/right and up/down gestures, since we don't support anything else anymore, and frankly it's just a lot easier to adjust them that way because it requires far less finger control.
  
  
• Abstract the new gesture engine so that it can be used both within our own windows, for the IV, and within the RIVA server. And update the RIVA server to use it. Also, since the other RIVA client guys never updated to support the changes in 4.4, just go back to the old scheme since the gesture engine will just translate those events into our current gesture stuff fine. The widgets that support inertial panning just need to check to see if they are in remote viewer mode and request a flick instead. That'll go away in a RIVA 2, but for now that's the only difference required.
  
  
• In the new gesture based world, the old Inc/Dec button widget just doesn't make any sense anymore. There's no way to support it the way it currently works. For now it'll be there, so as to prevent templates that currently include them from failing to load, but thye won't do anything. We'll have to come up with something else to provide that sort of functionality
  
  
• It looks like the iOS/Android RIVA clients never got updated to support the new gesture changes in 4.4.0. With all of the changes above, we don't really need them to change anymore, so just go back to the old scheme. Since we can use our new, abstracted gesture engine, we can just process mouse movement reports and turn them into gestures just as we do with local. mouse-driven faux gestures.
  
  
• Update the static list browser widgets to allow the user to update the text of list items by index. You can currently set the hidden user data, but not change the text.
  
  
• Make the list parameter value of the static list browser widget's SetBrowserList command optional, so that it can be used to set an empty list, i.e. clear the list.
  
  
• We have to prevent the widget being dragged from redrawing. Unlike with our page based smooth scrolling, which we can just do in a loop and therefore disallow any redrawing while it happens, a drag can go on indefinitely, so we can't just prevent everything from updating while it's being dragged. There is still an issue if something underneath the scrolling widget updates, but that is a pathological scenario since it makes no sense to have actively updating stuff under a transparent scrollable widget. Other things also prevented, such as responding to triggered events or doing any OnTimeout, so that would prevent something like an incoming event changing a background or something like that while a drag is happening.
  
  
• Mark did some exploration about correct IR data reduction, to get consistent hashes from slightly inconsistent data that IR remotes send out from one press to another. Use this to update the GC IRE driver so that it actually works now. I don't think anyone was using it because the previous reduction algorithm I (naively) came up with sucked, but if you are, then all of your commands are now not going to work since the algorithm has changed. If so, let me know. Maybe we can provide you with the old version of the driver or something. Unfortunately there's no way to convert the existing IR triggers that you've already trained in.
  
  

[Dean Roddey]

Version 4.4.901 is posted. It basically follows up with some fixes of gesture related things that slipped through the first beta, and fixes a few other bugs.

• The Adv. Media Item Browser got a bug during the previous drop, if you scroll it via buttons sending commands, it gets confused about where it is in the list. It also wasn't doing the press/release visual feedback when clicked.
  
  
• The Covert Art Browser isn't doing the press/release visual feedback when clicked.
  
  
• Reduce the 'inertia tail' just a bit for horizontal pans, so it slows down just a little faster.
  
  
• The Zoom Player driver got a bug introduced during the 4.4.0 work, where its acceptable media types flag was set to music instead of movies and music, so it would reject any movies that you tried to queue up on it.
  
  
• The auto-generation system isn't getting the field association for the movie player screen's play/pause check box updated correctly because the original template used for the generation is referring to the music player replacement moniker, and the generator isn't looking for that when it does the replacements. The action commands are also referring to the music player so those would have not been updated either.
  
  
• The GC-100 blaster model creation dialog isn't allowing command data to be manually pasted in. The data is always rejected because the regular expression that does the basic validation of the data is incorrect.
  
  
• When sending an overlay a scroll command (as opposed to a drag), it's not clipping the scrolling area within the overlay's border (if it has one), so it can overwrite the border.
  
  
• There was a leak of a font in the action editor, which would cause an eventual failure after a lot of editing of actions that contain If, Else, and End lines (since those used that font to bold themselves.) The program would run out of graphical object ids and have to be restarted.
  
  

[Dean Roddey]

Long in the forging, powerful in legend, quenched in the tears of a thousand angels, beta drop 4.4.902 is now posted. As mentioned in the official release thread, this more than most any drop before is maybe an actual beta, though by most standards likely a quite good beta. So you might find some quirks, and in some very unlikely circumstance it might just not work for you, because the changes are broad.

Most likely at worst you'll just see some quirks, and we'll get those fixed quickly. But just be sure to backup before you upgrade. And FOLLOW STRICT upgrade procedures. Don't just upgrade the MS with everything else running. Stop everything, upgrade the MS, make sure it's good, then move forward with other machines.

Read the upgrade guide, linked to just below the download link in the release thread. It provides a high level guide to what has changed and how it might affect you. For the more technical change list, here it is, fairly lengthy, so I have to break it into three parts. Some of these of course have been back-ported to 4.4.x follow-up releases as well.

• Update the IV engine to support rounded corner widget clipping. Currently they are all either square or square but with the background transparent so you don't really see the squareness. This will allow for rounded corner background fills and borders, which can be quite useful for creating particular looks without having to resort to using images.
  
• Add support for a line drawing widget, which also supports for now at least a couple styles of line end ornamenations. Currently the only way to do lines is via an image, or using the color fill widget which would create a very thick line at its thinnest.
  
• There's no reason the slider widget can't have a border, so enable that.
  
• For some reason text f/x never got enabled for the media list browser, so turn that on. The code was always there to support it.
  
• I failed to get the 'already busy' check over from the old mouse input stuff to the new gesture stuff, so you can start a new action before a previous one (that's taking a while to complete) has completed, and this can cause an exception. It also wasn't doing the 'no input' check, which is needed for the signage mode, where secondary IV's don't accept any input.
  
• The file open dialog doesn't protect itself against the fact that the previously used path (which is typically remembered by the applications and passed back in) may not exist anymore.
  
• Add a 'has capability' flag for scrollability, so that we can allow the user to enable/disable the 'no inertial scroll' flag generically in the base attributes tab for any scrollable widgets, but grey it out when it's meaningless.
  
• The media list browser widget has an issue with serving up it's runtime value object. It doesn't make sure that the category list isn't empty. So, if it is, or at design time when it's always empty, it'll cause an exception when it tries to get the 0th category in the list, because there's no 0th entry.
  
• The media list browser widget's assignment operator wasn't copying the slot height value, so any time it was assigned the slot height would revert to the default 12 pixels after invoking the configuration dialog on it.
  
• Add support for calculating the distance (in miles or kilometers) between two lat/long positions. Make it available at the action level (System::CalcGeoDistance(first, second, units, targetvar) and via CML as CQCUtils.CalcGeoDistance(lat1, long1, lat2, long2, miles). For the action each lat/long pair are passed as a single parameter, in the format "lat long", i.e. latitude, space, longitude. Units is Miles or Kilometers. The result goes into the target variable. For the CML method, the first four are floating point values, and the last is True to get it in miles and false to get it in kilometers. As always west and south values are negative, east and north values are positive.
  
• Update the above action command to allow the use of the special values [CLIENT] and [SERVER] in place of real 'lat long' values if you want to reference either the location reported by the client itself, or the location reported by the server (CQC backend, i.e. your home or office or whereever it is running.) If you use [CLIENT] and the client hasn't set location info, you'll get an error.
  
• Update the RIVA protocol to allow clients to pass along current lat/long info, which it can do during login and any time it thinks that the values have changed. These values will be stored by the server in the session context for that client and used any time you use the special [CLIENT] value as one of the location parameters to the CalcGeoDistance() action command.
  
• The gesture click handler isn't displaying an error dialog if an error occurs while processing a click event.
  
• When the Lutron RA2 driver is asked to reload the config file, it will load the new stuff, then call its own Connect() method which already does all of the work required to get initial values for all fields. But, if that failed, it was just returning ValueRejected. That would leave the driver in limbo land, without correct configuration but still connected. It should return Lost Connection in that case, so that it starts going back through the reconnection process until it succeeds.
  
• The recent change to prevent loopback adaptors from being used by the ORB was based on an incorrect understanding of the underlying address lookup API, and also a failure to realize that there was a client side component to the issue as well. Even if the servers include loopback addresses in their bindings, the clients should try to prevent loopback adaptors from being selected in any name to address lookups.
  
• Add the ability to anchor the edges of widgets to their respective sides of the parent container, or to maintain a center position in one or both axes. This will be used to support dynamic repositioning and sizing of template contents, very much for the immediate term for use by upcoming auto-generation improvements but this will likely be widely used. It will operate in two cases. On the base template, if it is marked for dynamic resizing. Unmarked base templates work like they always have and just center in the viewer. Or within an overlay when the loaded template is so marked, so this means that, if an overlay is resized because the overall template is resized, it can in turn resize it's contents, and so forth. But it doesn't have to. Each template loaded into the overlay can choose whether to be resized or not.
  In either case, the content will only shrink down to their original size in either axis, then they stop getting smaller and just clip. Dynamically resized overlay content isn't scrollable since it's sizing to fit the container. If you want to scroll the contents, make it non-resizing, which leaves it the original size. If that's bigger than the overlay, it scrolls.
  
• The change to allow training of generic trigger drivers (not the HTTP one but the string based ones) with parameter values on the incoming training values was either not done correctly or changed later incorrectly, since it's actually doing the reverse of what it should be. It's cutting out everything before the separator, not chopping off the bit from the separator forward.
  
• Make a fundamental change in how media metadata and art is dealt with. Instead of having clients (mostly the IV/RIVA) go to repository drivers to get data, create a new service (the client service) which, unlike the regular CQC app shell service, can run on client only systems without issues. It will watch all loaded repos and download their metadata and cover artlocally and cache it and make it available to client apps very efficiently. Update the all the repo oriented IV widgets to get metadata from this local cache, which will be vastly more efficient, though a bodacious amount of work to do. This service will be loaded on all machines, so it will also serve the RIVA server, which will be able to serve up metadata from local info instead of having to make a double hop to the repo driver.
  
• Update the installer to handle the new client service. It is always installed, on clients or servers. It is always set up for automatic start since it will not interfere with the system sleeping and such.
  
• The bitmap file format class has a bug in the code that streams out the data. It gets out various values up front to use, but it stores the height in the width value and vice versa. So only images that are square come out right. For all others the image is skewed because the calculations done when the image is loaded are going to come up with the wrong values for row length. Wasted a STUPID amount of time on this one.
  
• Add a driver for the Marantz 8801 A/V receiver. Do V1 and V2 compatible versions, since it makes no sense to do a non-V2 compliant one at this point.
  
• Add a driver for the Visual Apex VAPEX9106TN screen projector controller.
  
• Many CML drivers use enums to map back and forth between values in device messages and internal values or values displayed to the user. Currently they use the FromText() or FromName() methods to map incoming text to an enum value. These methods throw an exception if the value doesn't map. But this is often not a convenient way to do it since it's often expected that many values seen are not mapped, so it causes a lot of exceptions and that makes it hard to use the 'break at throw' option since it's constantly stopping on these enum mapping exeptions.
  
  So provide a new method: 'MapFromText([In] String Value, [In] Boolean IsName, [In] EnumType Default) Returns Boolean;' This will map the text value either as name or text depending on IsName. If it maps, then the mapped value is used, else the default value is used. EnumType here is whatever the enumerated type happens to be. It returns a boolean that indicates whether or not it mapped successfully or not, in case the caller cares.
  

[Dean Roddey]

Changes for 4.4.902 continued...

• Update the Z-Wave Leviton driver so that it will accept both basic reports and binary sensor reports for binary sensor modules. Otherwise the driver won't see the values they send out. I'd previously thought they always used the basic report to report value changes, but apparently not.
  
  
• Do a complete rewrite of the CAB. It needs to move to a non-paged scheme, based on the new locally downloaded media database cache. Also move it, like the advanced media item browser, to have it's per-slot layout controlled by a template, so that it can support fancy display of anything you want. This means that various commands, such as the text/image display options and the setting of the display pattern are meaningless now. They will be there to avoid errors but will not be found when you edit the CAB the next time. A default pattern template will be set up during upgrade which does the current image on top, text below layout, to provide a basic upgrade path. This will be another huge effort, and it'll be all tied up with the new client service stuff.
  
  
• Update the gesture engine so that a click while inertial scrolling is still going on, will just cancel the inertia without doing a click action. This allows the user to cancel inertia safely if they see something they are interested in going by.
  
  
• Go back and put the smooth scrolling back in for all of the command button (or possibly remotely) driven scrolling commands, to keep the 'slickness quotient' up.
  
  
• Add a new standard navigation command to the IV (which are used in keyboard or remote control) for 'going back', and update the CAB and media list browsers to use it to move back to the previous list. Otherwise they wouldn't be fully navigable via remote control or keyboard.
  
  
• While are are banging around in the media architecture, add support for poster art at the collection level. These are not going to be downloaded and cached. They are likely to be large but seldom needed, only when a new movie starts playing, so just download them from the repo as required. Update the media repo image widget to support poster art as an option. Later, if needed, we can provide for getting it from renderer drivers as well, but for now it's repo only. This still will need to be supported in the repos, which isn't implemented yet, but the potential is there once we get time to update any repos that might provide such an image.
  
  
• Update the designer so that its selection handles are drawn in different colors where there is an edge anchor, to help graphically indicate where they are.
  
  
• Create a new 'linear multi-patch image' widget. This will allow for end cap images, a fill image in between, and an optional center image. It can be horizontal or vertical. This will be a key feature for supporting good resizeable templates.
  
  
• The Video Processor and Video Scaler device categories were getting transposed when loading from a manifest and a text to binary translation was done. So one would show up as the other. Ultimately the difference between these is probably not worth fighting over and they should have been one category. But all this device category stuff is going to go away at some point, to be replaced by the new V2 compliant device class stuff, so it's not worth trying to consolidate them at this point.
  
  
• The vertical popup list window control, which is often used to pop up a menu beside a button and that sort of thing, was doing the work to insure the list remained as visible as possible on the monitor it is running on, but then failing to update the popup origin to make it adjust the position if needed. So these could hang off of the screen since they would be relative to the button, even if the button was near the bottom or right edge of the screen. It is also using the virtual desktop size, which can make it hang off the bottom if used on a smaller monitor in a multi-monitor system. It should get the size of the monitor is is actually on.
  
  
• The iTach Flex devices change the protocol a bit when reporting blaster zones. Apparently if it's a single zone, fixed function IR blaster device it returns IR_BLASTER (instead of just IR and leaving it to the driver to query the type of the IR zone.) So update the driver to deal with this special case.
  
  
• The media repo manager should make sure that it doesn't have any dialog boxes up before it responds to the notification of new media having shown up in a drive. Otherwise it can get caught up and not respond.
  
  
• The 'set user rating' backdoor command to repo drivers (currently only CQSL repo), should return a rejection code if the change would not be wise to make at the current time. Such as, in the CQSl repo, if there is a repo manager currently attached. Any changes made while that is so would get lost when the repo manager commits his changes. This way the user can be told the change can't be made right now, by looking at the return of the backdoor command used to to send the rating change. It should return 0 if it takes the change, 1 if it could take the change but not right now, or 2 if it cannot accept such changes at all.
  
  
• Update our CQSL repo so that the repo manager no longer makes changes remotely as they are done in the repo. Instead, let it just download the metadata database (since that's now there to support the client service's local caching) and do changes locally, and allow the user to commit them all at once. This will make things simpler in many ways, removing both a fair bunch of code and a whole bunch of complexity, avoid atomicity issues, etc... but it's going to be very intensive because it means almost completely changing how the whole thing works, and a lot of changes to the media database system as well.
  
  
• The above also means that the CQSL repo driver should stop storing info as separate metadata files and just consolidate it down into a single flattened media database object, in the same form that the new client service downloads. This will then work well with the above changes to how the repo manager works. It will also avoid atomicity issues on the loading and uploading side, and making loading way faster. It will have to do a conversion the first time it runs. Images of course are still separate files, and any ripped and uploaded media files.
  

[Dean Roddey]

Changes for 4.4.902 continued again...

• Add a couple more sources for cover art to the CQSL repo manager client. Some of the ones we used to use have stopped working for various reasons.
  
• Drop support for the old iTunes drivers, the pre-Tray Monitor ones I mean. There's no reason at this point not to use the vastly superior TM based iTunes repo and player control, and it would be a lot of wasted effort to upgrade them to support the new repo scheme.
  
• Update all of the remaining repo drivers and Tray Monitor to work in the new scheme, to support the client service's media data caching needs and to be V2 compliant. We have to do V1 and V2 versions of all of them, so as not to break existing users. The V1 ones also support the client service, since it's not optional to do so.
  
• Add a new CID_GESTSCALER= environment variable to allow folks to adjust the sensitivity of gesture inertia on each machine if needed. It can be from 0.5 to 1.5. The default is 1.0, which is just 'unity gain' and won't affect the actual sensed velocity. If you set it too high, the inertia will clearly start off faster than your hand is moving, so it'll appear to speed up when you release it. But if you aren't getting enough inertia, i.e. it seems to slow down noticeably after you release, then you can crank it up a bit. If you are getting too much, lower it.
  
• The generic IP listening trigger driver won't reset the 'in training mode' flag if the client disconnects while it's training. That will leave it stuck in training mode.
  
• When a bitmap is of the V3 or beyond format, which means it has a file header before the bitmap header, then the pixel data offset in that header has to be used to move to the correct spot where the pixel data starts. A gazzillion minus one times out of a gazzillon it won't matter, but sometimes it does. Bryan sent me some that weren't working and that was why. Updating to use the header offset works for those and appears to work for any other existing bitmaps I tested on as well.
  
• The Roku driver has an issue with the channel selection HTTP POST operation, in that it's passing in as post values the output header lines from a previous command. This can freak out the Roku for obvious reasons and cause it to fail. Stupidly, this was fixed for the keystroke sending command, but I failed to make the same check of the channel selection command at the time and fix it there.
  
• Change the way the IV allocates its big double buffering bitmap. It currently allocates it the size of the screen, but that can get wierd in RDP and multi-monitor scenarios. Just change it to resize to fit the view size as reported by the containing application. That way, it doesn't have to worry about the actual screen size, and it never has to actually be bigger than the view is (anything bigger than that would be clipped away anyway.) And it doesn't use unnecessary memory as well, which it very much can in multi-monitor situations.
  
• When the IV starts a resize (user dragging the edge) the maximum size it's setting is the desktop size, when it really should be using the virtual desktop size. As is is now, it limits the size to the primary monitor size. If you are on a mixed size system, you can't size it bigger than the primary monitor, even if the monitor it's on is larger.
  
• Update the CAB to allow the user to set specific images to use for missing artwork or for playlists if the repo doesn't provide playlist art. This replaces the old fixed images in the repository that used to be used, and provides a lot more flexibility.
  
• Update the IV engine to use the new persistent media image ids when it creates the string that it embeds in the images that it sends to the RIVA clients. This was already being done before, since the RIVA clients use them to come back to the server to get the images. But those were not persistent ids, and would only be valid for one run of a repo (other than the CQSL repo, anyway.) Now that key is based on the persistent id instead, so it should work across reloads of a repository. The RIVA server will now use this persistent id in the provided strings to find images and return them, so it can get them locally from the media data the client service has downloaded.
  
• Our command to power monitors off/on isn't always working quite right, particularly on Win8. Make a slight change to that to see if works better.
  
• Get the latest Nuvo Grand Concerto driver into the build (2.76), plus a fix for const parameter problems that the CML compiler now catches.
  
• Go through all of the CML drivers and remove any that are doing local bindings for stream sockets, since that's not something we want to do anymore in a dual IPV4/6 world, and in the presence of possibly multi-homed devices. For UDP sockets, for now, force them to bind locally to IPV4 until such time as it's proven they need to do otherwise. This should prevent issues on IPV6 enabled and multi-homed systems that have been happening with these drivers.
  
• Somewhere along the line, the abilty for a background message thread to get device change notifications got lost. Maybe it's a Windows 7 thing or something. But our background notifications of new drives coming or going wasn't happening, which meant that when you went to the file open dialog, it woudln't already have the info ready. That could cause delays as it scanned the drives to get the info, and it wouldn't see changes in the list either unless the program was stopped and started. You seemingly have to register for such notifications in any other than the top-level real visible windows these days.
  
• Add an auto-refresh mode to the web image widget. You can set it to a particular rate in milliseconds, and it will continually update at that rate.
  
• Add support for bmp files to the CQC Web Server.
  
• There is a potential for memory corruption in the RIVA server given the right circumstances. This could of course theoretically at least be responsible any glitches or strangeness that have been seen since the dawn of RIVA time.
  
• The file swap command, which is used to create new files separately and only after they are successfully fully created and verified to replace the original in an atomic way, will fail if the target file doesn't exist. If this happens, the method should watch for that file not found error and revert to a simple rename of the temp to the new.
  
• In working on the client service wrt to system power state changes, I realized that one of the problems we may have seen over the years is that, during the system startup, even when we clearly indicate we don't want loopback addresses, we'll still sometimes get them. Actually, that's ALL we get when this happens, no regular adaptor addresses. Presumably they haven't initialized yet. This causes all kinds of problems. It happens regularly when coming out of sleep mode, which is how I saw it. So, add code to the server side ORB initialization that will, if not told to support loopbacks, to wait a while, asking for non-loopback addresses. As long as we are seeing them, we just sleep a while and try again. Once we see non-LB addresses, then we continue. If we don't get one after a reasonable time, we just continue forward with what we have.
  
• The VRCOP, if the msg is more than a fairly small number of characters, will sometimes put out a \ character, and then put the rest on the next line, but with a redundant prefix. So we need to be able to handle this scenario. Entry control (lock) reports are likely to be of this sort.
  
• To handle Z-Wave scene actuator devices, which report their general class as multi-level switch, we need to have our ML switch class watch for actuator reports for scene id 0, in order to get asynchronously reported current level values from those units.
  
• Update our base window class so that, when a window is clicked on, if it's not part of the active application, then allow it to come forward, but eat the click. If it's part of the active application, process the click. This allows you to bring forward programs even if the only visible part of it is something that would otherwise react if clicked. This lets us get this (always desired) functionality globally with a simple change.
  
• If you create a field based widget, and never select a field, it can cause an ongoing repeated log message because the moniker and field names never get set, but this isn't checked for so it tries to register these empty names with the polling engine. That causes it to try to create a thread for this non-existent driver's host name, which is empty, and that causes a duplicate thread id error.
  
• Update the RIVA protocol to allow RIVA clients to tell the server about dynamic screen resolution changes, so that Windows type RIVA clients, which don't have to be full screen, can take advantage of dynamic resizing. Sine no one has actually implemented the V5 protocol changes yet (that was recently done to support lat/long info for geofencing), and since it's a client to server message, just add it to the V5 version. DO NOT send this continuously as the user drags to change size. Only send it at the end when the resize is complete, else you will blow up real good.
  
• Lower the active polling time on the Marantz 8801. It must have a timeout and is dropping the connection because our current 20 second poll time is too long.
  

[Dean Roddey]

Version 4.4.903 is posted. It just addresses the stuff reported yesterday with the initial big drop of all the new stuff, and adds a couple small things.

• Allow the socket pinger the option to accept a source side address to bind to if desired, instead of letting it chose a default. This is required apparently for multi-homed systems. There is now a StartPing2(). It adds two more parameters, a source address in the form an IPEndPoint object, and a boolean that indicates whether to use that source address not. If the last parameter is False, then the source address ignored and a default local bind is done, as the original StartPing() does. But this way you can always use StartPing2() and just pass in a flag as to whether the source is valid or not.
  
  
• Make the logging of failure to load cover art a verbose mode thing. We don't want to kick out lots of errors every time a repo loads that has potentially some dodgey embedded art. Also make sure to get the art path in that logged msg. If small art was being loaded, but the repo creates small art from the large art, be sure to log the large art path.
  
  
• Add a 'ScaleNumRage' expression to the PDL driver. Since we have to scale things like volume in the new V2 world, this is going to be a common requirement and doing it manually with individual math expressions is pretty annoying. Given it's coming ubuiqity, make it easy. It is ScaleNumRange(val, minval, maxval, mintar, maxtar). So the percentage that the current value represents in the min to max value range is used to create a new value which is the same percentage of the min to max target range. By flipping the two ranges you can map to and from device values and driver values.
  
  
• Add a driver for the Monoprice ZM6. Actually it doesn't even have a model number as best I can tell. It's just called their multi-zone controller or some such thing. I have christened it the ZM6 for the purposes of this driver. This one only supports a single unit, it can't handle daisy chained units. So it only does 6x6 switching. This one is a V2 compliant driver, and requires new functionality added in this drop, so it can't be used on versions before 4.4.903.
  
  
• Increase the size of the buffer that the media engine uses to decompress media database it gets from the client server's cache. It's too small and can max out for larger repos.
  
  
• The recent big changes created a situation where the widgets in popups were being initialized twice. This would cause an error in the web image widget because it would try to start up its background download thread but it was already started by the first initialization pass.
  
  
• The web image widget is redrawing every time, even if there's not a new image. This is quite wasteful, particularly if the refresh time isn't really fast.
  
  
• The web browser widget can sometimes cause an exception when you move to a new template or load a new template into an overlay and this causes the browser widget to be destroyed. A fix was put into place which seems to take care of this, so let us know if you see any issues of this sort moving forward.
  

[Dean Roddey]

Version 4.4.904 is posted. This one is just to get a few fixes out plus to get a first cut at a Philips Hue lighting driver out there, and the associated color palette widget.

To help on the palette front, to see how it works, I attached a template pack with the little test template I set up for the color palette. It will be \User\TestClrPal I think. Basically move your finger around on the palette and it sends out its color info to the preview area fill widget, in RGB format which is what is required in that case, and it outputs it RGB and HSV floating point value to a display static text widget for debugging. The three Get buttons just ask the palette for its color in one of the formats available, and write that to the display text widget, again for debugging.

The attached template won't work anymore since things have changed. See the auto-generation system for a good example.

The To Hue button gets the color in the correct format to send to the Hue and writes to one of its xxx_SetColor fields. That's the one you'll have to change, to target whatever is appropriate for your system.

The driver queries the defined lights and creates two fields for each one:

xxxx_Switch - Just turns it off or on, it's Boolean and read/write
xxxx_SetColor - Write only . Takes an HSV color in integral format (which is one of the formats you can ask the palette for.)

It just round robin polls the lights, since the Hue doesn't send notifications. So the more lights you have, the longer it will be before you see changes made on the switches show up in CQC. Sometimes the controller is quite fast and sometimes not so much so. That might depend on whether it's doing something else at the time or something, I'm not sure. We'll see how it goes. I didn't see it time out, doing it remotely, with a 2 second response wait time. But of course even a second is a long time if you have 40 lights, since it would likely take on average 30 seconds or so to see a change made at the switch.

This driver requires 4.4.904 or beyond, because it required me to add some new functionality to support it.

• The Hue driver requires an HTTP PUT, which never got implemented back during the big rework of the HTTP support a year ago or so. So put that back in. It's the same as the SendGET, i.e. same parameters, but it's SendPUT(...).
  
• The HTTP class' SendGET method has an error if you try to send body text, in that it doesn't set the outgoing content length. Normally you don't send any body text in a GET, but it's supported in case something requires it.
  
• Implement a driver for the Hue lighting system. This requires 4.4.904 or beyond because new functionality had to be added.
  
• Implement a color palette widget, which will primarily be for use with the Hue type lights, to allow their color to be set interactively by selecting a color in the same HSV type color scheme that they use. The palette will provide the hue (horizontal axis) and saturation (vertical axis), and it will accept commands to set the Value component, so you can use a static slider or progress bar to set that. It will send out events with the current color as you drag around on it or adjust the value component via command, so you can update a color fill widget to show the color. You can query the color in a couple formats, and send the resulting color to a driver such as the Hue or any other driver that accepts color info in RGB or HSV format.
  
• Apparently JSON can start with an array as the top level node, whereas our parser assumes it's an object. The Hue driver, yet again, is doing something that we don't support so update the JSON parser to allow for this.
  
• The method that activates a window can legitimately fail in some cases, so don't check the return value from that and throw an error. If it activates it does, else it doesn't. I think this is what is causing the log monitor to have problems for a user on Windows 8, but we'll see.
  
• The installer's backup shouldn't include the media cache directory. Just let them re-download if you ever restore a backup.
  

[Dean Roddey]

Version 4.4.905 is released. Again, mostly just taking care of issues reported, but also some changes in the Hue driver and the associated color palette widget.

I realized I'd done something dumb. I added a SetColor command on the Area Fill widget to allow it to be used as a preview for colors selected in the color palette widget. But all the widgets already have a command to set any of the associated standard colors, so there was no need for this command. I removed it so if you used it after 904 above, it won't work now and you'll need to replace it with the standard SetWidgetClr command.

The other thing is that, now the HSV colors are in the mix, it would be nice if you could set those colors via either RGB or HSV. So I added a third parameter to SetWidgetClr, which is an enumerated parameter with the values RGB, HSV Integer, and HSV Float, i.e. the same formats that you can query the color from the color palette in. Any existing commands were upgraded to default that new parameter to RGB of course, since any existing uses would have been setting RGB colors.

So, you can use whatever color format you want to set them now. The color palette provides RGB of course so we could have stuck with that. But, I also changed the xxx_SetColor fields of the Hue driver to be just xxx_Color and made it read/write. So you can get the current color as well. It will be in the HSV Integer format, and that's also what you write to it to set it.

This means that, if you bring up an overlay or popup to control one of these lights, you can get the current value, write it to the color palette and preview area fill widgets so that they start off with the right values. You could also use the xxx_Dimmer field to set the Value slider as well, so that everything represents the current settings of the light.

In order to do that, since it returns values in HSV Integer format, we had to be able to set that format on the widgets to get the area fill to update to show the current light color.

This breaks the previous color palette demonstration template I posted in the previous post, so I updated it to work with this new version. If you already downloaded it, go get it again. And upgrade to this 905 version before you start working with it and/or the Hue driver, to avoid doing stuff you'll just have to undo.

Oh, and I also added xxxx_Dimmer fields for each light, which just affects the Value part of the HSV color. The Hue isn't a dimmer per se, but effectively the V part of HSV is a brightness level, and has the same effect as a dimmer. So now you can both turn it off and on and set the dim level without changing the hue/sat settings. And those fields will also let them work as standard lights in the auto-generation system.

• A number of the scrollable widgets lost support for the 'no inertia' setting during the recent big changes, some completely and some in just some situations.
  
  
• The Tray Monitor repo driver doesn't pass along the reload database command to the tray app, it just rejects it as an unknown field write command.
  
  
• The JRiver repo driver shouldn't fail the load if it has trouble with loading a cover art image. It was catching errors from the actual load of the image file, but the code that built up the path to load wasn't within the catch block, and if the file name is some crazy long file, it could overflow the maximum path length and that would cause an error that wasn't caught.
  
  
• The Hue doesn't support 'dimming' per se, but the brightness level (the Value of HSV colors) is effectively a dim level. So add a third field for each light, xxx_Dimmer, which just affects the brightness, read/write, card4 with the usual 0 to 100 percentage range. This will also give the stuff required to fully fit into the auto-generation scheme.
  
  
• I added a SetColor command to the area fill widget, which was dumb because all widgets already support setting any of the various colors. So remove that and just use the standard SetWidgetClr commands. However, add a new parameter to it, to allow it to accept HSV Integer, HSV Float or RGB formatted colors, now that we are bringing HSV colors into the picture. Update the palette so that it's RTVs are now RGB, HSV Integer, and HSV Float as well, so that you can get the currently select color in any of the three supported formats as well.
  
  
• Make one more change to the Hue driver. Change the xxx_SetColor fields to just xxx_Color and make them readable so that you can see the current color of a light. It'll be in HSV Integer format, so you could grab that and use it to set up the initial preview color when changing the color of a light.