Creating ADD ONS
in [Visual Basic]
|
From: Webbiz on 16 Feb 2010 14:04 On Tue, 16 Feb 2010 00:06:04 -0500, GS <GS(a)discussions.microsoft.com> wrote: >Webbiz explained on 2/15/2010 : >> On Fri, 12 Feb 2010 08:44:40 -0600, "Larry Serflaten" >> <serflaten(a)usinternet.com> wrote: >> >>> >>> "Webbiz" <nospam(a)noway.com> wrote >>>> Suppose you have a VB6 application that is already completed, but you >>>> want to now add new functionality by way of ADD ONS that are purchased >>>> separately. >>> >>>> ... When purchased and properly installed, it shows up under the ADDON >>>> menu that the user can now select and it will do its thing. >>>> Suggestions, pointers, etc. would be appreciated. >>> >>> >>> Its rather interesting that you've completed the app, yet gave it an ADDON >>> menu item, without fully defining how that menu item will be used.... >>> >>> As some have already stated, something like that should be included in >>> the initial design. Are you saying you can alter the source code to >>> 'retrofit' the new capability? Or are you only able to work with an >>> application that has already been shipped? >>> >>> The other aspect that needs further detailing is your idea of what a >>> 'module' is. If you have (for example) a music player and you now >>> want it to play video, then that's a major UI change, isn't it? >>> >>> Take a look at VB's own Add-In manager, and the types of things >>> it adds in. Is that about what your after? >>> >>> LFS >> >> >> I didn't say that my completed app had a menu item for ADD ON's. I was >> saying that I have a completed app that I 'now' would like to give it >> the ability to add new features, sold separately. >> >> The solution I most favor at this point is to simply add the ability >> to the application and have it deactivated. If purchased, the user can >> purchase the new key. >> >> This would work well for me as I already know how to add new >> functionality to my apps and can easily adapt my app to unlock >> features based on 'codes' or 'keys'. >> >> Thanks! >> >> Webbiz > ><Built-in> >What you're saying here now is that your intention is to make app >levels similar to how others issue app editions. (i.e.: Standard, >Professional, Enterprise...) This concept usually precludes that all >features and functionality are shipped and installed, with specific >features and functionality only made available if the right level of >'license key' is entered by the user. This is trivial to achieve, as >you state here, only if you use a good licensing methodology. Adapting >your apps to implement this could be as simple as hiding the menus that >access the extra features, and unhiding them after the correct 'key' is >entered. Of course, it could also be more complex than that depending >on how your app is designed and coded. > >If you employ the 'try it before you buy it' concept, usually the app >runs in 'trial' mode for a given period of time or number of executions >during which all features and functionality are available for >evaluation purposes. The user can then decide what 'edition' to >purchase based on having full use during the trial period. In this >case, having the features built into the app from the start makes >sense. ></Built-in> > ><Add-ons> >The concept of 'Addons' as commonly used by many software products is >quite different, and typically refers external apps or components (or >as you stated: 'modules') that would be shipped separately to extend >features and functionality of an already finished app. This is what I'd >be interested in doing with VB6 because it allows me an opportunity to >give clients added functionality that directly pertains to their >specific needs while using my apps, and allows the client to customize >what they can do with my app beyond the standard features. For example, >it's common for users to want data exported to their accounting >software or database. Since not everyone uses the same accounting >software or database it precludes that building this into the app >doesn't make sense. I don't mean generic data export; what I mean is >user-defined details that are unique only to that user. Generic >requests can usually be added to the core app as an update/upgrade >feature, and is usually how it's handled if several users make the same >or similar request. > ><IMO> This approach should also employ the 'try it before you buy it' >concept because if your user doesn't like what he buys from you then >how do you handle refunding him and making sure the addon isn't used >any longer? ></Add-ons> > >Since you expect to get paid for the extras, you need to have a >methodology in place that ensures you get paid for every install. This >is determined by the scope of the 'unlock key'; --How many machines can >it be used on (i.e.: is it locked to the user, the app, or to a >specific machine)? Simple licensing schemes don't offer much security >or flexibility. Even the schemes that use private/public key >cryptography are only as good as the bit strength of the keys. The >higher the better, but nothing is 'bullit proof'. Some of the highest >bit strength methodologies may take years to decrypt based on today's >computing power, but I don't think this matters since most users >wouldn't bother to crack your keys unless the benefit is well >worthwhile. So unless your app involves national security stuff or the >like, it's reasonable to assume you're probably going to get paid for >every extra. > >Kind regards, >Garry > All my applications are niche products sold to those who are already aware of what they can do for them. At this time, there is no 'try before buy' scenario. In the case of the 'charting' program, as with the other apps, these are all 'protected' using protection software that requires a 'key' to unlock the application to a specific computer or to simply unlock the application on any system. Depends on the app. I've been using the protection scheme for over 10 years now successfully. Recently, I had provided users of one of my apps the option to 'unlock' a special module already built into the program if they met certain requirements (ex: attend a special webinar, for example). So for those who met the requirement, they got a 'key' that unlocked the module that was already domant within their app they possessed on their machine. So this is why I said I was already 'familiar' with this approach. The thing about this approach, however, is that I would have to update the main core app each time to add something, and then the user would have to download the new updated app first before unlocking with a new special 'key'. My preferred method would be to leave the original app alone and simply sell new code modules that can be downloaded and used by the original core app. The program would likely have to then use multiple keys, where each key adds an additional feature sold separately. This way, users can just add what they want. From reading the replies to this thread, I was not able to come away with a 'clear' idea as to how one would do this. Some say write a 'dll' for each and others say "don't do it!". As a novice programmer (most of you here are so way over my head in techno speak, LOL), I would need a clear 'path' to take in order to go the 'preferred' route of separate modules. Meanwhile, I can impliment these new modules within the core app and produce keys that unlock 'levels' within the code. This is provided by the protection software I have been using these past 10 years. It provides the means to activate and deactivate code segments within app by providing custom 'keys'. If I could just focus on new modules that could be absorbed by the original core app when purchased, that would be my preferred way to go. But until it is clear in my head how I'm supposed to do something like this with VB6, it appears my only solution is to just add it to the core app and 'mark' those sections for activation by 'key'. Thanks! Webbiz
From: Schmidt on 16 Feb 2010 14:31 "Webbiz" <nospam(a)noway.com> schrieb im Newsbeitrag news:93qln5tlgoktvdsiq24oo72fhouidrsia9(a)4ax.com... > Meanwhile, I can impliment these new modules within > the core app and produce keys that unlock 'levels' within > the code. If you implement each module within a Class instead of a *.bas-module, then you're "halfway done" with regards to a "plugin-model". Just try to implement the functionality isolated from "surrounding modules and their Public Functions". Specify tight Interfaces in your Module-Classes, meaning - try to "invent" Public Subs and Functions, which get all their Data (from your surrounding App) passed over Standard-VB-Param-Types or Objects - but try to keep the Function-Count low, as well as the Parameter-Count in each Function. Then - after implementing two or three of these Class-Modules you should take a look at the Function-Naming and the Similarities among them - then try to re-implement all of these Modules using only this "common Function-Set". This is something like an "evolutional way", to establish a robust and common (generic) Interface, usable by all of your other (future) plugins. If that common interface (the generic set of Subs and Functions) has proven successful, then you can take the next step - and switch from internal (Class-)Module-Functionality to an external one. No need to rewrite much - just move these proven (App- Private) Classes (each) into a different ActiveX-Dll, and your proven Interface should then be defined as an "abstract one" - and should be Implemented (with VBs Implements- Keyword) by each of your worker-classes (plugin-classes). Finally you could even instantiate these Plugin- Dlls (and their Public Class) regfree - against the abstract "Interface-Dll" which you should not change anymore (or change only BinCompatible). That would be something like a "smooth migration" - first step: - each different Functionality sitting in its own Private Class (directly within your Main-App) - second step: - try to ensure in each of the Classes the very same set of Functions (some Classes using the full function-set, some classes only some of them - optional Parameters and Enums can help in this "generalization-process" too). Last step(s) - use the proven (common) function-set to define an abstract Interface-Class - and make each of your yet Private Classes Implement this Interface. Then you're free to each of these Classes out of your Project into separate AX-Dlls. Olaf
From: Larry Serflaten on 16 Feb 2010 15:56 "Webbiz" <nospam(a)noway.com> wrote > >> ... When purchased and properly installed, it shows up under the ADDON > >> menu that the user can now select and it will do its thing. > I didn't say that my completed app had a menu item for ADD ON's. Well, that's the way it appeared. If the ADDON menu wasn't in the main app, where was it??? > The solution I most favor at this point is to simply add the ability > to the application and have it deactivated. If purchased, the user can > purchase the new key. If that works for you, then go for it, but as you indicated you'd be doing some customizations (for specific users)and that could get to be a maintenance nightmare when some shops want feature X, so you add the feature and give them a key, then some other shops want feature Y, so you add that and give them a key. And so on for some amount of time. Then the X shops have trouble, and you have to remember what version they had, or tell them to upgrade all their boxes, etc. etc... And so on for so many different features. As Olaf suggests, eventually you need to put your features in their own classes. After a few of those, you might be experienced enough to try the DLL approach. Rome wasn't built in a day! <g> Good luck! LFS
From: GS on 16 Feb 2010 16:20 Webbiz used his keyboard to write : > On Tue, 16 Feb 2010 00:06:04 -0500, GS <GS(a)discussions.microsoft.com> > wrote: > >> Webbiz explained on 2/15/2010 : >>> On Fri, 12 Feb 2010 08:44:40 -0600, "Larry Serflaten" >>> <serflaten(a)usinternet.com> wrote: >>> >>>> >>>> "Webbiz" <nospam(a)noway.com> wrote >>>>> Suppose you have a VB6 application that is already completed, but you >>>>> want to now add new functionality by way of ADD ONS that are purchased >>>>> separately. >>>> >>>>> ... When purchased and properly installed, it shows up under the ADDON >>>>> menu that the user can now select and it will do its thing. >>>>> Suggestions, pointers, etc. would be appreciated. >>>> >>>> >>>> Its rather interesting that you've completed the app, yet gave it an ADDON >>>> menu item, without fully defining how that menu item will be used.... >>>> >>>> As some have already stated, something like that should be included in >>>> the initial design. Are you saying you can alter the source code to >>>> 'retrofit' the new capability? Or are you only able to work with an >>>> application that has already been shipped? >>>> >>>> The other aspect that needs further detailing is your idea of what a >>>> 'module' is. If you have (for example) a music player and you now >>>> want it to play video, then that's a major UI change, isn't it? >>>> >>>> Take a look at VB's own Add-In manager, and the types of things >>>> it adds in. Is that about what your after? >>>> >>>> LFS >>> >>> >>> I didn't say that my completed app had a menu item for ADD ON's. I was >>> saying that I have a completed app that I 'now' would like to give it >>> the ability to add new features, sold separately. >>> >>> The solution I most favor at this point is to simply add the ability >>> to the application and have it deactivated. If purchased, the user can >>> purchase the new key. >>> >>> This would work well for me as I already know how to add new >>> functionality to my apps and can easily adapt my app to unlock >>> features based on 'codes' or 'keys'. >>> >>> Thanks! >>> >>> Webbiz >> >> <Built-in> >> What you're saying here now is that your intention is to make app >> levels similar to how others issue app editions. (i.e.: Standard, >> Professional, Enterprise...) This concept usually precludes that all >> features and functionality are shipped and installed, with specific >> features and functionality only made available if the right level of >> 'license key' is entered by the user. This is trivial to achieve, as >> you state here, only if you use a good licensing methodology. Adapting >> your apps to implement this could be as simple as hiding the menus that >> access the extra features, and unhiding them after the correct 'key' is >> entered. Of course, it could also be more complex than that depending >> on how your app is designed and coded. >> >> If you employ the 'try it before you buy it' concept, usually the app >> runs in 'trial' mode for a given period of time or number of executions >> during which all features and functionality are available for >> evaluation purposes. The user can then decide what 'edition' to >> purchase based on having full use during the trial period. In this >> case, having the features built into the app from the start makes >> sense. >> </Built-in> >> >> <Add-ons> >> The concept of 'Addons' as commonly used by many software products is >> quite different, and typically refers external apps or components (or >> as you stated: 'modules') that would be shipped separately to extend >> features and functionality of an already finished app. This is what I'd >> be interested in doing with VB6 because it allows me an opportunity to >> give clients added functionality that directly pertains to their >> specific needs while using my apps, and allows the client to customize >> what they can do with my app beyond the standard features. For example, >> it's common for users to want data exported to their accounting >> software or database. Since not everyone uses the same accounting >> software or database it precludes that building this into the app >> doesn't make sense. I don't mean generic data export; what I mean is >> user-defined details that are unique only to that user. Generic >> requests can usually be added to the core app as an update/upgrade >> feature, and is usually how it's handled if several users make the same >> or similar request. >> >> <IMO> This approach should also employ the 'try it before you buy it' >> concept because if your user doesn't like what he buys from you then >> how do you handle refunding him and making sure the addon isn't used >> any longer? >> </Add-ons> >> >> Since you expect to get paid for the extras, you need to have a >> methodology in place that ensures you get paid for every install. This >> is determined by the scope of the 'unlock key'; --How many machines can >> it be used on (i.e.: is it locked to the user, the app, or to a >> specific machine)? Simple licensing schemes don't offer much security >> or flexibility. Even the schemes that use private/public key >> cryptography are only as good as the bit strength of the keys. The >> higher the better, but nothing is 'bullit proof'. Some of the highest >> bit strength methodologies may take years to decrypt based on today's >> computing power, but I don't think this matters since most users >> wouldn't bother to crack your keys unless the benefit is well >> worthwhile. So unless your app involves national security stuff or the >> like, it's reasonable to assume you're probably going to get paid for >> every extra. >> >> Kind regards, >> Garry >> > > > All my applications are niche products sold to those who are already > aware of what they can do for them. At this time, there is no 'try > before buy' scenario. > > In the case of the 'charting' program, as with the other apps, these > are all 'protected' using protection software that requires a 'key' to > unlock the application to a specific computer or to simply unlock the > application on any system. Depends on the app. I've been using the > protection scheme for over 10 years now successfully. > > Recently, I had provided users of one of my apps the option to > 'unlock' a special module already built into the program if they met > certain requirements (ex: attend a special webinar, for example). So > for those who met the requirement, they got a 'key' that unlocked the > module that was already domant within their app they possessed on > their machine. > > So this is why I said I was already 'familiar' with this approach. > > The thing about this approach, however, is that I would have to update > the main core app each time to add something, and then the user would > have to download the new updated app first before unlocking with a new > special 'key'. > > My preferred method would be to leave the original app alone and > simply sell new code modules that can be downloaded and used by the > original core app. The program would likely have to then use multiple > keys, where each key adds an additional feature sold separately. This > way, users can just add what they want. > > From reading the replies to this thread, I was not able to come away > with a 'clear' idea as to how one would do this. Some say write a > 'dll' for each and others say "don't do it!". As a novice programmer > (most of you here are so way over my head in techno speak, LOL), I > would need a clear 'path' to take in order to go the 'preferred' route > of separate modules. > > Meanwhile, I can impliment these new modules within the core app and > produce keys that unlock 'levels' within the code. This is provided by > the protection software I have been using these past 10 years. It > provides the means to activate and deactivate code segments within app > by providing custom 'keys'. > > > If I could just focus on new modules that could be absorbed by the > original core app when purchased, that would be my preferred way to > go. But until it is clear in my head how I'm supposed to do something > like this with VB6, it appears my only solution is to just add it to > the core app and 'mark' those sections for activation by 'key'. > > Thanks! > > Webbiz Thanks for the feedback! Well, if you've been using software protection for 10 years then you've got more years of programming experience than I do. It sounds like you DO want to implement Addons as independent components, though. Olaf raises some good points. Larry also has some worthy suggestions. I plan to persue these to the same end; --where the core app remains independent of the addons, and addons are separate from the core app. I'm not sure what software protection methodology it is that you use but can it not accomodate addons by simply upgrading a current license? For example, you issue a license key for the core app; -then later you reissue a license key that includes the purchased addon so that you don't have to manage multiple license keys. This requires a methodology that allows any amount of data to be encrypted into the license key. Surely it would simplify management of addons whereby you could activate them based on the license 'profile' as defined in the license key. This is what I use, and I issue a LicenseKey_#...#.exe that handles the process. Since most of my apps are machine-locked, the '#...#' is the actual SeatID (a unique serial#) of the target installation. It will only work with that installation as long as it remains on that machine. Adding features then is as simple as upgrading the license key and sending a new LicenseKey_#...#.exe for that particular install on that particular machine. I don't see why you can't use DLLs. That's what I will do. Currently, the DLL just opens a dialog that contains a menubar (and optionally a toolbar) which looks/feels/behaves like a floating toolbar, which is how I currently give users access to the features. The issue is when there are multiple addons available for a single core app. I'd like them to add and use their own menus on the core app's menubar and so is what I'm working toward. This makes it look and feel like a seamless integration, which is how it should be <IMO>. For an example, look at how the Mozilla Project works with Addons. -- I appreciate your input... Kind regards, Garry
From: Mike Williams on 16 Feb 2010 16:31
"GS" <GS(a)discussions.microsoft.com> wrote in message news:uPWzP30rKHA.5568(a)TK2MSFTNGP05.phx.gbl... > Webbiz used his keyboard to write : >> On Tue, 16 Feb 2010 00:06:04 -0500, GS <GS(a)discussions.microsoft.com> >> wrote: >> >>> Webbiz explained on 2/15/2010 : >>>> On Fri, 12 Feb 2010 08:44:40 -0600, "Larry Serflaten" >>>> <serflaten(a)usinternet.com> wrote: >>>> >>>>> >>>>> "Webbiz" <nospam(a)noway.com> wrote >>>>>> Suppose you have a VB6 application that is already completed, but you >>>>>> want to now add new functionality by way of ADD ONS that are >>>>>> purchased >>>>>> separately. >>>>> >>>>>> ... When purchased and properly installed, it shows up under the >>>>>> ADDON >>>>>> menu that the user can now select and it will do its thing. >>>>>> Suggestions, pointers, etc. would be appreciated. >>>>> >>>>> >>>>> Its rather interesting that you've completed the app, yet gave it an >>>>> ADDON >>>>> menu item, without fully defining how that menu item will be used.... >>>>> >>>>> As some have already stated, something like that should be included in >>>>> the initial design. Are you saying you can alter the source code to >>>>> 'retrofit' the new capability? Or are you only able to work with an >>>>> application that has already been shipped? >>>>> >>>>> The other aspect that needs further detailing is your idea of what a >>>>> 'module' is. If you have (for example) a music player and you now >>>>> want it to play video, then that's a major UI change, isn't it? >>>>> >>>>> Take a look at VB's own Add-In manager, and the types of things >>>>> it adds in. Is that about what your after? >>>>> >>>>> LFS >>>> >>>> >>>> I didn't say that my completed app had a menu item for ADD ON's. I was >>>> saying that I have a completed app that I 'now' would like to give it >>>> the ability to add new features, sold separately. >>>> >>>> The solution I most favor at this point is to simply add the ability >>>> to the application and have it deactivated. If purchased, the user can >>>> purchase the new key. >>>> >>>> This would work well for me as I already know how to add new >>>> functionality to my apps and can easily adapt my app to unlock >>>> features based on 'codes' or 'keys'. >>>> >>>> Thanks! >>>> >>>> Webbiz >>> >>> <Built-in> >>> What you're saying here now is that your intention is to make app levels >>> similar to how others issue app editions. (i.e.: Standard, Professional, >>> Enterprise...) This concept usually precludes that all features and >>> functionality are shipped and installed, with specific features and >>> functionality only made available if the right level of 'license key' is >>> entered by the user. This is trivial to achieve, as you state here, only >>> if you use a good licensing methodology. Adapting your apps to implement >>> this could be as simple as hiding the menus that access the extra >>> features, and unhiding them after the correct 'key' is entered. Of >>> course, it could also be more complex than that depending on how your >>> app is designed and coded. >>> >>> If you employ the 'try it before you buy it' concept, usually the app >>> runs in 'trial' mode for a given period of time or number of executions >>> during which all features and functionality are available for evaluation >>> purposes. The user can then decide what 'edition' to purchase based on >>> having full use during the trial period. In this case, having the >>> features built into the app from the start makes sense. >>> </Built-in> >>> >>> <Add-ons> >>> The concept of 'Addons' as commonly used by many software products is >>> quite different, and typically refers external apps or components (or as >>> you stated: 'modules') that would be shipped separately to extend >>> features and functionality of an already finished app. This is what I'd >>> be interested in doing with VB6 because it allows me an opportunity to >>> give clients added functionality that directly pertains to their >>> specific needs while using my apps, and allows the client to customize >>> what they can do with my app beyond the standard features. For example, >>> it's common for users to want data exported to their accounting software >>> or database. Since not everyone uses the same accounting software or >>> database it precludes that building this into the app doesn't make >>> sense. I don't mean generic data export; what I mean is user-defined >>> details that are unique only to that user. Generic requests can usually >>> be added to the core app as an update/upgrade feature, and is usually >>> how it's handled if several users make the same or similar request. >>> >>> <IMO> This approach should also employ the 'try it before you buy it' >>> concept because if your user doesn't like what he buys from you then how >>> do you handle refunding him and making sure the addon isn't used any >>> longer? >>> </Add-ons> >>> >>> Since you expect to get paid for the extras, you need to have a >>> methodology in place that ensures you get paid for every install. This >>> is determined by the scope of the 'unlock key'; --How many machines can >>> it be used on (i.e.: is it locked to the user, the app, or to a specific >>> machine)? Simple licensing schemes don't offer much security or >>> flexibility. Even the schemes that use private/public key cryptography >>> are only as good as the bit strength of the keys. The higher the better, >>> but nothing is 'bullit proof'. Some of the highest bit strength >>> methodologies may take years to decrypt based on today's computing >>> power, but I don't think this matters since most users wouldn't bother >>> to crack your keys unless the benefit is well worthwhile. So unless your >>> app involves national security stuff or the like, it's reasonable to >>> assume you're probably going to get paid for every extra. >>> >>> Kind regards, >>> Garry >>> >> >> >> All my applications are niche products sold to those who are already >> aware of what they can do for them. At this time, there is no 'try >> before buy' scenario. >> >> In the case of the 'charting' program, as with the other apps, these >> are all 'protected' using protection software that requires a 'key' to >> unlock the application to a specific computer or to simply unlock the >> application on any system. Depends on the app. I've been using the >> protection scheme for over 10 years now successfully. >> >> Recently, I had provided users of one of my apps the option to >> 'unlock' a special module already built into the program if they met >> certain requirements (ex: attend a special webinar, for example). So >> for those who met the requirement, they got a 'key' that unlocked the >> module that was already domant within their app they possessed on >> their machine. >> >> So this is why I said I was already 'familiar' with this approach. >> >> The thing about this approach, however, is that I would have to update >> the main core app each time to add something, and then the user would >> have to download the new updated app first before unlocking with a new >> special 'key'. >> >> My preferred method would be to leave the original app alone and >> simply sell new code modules that can be downloaded and used by the >> original core app. The program would likely have to then use multiple >> keys, where each key adds an additional feature sold separately. This >> way, users can just add what they want. >> >> From reading the replies to this thread, I was not able to come away >> with a 'clear' idea as to how one would do this. Some say write a >> 'dll' for each and others say "don't do it!". As a novice programmer >> (most of you here are so way over my head in techno speak, LOL), I >> would need a clear 'path' to take in order to go the 'preferred' route >> of separate modules. >> >> Meanwhile, I can impliment these new modules within the core app and >> produce keys that unlock 'levels' within the code. This is provided by >> the protection software I have been using these past 10 years. It >> provides the means to activate and deactivate code segments within app >> by providing custom 'keys'. >> >> >> If I could just focus on new modules that could be absorbed by the >> original core app when purchased, that would be my preferred way to >> go. But until it is clear in my head how I'm supposed to do something >> like this with VB6, it appears my only solution is to just add it to >> the core app and 'mark' those sections for activation by 'key'. >> >> Thanks! >> >> Webbiz > > Thanks for the feedback! Don't mention it ;-) |