This content has been marked as final. Show 5 replies
Wow, I'm sure it's probably possible to accomplish, but I sure couldn't tell you how to do it.
I'm not sure why you wouldn't want this handled at the installer level though. I mean, how are you currently handling the installation for the two different setups? You mention a license, so I'm inferring that they buy product A or product B.
I spent about a year and a half working as a lone Tech Writer for a small software company. There, an employee worked as the lone "installer builder". This guy was totally responsible for creating the installer. So it would seem to me a very straightforward way to approach this would be to have the singular installation program make some sort of determination which help file should be installed. I suppose this could even happen by virtue of a license key that is provided at time of purchase. If it's a key of this variety, install this version (and applicable .CHM) if the other variety, install the opposite.
Just a thought... Rick :)
Hi there Jeffch1970
We have a similar set up with the application we deliver. I create two .chms but I use different file names for each of the builds. When the application is opened, only those screens that the user is licensed for can be accessed. When F1 is pressed, the application also looks at the licensing to call the relevant chm.
Unfortunately, the code required to make this happen is beyond my realm of experience and would very much depend on the language the software is written in. But at least you can tell your developers that it is possible.
Interesting. So what do you do if the customer goes spelunking the disk and just double clicks the .CHM they aren't supposed to see? How are you preventing the information from displaying in this case?
I'm going a bit out on a limb here and assuming that you would know a bit about how to make this happen, as the only way I could fathom it would be to specially do something prior to compiling the .CHM file. The only other possiblity that occurs to me is if you somehow decided to rename the .CHM to something different and your developers set calls up that looked for the alternate file extension.
Cheers... Rick :)
Our application calls either ProductA.chm or ProductB.chm when F1 is pressed depending on the license key.
The application is written in Progress and uses a Blob (whatever that is). The Blob lays down a local copy of the appropriate .chm on a Workstation when the application is first opened. From then on, it checks the version of the .chm each time the application is opened to ensure that the latest version of the .chm is on the local drive, if the help file has been updated since the .chm was laid down, the Blob replaces it with the newer version.
In 99% of our client sites, the application is installed on a server and accessed via Workstations. Only the server would have both .chms and all the source. I guess if someone from ProductA really wanted to (and they had access to the server), they could browse the program files until they located the ProductB.chm.
Thanks for the help everyone. After much discussion and fair amount of high-level squabbling, we have come to the conclusion that we are going to say screw it. In essence, we were attempting to keep from mentioning one of our products in the help. We have a user company that competes with us in one application, but uses our other app in conjunction with their own. We decided that trying to hide the fact that we make a piece of software is like a bird trying to hide it's wings-thier analogy, not mine. Thanks again for the help. The difficulty in the resolution sealed the fate of the dual CHM idea.