Primary needs different behavior from Secondary and will be sold as separate product

[mmehr2]

This involves the requirement for ECS to sell the Primary version of MSW-Remote as a separate product than the MSW-Remote Secondary teleprompter product.

The Primary is for central office use, and will pair up with multiple Secondary teleprompter machines in various remote studios, only one at a time.

The UI dialog box (Remote Installations, called RemoteDialog in the code) needs to either disappear or be grayed out in the Secondary version. Or it could be replaced by a RemoteStatus dialog that would only report the conditions between the Secondary and the net (Pubnub), and optionally allow for manual Login/Logout if we need that for billing support.

In addition, there is a requirement for this new UI behavior to be documented in the Help System (see related issue #21).

[mmehr2]

This is related to issue #5 which details the requirements for the Primary feature, but not the need for the two separate versions talked about here.

It is also related to the feature of the Secondary version of this dialog, issue #20.

[mmehr2]

Why this is here:

Differs from #7 in scope, supersedes and includes it.

We could compile two different EXE binaries from the same source and set it up that way. I think this would best fit ECS Video's current needs. How to generate the production versions of the installers for each is still a question I have. Hopefully it's a simple matter of making an installer that would install the Primary binary, and another to install the Secondary.

We could implement one binary and have the choice be made by an INI file setting, or presence of a hidden file, or a registry setting. This however would make it possible for the customer to change a Primary into a Secondary and avoid buying it separately.

The Primary/Secondary Installer change is probably much more simple than the other way, and would lead to less likely of a need to bring Inno Setup up to date. (But see issue #8 and #2.)

[mmehr2]

Work tasks: Choice: Work with two EXE binaries for now, also implying two installers.

UPDATE 3/29: Instead of two EXEs (and making so many builds for Debug vs Release), we can use a hidden registry setting that can be set by a special version of the Installer program.

• [x] - Remove the XMPP/libjingle code and libs from the U build configs. (Do this first). Also exclude files.
• [x] - Split off two configurations for Plain (DebugU and ReleaseU) and Remote (DebugR and ReleaseR) builds (this is issue #7).
• [x] - Exclude all remote source files from the Plain builds.
• [x] - Configure the code with conditional checks in the appropriate startup place, mostly for the UI. OK to test the runtime flag in most locations, as is done now. Use an undocumented registry setting to determine who is Primary and who is Secondary.
• [ ] - Create a second Installer program that sets the flag in the registry to allow Primary operation.
• [ ] - Work out the names for these installers. Binary will retain the MagicScroll.exe name.
• [ ] - Get official release numbers from Eric.
• [ ] -- Version resource update (it does exist)
• [ ] -- Help/About box (automatically uses version resource if done properly)
• [ ] -- Splash screen update (same, if done that way)

[mmehr2]

So far I've completed the following:

• Split off two configurations for Plain (DebugU and ReleaseU) and Remote (DebugR and ReleaseR) builds (this is issue #7 - see note added there).
• Exclude all remote source files from the Plain builds.

I'll try removing the XMPP stuff later, for now it is a good reference to sanity check against. I do need to remove the calls though.

[mmehr2]

I have added one #ifdef PRIMARY block that sets the PubnubComm object to whether it operates in Primary or Secondary mode. All I need to figure out is how to leave the UI disabled in this case too, and we are all set.

Then we must build twice for each iteration, with and without the setting on - how to best accomplish this? Two configurations means maintaining two separate copies of all those file lists and settings, and creates a combinatorial explosion with all the builds (ReleaseU shouldn't care, but ReleaseR needs to be built twice, to generate the Primary and Secondary EXE files and installers, as well as DebugR twice.)

Perhaps it really would be better to implement the flag in the installer somehow? One idea I am favoring now is to set a hidden registry setting that the code can check for. So unless someone learns about what this is and can hack it, the installer code is in charge of determining which machine operates in Primary mode. It should be lots easier to generate two Installer programs that differ in this setting, thanks to Inno Setup 5. And the Primary Installer can be executed to set the flag on the machine designated as Primary, where as the Secondary Installer clears that flag.