Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
5.1.0 followup releases
#21
(05-25-2017, 01:25 PM)Dean Roddey Wrote: Have you done the registry compatibility thing? Be sure it's for CQCWBHelper.exe, not CQCIntfView.exe if you need to add it.

It's not the registry thing as IE shows the same damaged page and this was working until several days ago. But, yes, I have the registry entry.
Mark Stega
Reply
#22
Oh, yeh, duh!
Dean Roddey
Software Geek Extraordinaire
Reply
#23
(05-21-2017, 06:46 PM)Dean Roddey Wrote: Scheduled Events Improvement

The other new thing is that for 'every x hours/days' type scheduled events, you can control what minute within the hour and what hour within the day that it runs.
I like that I can now see the time the scheduled events are set to run.  Is it possible to do this also for the sunrise/sunset options?  For me, it's really useful to check what time the event is going to run and it changes by the day and I feel a bit lost not being able to see the exact time, like I could before.
Thanks
Reply
#24
Just a comment on Mark Stega's post regarding the screen getting cut off.  I have seen this as well, on two different touch screens - one is a Dell Venue Pro 10 running Win10 (Not updated to Creator's update), and another is an HP- T510 running Win7 embedded.  It is the exact same for both, and I can't really give you a definitive on why it happens, but it happens after the screen saver has been turned on by Windows, and possibly after the monitor has been turned off by Windows.  Neither of these units are set up to go to sleep.

You may (or may not) recall I had reported that the screen was shifting a few pixels up and left and posted some screen shots before you modified the program to account for the Creators Update.  It seems that this is the same thing, but instead it shifts half of the full screen over rather than a few pixels.

One question you asked Mark was: can you close it, and when restored, did it come up full screen, and the answer is yes.   I have a hidden button on my interface to close it down, and it is on the part of the screen showing, so I have closed it down, then restarted, and it is back to full screen.

Will let you know if I see any other tendencies that may help you with this.
Reply
#25
I've posted 5.1.2. This one is mostly just a set of small fixes.

But it also includes one substantial but behind the scenes change. If you've not seen the discussion elsewhere, we are taking a whack at porting the RIVA system to the browser (and CQC Web Server for the back end.) So I've reworked the WebSockets support in the Web Server to be prepared for the vastly higher throughput requirements of the RIVA protocol. I've tested out some user written style CML web socket handlers and they are working fine under the new regime. Just the underlying message I/O plumbing was updated. It all works the same from a CML code point of view.

This means I can now start getting bug fix drops out, and can move on in the meantime working on the RIVA migration without causing any issues for the mainline code, but without having to go to beta mode yet and split the code base. In theory I can get the web based RIVA setup going completely on the side and never have to do a beta phase for 5.2, but that might not work out in practice, we'll see. At least until such a time, no matter what shape the WebRIVA stuff is in, I'll always be able to do more bug fix slash small improvements updates without the huge overhead of a split code base.

* The existing RIVA system will be left in place of course during the transition, to give us all time to get used to the new guy and work out the issues. Then we'll eventually retire it.

Some of you might remember we were going to do a room config based app first. But, upon further investigation, the possibility of a browser based RIVA client seemed a lot more doable. And, if we can do it, it'll mean we can retire the current RIVA stuff much sooner and have a viable non-Windows client again.

The ultimate goal is still a 'fat' web based client for non-Windows platforms, or at least a lot fat'er. But we want to hold off on that, because things are percolating in the web based client world that offer the promise of using .Net for portable development of browser delivered clients (based on WASM.) So, if we can get a web based RIVA client working, that gets us the breathing room to let that situation develop, and hopefully be able to move forward on a fat(er) non-Windows client using a real development environment and real language. That would be a HUGE benefit.

Though it's something you guys won't see, I also spent some days creating a little 'compiler' program that let's me define the RIVA protocol in XML. It reads that and generates constants, enumerated types, and helper methods for both C++ and Typescript. This will vastly simplify things in this new WebRIVA effort, and make it far less likely that mistakes creep in due to failure to keep the two sides in sync.
Dean Roddey
Software Geek Extraordinaire
Reply
#26
BTW, support is in this release for the Fibaro RBGW controller, but it doesn't work correctly yet, because the controller is not well documented and the usual fighting with Z-Wave to get anything to work like I want it to. So don't configure them if you have any in your system. They will show up in the client interface, but just ignore them, better yet mark them as ignored for now.
Dean Roddey
Software Geek Extraordinaire
Reply
#27
We are in the annual summer "Slough of Automation Despond" it looks like. All of the automation fora go dead at the same time. Some sort of homing instinct that causes that automation people to all swim upstream at the same time to their ancestral beach chairs and drink pina coladas or something.
Dean Roddey
Software Geek Extraordinaire
Reply
#28
Yup {B} (emoji for beer if it were to display)
Reply
#29
Web browser support shouldn't be so difficult! Two things -

1) The documentation still refers to the old name of CQCWebHelper.exe in the web browser section that talks about setting the registry key

2) A couple of my main menu commands do full screen popups; I never hit this before but if I execute them with the web browser control showing the popups are (mostly) behind the web browser widget. Is there a user command that I can use to force the web helper to be behind the IV and then to pop it back when the popup completes? Or should I just create a blank window to load into the overlay area before I do the popup?
Mark Stega
Reply
#30
1. I'll fix the docs. Was it ever Web helper? Anyhoo, now its CQCWBHelper and the web camera is CQCWCHelper.

2. The helpers have to create separate windows. So they will always be on top of any IV content. The IV content is drawn into the main IV window, so it can never be on top of the helper windows.

The helpers are owned by the main IV window, which is what makes the act as though they are part of that window (or a large part of why they do.) That includes making sure that they stay on top of it, else any interaction with the IV would make it come up over them.

You can just hide them before the popup if you want. Put some place holder image behind it that will show when it's hidden or something like that. Then show them again when you come back.

Or, just always put them on a popup, so you invoke a popup to see them, which insures that they should actually be on top of any of the base template content anyway.

Or keep them to the side so that they never overlap any popups.
Dean Roddey
Software Geek Extraordinaire
Reply


Possibly Related Threads...
Thread Author Replies Views Last Post
  5.2.0 follow up releases Dean Roddey 3 215 10-25-2017, 12:46 PM
Last Post: Dean Roddey
  A 4.3 followup release candidate Dean Roddey 11 1,675 06-02-2013, 07:24 PM
Last Post: Dean Roddey
  4.2 Followup Releases Info Dean Roddey 131 7,945 11-28-2012, 08:36 PM
Last Post: Dean Roddey

Forum Jump:


Users browsing this thread: 1 Guest(s)