[RESOLVED] Registered as apposed to Unregistered UCs

[cheesebrother]

I've been wondering about how usercontrol's work. When you have a usercontrol compiled as an .ocx you need to make a special install to use your program on another computer. Another way you can use usercontrol's is to attach it to your project, uncompliled. What I would like to know is, what's the difference? One that I like is that you DON'T need to register UCs that are just added to the project. You can put your program on another pc and it works fine. But that is just a small matter of preference.

What are the pros and cons for registered and attached usercontrols?

[LaVolpe]

Here is a nearly identical thread two weeks ago

[Magic Ink]

In terms of how an app runs I expect there is little to choose in either method if the uc is serving a single exe. However if the uc serves more than one exe then all dependent exes can be more easily be 'upgraded' (without changing/ reinstalling them) by installation of a new version of the uc's ocx.

[LaVolpe]

However if the uc serves more than one exe then all dependent exes can be more easily be 'upgraded' (without changing/ reinstalling them) by installation of a new version of the uc's ocx.

Yep. Bottom line in my opinion: If it is to be used for a single application only, no need to make it an external ocx. However, if you plan on using it in future applications, make it external and by all means, enable binary compatibility for future revisions of the ocx

[dilettante]

Even if you make controls and classes that will only be used in one program there are a several reasons to write and compile them as DLLs (and OCXs).

Some include:

• Breaking up a large program into smaller parts that can be worked on separately to avoid the extra effort complexity brings.
• Breaking up a large program into smaller parts that can be worked on by different people easily, sharing the development load more easily among multiple programmers.
• Breaking up a large program into smaller parts that can be compiled in pieces, avoiding long recompilation times and "program too large" failures.
• Enabling subsequent sharing across multiple programs when you later realize you also need a "batch" maintenance utility, need to spawn a second process for an elevated function, or need to write another program based on many of the same things. In many cases leaves you with classes you can re-use in scripts or VBA.
• Making modular updating possible (mentioned by others already).
• Encouraging "re-use" development discipline and better quality programming by making you more conscious about defining your interfaces and object models and implementing encapsulation instead of raggedy coding relying on a lot of Public data in static modules. Helps avoid the dead-end of "ad hoc" design.

Many of these may seem theoretical - until you need them. Then you wish you had not been so monolithic about your programming and you'll suffer the frustration of having to unlearn old habits on the fly while you ought to be free to concentrate on the problem at hand.

[cheesebrother]

Ok, thanks for all your help.

Yep. Bottom line in my opinion: If it is to be used for a single application only, no need to make it an external ocx. However, if you plan on using it in future applications, make it external and by all means, enable binary compatibility for future revisions of the ocx

That seems to be the basic thing. Was curious as to what the advantages are. Now i am enlightened.

[dilettante]

That seems to be the basic thing. Was curious as to what the advantages are. Now i am enlightened.

While I agree with what LaVolpe said, that isn't the thing you should really take away from this discussion. Don't forget all of those other points already made.

As I tried to point out, not working with separately compiled DLLs and OCXs of your own means you are likely to reinforce some really poor programming habits. And without cultivating the discipline you'll doom yourself in the long run - so there is a vicious circle there that handicaps your development as a VB programmer.


Another point nobody mentioned is that separately-compiled libraries offers a way to share your work without giving away all of your effort by distributing source code. This becomes more important when you do enough work to provide a library worth enough to people to justify charging money.


Sadly the way the CodeBank here works discourages doing things "right." I.e. there is no way to provide working code (whether a whole utility or a library) without providing the source. So on the one hand people think "Why bother making a robust component library of commercial quality to give away, because I have to hand over my source? I'll just slap it together as an in-lined Class or UserControl module." Or on the other hand "I put a lot of work into this to do it well, why post it for people to use for free? I'll just post it where I can ask for some money for it instead."

Lots of my better stuff will never end up here for that reason. Probably others' as well.

But the worst impact is that the site offers no incentive to "do things right" or even to discuss how to "do things right."

The kinds of issues that fall by the wayside include: proper use of encapsulation, using design-time and run-time licensing, and packaging libraries for developer installation and use. This is really a bit of educational mission failure for the site and for the users - both losing an opportunity.

[LaVolpe]

dilettante makes some good points, but I think they will fall on mostly deaf ears for following reasons

1) Distribution. For whatever reasons, there are too many coders out there that are opposed to distributing a dll/ocx with their program. Personally, I don't get that. I'm sure for some, there are malicious reasons but for the most part, is it just because they don't want to build a proper distribution package, i.e., setup.exe? Rhetorical question.

2) Sharing code on sites that prevent binaries from being uploaded. I've seen this time and again and have fallen victim to it also. Pride may be a player here. If you write something that you think is cool or great and even somewhat advanced, odds are you will scare away others if your project contains a module or two, a few classes, a property page, and other stuff. So how do you make your newest widget, a token of your perceived genius, available? Early in my programming life, sites like this and PSC have visitor and download counts. The higher the count, the more people are interested in your code, the more gratified you may feel. But if you can get it to a single user control file that someone can simply add into their exe project and not require additional dependencies, then you attract more people. Most likely, these people we are attracting are in the novice category as they would be the more likely to be scared off by larger projects. I used to pay attention to the "download count" game too; now I don't care whether my projects get 100 downloads or 100,000.

3) Experience of the coder. Let's face it, when we all started off with programming, we were probably put off by the idea of using classes and custom user controls because we didn't understand them. So when we first began playing with them, what did we do? Did we create our first dll and ocx right away? Nope. We designed classes that, at best, could be re-used or a user control that we could re-use inside of an exe project. Only later on did we feel comfortable enough to begin challenging DLL hell and create external dependencies. As you mentioned, the bad habits were already developed.

For those that fully understand your points, they are already experienced coders I would think.