We have solved this by creating only one application. The users "buys" a password, and this password is created by us in a special program. We enter the customer's name, how many simultanous users they pay for, how long time they pay for which modules they want to use and so on. This means that the password is very long, but with cut'n'paste that's no problem.
This password is stored on the users' computer, and the application checks every day that the the password is valid. Plus they get an early warning when the program is close to "expire". When this password is entered the first time, the program sends a message back to us with unique information about their computers. This information is used by us to generate a second password which also must be entered by the users. Since this second password includes information about the users' computers, they give us 100% protection against people trying to get away without paying.
>Hi all
>
>This may be steep requirement. I have multiple interest from clients for an application of mine which is currently under works. I intend to charge the clients on a module by module basis so if a client orders module x he will be charged for it but other clients should not be able to see it till they pay for it. I don't think I will be able to manage multiple exes it has to be in the same main exe. I just intend to flag it at the menu option level (the database contains all and every table for all the clients).
>
>What kind of a coding scheme would you suggest. The general concept I have in mind is that I have a code assigned to each and every client. This code will contain the information of which modules are available to the client. At every (class based) menu option I should check if the menu should be visible or not.
>
>Now the million dollar question is there may be many modules and many combination all to be gleaned from this one code. I could use a character code which could have 1 for active 0 for invisible for eg. 0100111 (modules 2, 5, 6 and 7 visible) but then the field will have to be huge.
>
>Any better idea?
>
>Thanks.
