Creating ADD ONS
in [Visual Basic]
|
From: Larry Serflaten on 13 Feb 2010 20:16 "GS" <GS(a)discussions.microsoft.com> wrote > The major issue for me will be how to get the plugin menus working > seamlessly within the core app. Menus can be loaded dynamically, as part of a (menu) control array. If you notice, the Windows menu in the VB IDE will add a new menu item for every form you add to a project. You can get that same response by dynamically adding menu items just as you would dynamically add other controls using the Load command. From there, what you do when the item is selected can get to be a bit tricky. To ease the effort in my ealier project, I put each task (function or routine) in a separate class that exposed an Execute method. That way once I got the object, to get it to work, all I need to do is call its Execute method. But, some required parameters, and the main app needed to know what to pass for the parameters. And so on, the details were all worked out, so that the main app did not need to know anything about what the add-on did because the Info class would tell it what to pass in (if anything) for it to do its job. I must have been on an interface kick, because I seem to recall that the add-on implemented an 'Executive' interface whose sole purpose was to expose the Execute method. IIRC, that method used a single collection as a parameter so that any number of arguments could be passed to any of the add-ons. I used interfaces because (I thought) that would lock in the communication between the app and the add-ons such that all the add-ons could be treated in exactly the same way. What worked for one add-on (in the main app) worked for them all, so the actual app code was kept to a minimum. In any case, as was mentioned earlier, the details need to be worked out from the initial design so that the main app can be given the correct code to utilize the add-ons. Good luck! LFS
From: GS on 13 Feb 2010 22:20 I knew that menus could be added dynamically but I've never done this. My approach would be to have the addon do this in its Class_Initialize event, if that's doable. Having separate classes for each menu could get burdensome. I was thinking to have my host app make a call to the DLL and pass the control index as a parameter. That way, it doesn't need to know anything other than what menuitem was clicked. The DLL will redirect based on the index passed in. This is similar to how I handle passing menu clicks from Excel to a common procedure in my VB6 COMAddins. What's different there is I can store the procedure name in the Tag property and pass parameters from the Parameter property. The COMAddin then passes the procedure parameters, if any, to a global variable and uses CallByName() to execute the procedure. The procedure, in turn, reads its parameters from the global variable. Unfortunately, VB6 menus don't support either of these properties so it makes for needing a different methodology. I'm thinking, then, that passing the control index to a common procedure (class method) in the DLL might be a simpler solution, then just redirect flow from there using a Select Case structure. Any params could retrieved from the core app (-OR- determined in the Select Case structure) based on index passed, and stored in a global variable inside the DLL before flow redirection occurs. This then would closely resemble the methodology I currently use for VB6 COMAddins, thus offering some consistency to my project management duties. Do you think this is doable? Can you foresee any pitfalls I might encounter? Kind regards, Garry
From: Webbiz on 15 Feb 2010 21:57 On Fri, 12 Feb 2010 13:49:31 +0100, "Henning" <computer_hero(a)coldmail.com> wrote: > >"Webbiz" <nospam(a)noway.com> skrev i meddelandet >news:6jq9n5131mbqvq03htf378bqdrlca13b7g(a)4ax.com... >> 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. >> >> What is the direction one would take to do this? >> >> For example, say you have a stock charting program and you want to >> make available various 'modules' that a user can purchase. When >> purchased and properly installed, it shows up under the ADDON menu >> that the user can now select and it will do its thing. >> >> This would be the first time I've tried to do something like this and >> I'm not sure what the approach is. >> >> Suggestions, pointers, etc. would be appreciated. >> >> TIA >> >> Webbiz > >As a lot of others, ship the complete app with parts of it disabled if not >activated by a new key. > >/Henning > Ah, now this is something even a simpleton like me can do! Thanks! Webbiz
From: Webbiz on 15 Feb 2010 22:02 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
From: GS on 16 Feb 2010 00:06
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 |