What is wrong with CQC?

[Dean Roddey]

If the product is a single application, then depending on the computer login would be sufficient. But that's not the case here. Just because someone has to the login to a given computer doesn't mean you want to allow them to mess with your CQC configuration. And that's very important in the pro/commercial world where the installer is the only one who wants to be able to make fundamental changes, but still needs to allow the user to run non-administrative programs.

 

[Deane Johnson]

OK, so I went to the FAQ  to look at the low security log in environment.  I believe this is a classic example of what we might be talking about.  There's a bunch of stuff I have to do to make it work.  I only want to check a box that lets me eliminate any security since I don't need any.

 

[Dean Roddey]

You can't really eliminate security, just as with Windows. In order for security be actually useful, it must be fundamentally integrated into the product, else it wouldn't be very effective. Just as with Windows you always have to login. The best you can do is to indicate what user account you want to log in with and let the client programs do that for you.,You have to do that on each client, it can't just be on the server, else the security would be useless if any computer that could connect to the server could ask for login credentials and get in. And it wouldn't allow for different accounts to be used on different clients (which there are very good reasons to do.)
 
So probably not ever just going to be a check box.

 

[fcwilt]

If the product is a single application, then depending on the computer login would be sufficient. But that's not the case here. Just because someone has to the login to a given computer doesn't mean you want to allow them to mess with your CQC configuration. And that's very important in the pro/commercial world where the installer is the only one who wants to be able to make fundamental changes, but still needs to allow the user to run non-administrative programs.

 
You could still implement single login with multiple layers of access - if the person who is logged in doesn't have the required permissions they simply cannot launch that program. There are many ways to achieve this. Perhaps the cleanest would simply be a central app where all other "child" programs are started from. The permissions of the logged in user determine what programs they can see.
 
There are many other tools out there that manage multiple layers of access without having to login over and over.

 

[Dean Roddey]

I guess it could be a deal where, if you've not so far logged in (to any open app) with an account required for the new program you are trying to log into, then it would prompt you to log in, and store that new info.
 
Of course, any time you try to make it easier, you increase the odds of making bad mistakes. If you walked up to a limited user's machine (as an admin) and ran a program that prompted you for admin rights, you would immediately elevate that machine to your account level. If you then walked away, that user would still have your administrative rights, even if you closed the app you were using. He could just start it right back up, because you've raised that machine's rights.
 
All these things have to be dealt with. It's stupidly easy to make simple mistakes that make the security system useless, or put the all of the onus on the user to never make a mistake, whereas just requiring a login avoids all those possible issues.
 
If you know of other (multi-user, networked, multi-application) tools that do this, how do they work?

 

[Deane Johnson]

I have to log into many things on my computer, particularly on-line.  Amazon for instance.  However, it gives me an option of "remember me".  It's a click box.  Would it be possible for CQC to have that?

 

[fcwilt]

I guess it could be a deal where, if you've not so far logged in (to any open app) with an account required for the new program you are trying to log into, then it would prompt you to log in, and store that new info.
 
Of course, any time you try to make it easier, you increase the odds of making bad mistakes. If you walked up to a limited user's machine (as an admin) and ran a program that prompted you for admin rights, you would immediately elevate that machine to your account level. If you then walked away, that user would still have your administrative rights, even if you closed the app you were using. He could just start it right back up, because you've raised that machine's rights.
 
All these things have to be dealt with. It's stupidly easy to make simple mistakes that make the security system useless, or put the all of the onus on the user to never make a mistake, whereas just requiring a login avoids all those possible issues.
 
If you know of other (multi-user, networked, multi-application) tools that do this, how do they work?

 
Let's take Elan for example.
 
There are essentially two applications - the client viewer, where requiring login is optional and the main configuration tool - which is the front end for everything else, configuration wise.
 
If client viewer login is enabled then the person logged in can only view the screens they are assigned - otherwise everyone sees the same default set of screens.
 
If you can login to the configuration tool you can do everything.
 
So there are essentially only two categories of users - viewers and administrators.
 
 
Typically the installer is going to limit the configuration tools to his own computer(s) and connect locally or remotely to configure the system. In this case the only application the end users have access to is the viewer.
 
 
Even if the configuration tool WAS installed on one of the customers computers without the login information there is nothing they can do.
 
 
Seems to me CQC could do the same - have a main tool which requires login and provides access to all of the "child" tools. If needs be you could have multiple levels of access but I don't really see the need. Either you are an administrator or you are not.

 

[fcwilt]

I was thinking about your remark about the amount of time that making a dialog required.
 
I gather you are not using, as your development tool, something like Visual Studio where the process of creating a dialog is simplified by the ability to drop controls on a form, set some properties and code some event handlers?

 

[Dean Roddey]

I have my own design tool, so it's not the layout and the setting up of handlers. That's all easy enough.
 
It's managing the state of everything to correctly reflect the needs of whatever is being done. It's sometimes very complicated, and it's often something that's easy to make a mistake with when making changes, because the requirements of enforcing whatever rules are relevant to the thing at hand are sometimes pretty complex. Keeping things enabled or disabled based on the state of various other things or what the user has entered so far, making sure focus and default button status correctly handled when things are enabled and disabled, trying to arrange it as much as possible so that only valid input can be provided so as to avoid having to do lots of validation at the end, managing the enormous number of loadable text messages that come with such a large product and trying to be sure that there's not tons of duplication of messages (since one day we may have to pay to have them translated), dealing with errors appropriately so that things get undo that should get undone if something goes wrong. Dealing with trying to make sure that the error messages points them to the right thing where possible, dealing with event handlers during initial loading since the ordering can cause things to be changed that shouldn't be changed, making sure the tabbing stuff is all correctly done, etc...
 
All that stuff comes up over and over and over, and it's not stuff that can easily be automated, because it depends on knowledge of the constraints of the data being edited generally.
 
But certainly, if I end up starting again, I will spend time looking for as many commonalities as I can find and create more helper base classes that will make some stuff easier to do if it follows this pattern or that pattern. That's something that's vastly easier to do if you have already done it once.

 

[samgreco]

Dean - After reading all of this thread, I get the sense that the issue is really that CQC is designed first and foremost for the pro installer.  The high-level DIYer is the secondary market.  The mass market really doesn't fit.
 
So the question in all of this should really be, how do you take a bite out of Crestron, AMX, etc.?  Have you ever had a presence at Cedia?  Or have you considered hiring Manufacturers Reps (a small percentage) to get the word out?  I used to be a manufacturers rep in the audio industry so I could certainly point you in some directions.
 
But I also understand that it is an uphill battle getting them to let go of what they know and use the dreaded Windows PC.

 

[Dean Roddey]

It was certainly initially created for the pro installation world. But of course they tend to be a VERY conservative bunch, hence my discussion previously of how nice it would be if more IT type folks would get into the automation world by way of something like CQC that would very much work within their realm. It would be easier if we had the means to get it into a bespoke enclosure.
 
For the installers using the product, it's doing them very well. One has put CQC into like 10 Pluckers sports bars down in the Dallas area, plus some restaurants and theaters.
 
What we'd prefer more than reps is a sales person who would work the pro market and get us more installers signed up. But it would have to be an equity sort of deal in the short term. But it wouldn't take that many pro installers getting on board to get the revenues up enough to start paying salaries.
 
Not to say that many of the suggestions in this thread wouldn't also be useful to the pro installers. I'm sure they'd like to have a lower end, simpler solution to go with the higher end solution, and easier setup. If they can do it with one product, all the better for them.

 

[fcwilt]

Yes I found handling state for Forms a rather difficult task. I settled on a "flag" class where each changed field set a flag. When a flag was changed a routine processed all the flags and determined the state of all the controls on the Form.
 
Field validity checking also used the flag class so that information could be taken into account. 
 
The advantage was all of the logic for what should/should not enabled was in one place - the flag change handler.
 
The disadvantage was if you had a ton of fields performance could suffer - but tons of fields would indicate a Form that was probably too complex.
 
Strings went into Windows resources so they were all in once place. The tool that managed them insured the any identical strings were merged. And the translation tool was intended to generate resources in other languages - but I never had to do that.

 

[Dean Roddey]

I considered a flag type of solution, but the problem is that sometimes it's a complex combination of and/or/xor type of deal, and keeping track of all of that for every possible scenario and the mechanisms to indicate all the possible scenarios is itself fairly complicated, and very separate from code so that it's also sort of easy to change them incorrectly.
 
Another option is to define a set of possible states for a dialog, and let each control pass judgment on a newly set state and adjust themselves. I could do that since all of the controls are my own, so I could build such a mechanism into every control, so that you could add a list of states to one that it should consider disable me states.
 
But you still have to deal with how do you move focus and default button emphasis correctly when you enable and disable controls. The default things that happen are not always the desired ones. There again, since I'm doing my own, I could have the dialog class also support the states and load it up with what to do for each one. But that is also still a fairly complex and easy to mess up system.
 
We also have our own loadable resource system, and text is defined in the resource system. But it's not a single program. We have a huge general purpose code layer with lots of DLLs and exes, and a lot of DLLs and Exes in the CQC layer on top of that. Having a single, enormous loadable text file for the whole thing would be a huge mess to keep up with. And the general purpose and CQC code bases are completely separate, so no tool sees them all together anyway, and the general purpose part has to be usable completely separate from the CQC layer.
 
The issue isn't identical strings, but trying to only have one loadable text string that is used for a given thing, and not create multiples of them around the system. That's very difficult as it gets larger and larger, to be sure that there's not a string already in there somewhere that essentially says what you want to say, or should you add another one. I keep them well organized but it's still difficult as it gets larger. And of course if you use one from a lower layer that appears to say what you want, but for some reason that text later is changed due to requirements down in that layer, to be sure you've found all uses of it and made sure that replacement tokens are still handled correctly for the new text and such.
 
Anyway, as with any really large bunch of data, sheer size becomes your enemy.

 

[fcwilt]

I used the flag class for many years in a variety of applications and while it may have issues it was the best solution I ever came up with.
 
Having the decision making all in one place was a big plus in my book.
 
I also liked the fact that the controls only needed to "know" what their associated flag was and what constituted a valid value. That knowledge needed to be somewhere and it seemed to keep things the "cleanest" when it remained with the control.
 
In practice it worked very well. I never encountered a situation which led me to seek another approach.

 

[samgreco]

Dean - Think of manufacturers reps as sales people that don't get paid unless the sell something.  So if they sign up a dealer, they get a small percentage (typically % or 6%) of everything that dealer/installer buys going forward.
 
There is a big show in June in Orlando, InfoCOMM.  That is the commercial equivalent of CEDIA.  But much larger.  I did more on the commercial and musical instrument side than home when I did it.  I actually have customers still in that industry for my IT services and web stuff.