Creating ADD ONS
in [Visual Basic]
|
From: Webbiz on 25 Feb 2010 02:14 On Tue, 16 Feb 2010 16:20:04 -0500, GS <GS(a)discussions.microsoft.com> wrote: Replies within... >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's all relative, really. I've been programming since 1973 when I learned COBOL at McDonnell Douglas Aircraft Co. By 1977, had programmed in BASIC, RPG, RPGII, Assembly and Fortran. Even programmed in pure machine language while working on mainframes for Sperry Univac during the late 70's. During the 80's I merged into C, then C++, then Delphi/Pascal only to switch to VB3 during the early 90's. Since then, it's been VB4, 5 and now 6. I'm trying to learn C#.net with the 'dummy' book, but haven't coded anything yet. And after all that, I still ain't more than a novice, wet behind the ears programmer. This is because I do just enough to solve a need and then get back to what I'm paid for, which is not programming. It's something I do on the side with spare time if any. Thus, you guys are just way over my head in VB6 programming. Without a lot of folks here I'd be stuck in the mud. > It sounds like you >DO want to implement Addons as independent components, though. Olaf >raises some good points. Because you understood what he was suggesting, this tells me your experience trumps mine. :-) >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. This is what I'd "like" to do. Just not sure how I'd go about it though. So if you succeed, perhaps you can post something. > >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. It's Software Passport. I can create multiple keys, but I don't need to issue multiple keys. A single key can be for just the core app, and another can be for the core and a specific function(s). > 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. Don't laugh, but I've never written a DLL. Ever. Yes, I've added DLLs to my apps and declared them, but never have actually created one of my own. Perhaps it is time I get out of my comfort zone and write a small one or two. > 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.
From: Webbiz on 25 Feb 2010 02:16 On Tue, 16 Feb 2010 14:56:32 -0600, "Larry Serflaten" <serflaten(a)usinternet.com> wrote: > >"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??? Where it would be is on the menu bar of the main app ONLY if the user purchased an ADDON. In other words, the main app should be able to detect that there is an ADDON installed on the machine and link to it, creating the menu items needed to use it. That was my thought. > > >> 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> Yeah. But look what happened to Rome. LOL. > >Good luck! >LFS > Thx.
From: David Kerber on 25 Feb 2010 16:06
In article <uq8co55begsgjlbnsj6e6llca6tltdie0v(a)4ax.com>, nospam(a)noway.com says... .... > >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> > > Yeah. But look what happened to Rome. LOL. But it took a loooooooong time!! D |