Re: Visual Basic for Autorun?
From: J French (erewhon_at_nowhere.com)
Date: 06/08/04
- Next message: J French: "Re: Visual Basic for Autorun?"
- Previous message: Michael Cole: "Re: SQL SELECT"
- In reply to: Michael Culley: "Re: Visual Basic for Autorun?"
- Next in thread: Michael Culley: "Re: Visual Basic for Autorun?"
- Reply: Michael Culley: "Re: Visual Basic for Autorun?"
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 8 Jun 2004 08:38:16 +0000 (UTC)
On Tue, 8 Jun 2004 16:11:44 +1000, "Michael Culley"
<mculley@NOSPAMoptushome.com.au> wrote:
>"J French" <erewhon@nowhere.com> wrote in message news:40c542bc.78643818@news.btclick.com...
>> Why more professional ?
>
>Take as an example a grid I wrote for one project.
Been there - very useful
>Time was set aside to write it and it was tested on its own and once it reached a
>certain state it was compiled and used in the main app. It reached a point where it was sealed and delivered. Changes still happen
>ocassionally but it is much more controlled. Now several apps use the same grid and it is impossible for developers to make sly mods
>to suit their application. If changes are required they can't be specific to one app.
Realistically the point is preventing other coders mucking things up
- it is a valid point
- but there is nothing to stop them mucking up the OCX
- assuming they can get into version control
>The alternative would be to copy the code from
>project to project and not really be sure of the changes made to each. Obviously this doesn't apply to all usercontrols and should
>only be used where appropriate, but even when usercontrols are very specific to a project I create a seperate ocx project that will
>only be used by the one exe.
I generally make another (local) copy of a UserControl and work on
that while enhancing a 'library' UC
It only goes into the 'library area' when I am sure of it
>
>Here's a few other reasons:
>If a programmer passes in an invalid parameter to my dll/ocx then I can raise an error and it breaks on their line of code, not
>mine.
True - I tend to prefer a simple MsgBox
- that goes back to writing library code well before Windows
>If their app closes due to an error the control still shuts down correctly. This basically means class_terminate fires so resources
>can be tidied up.
You mean at run time
>Extender properties (top, left etc) are not always available if the control is in the exe.
Circumstances ?
>Version tracking is easier, eg I can tell that my grid was updated on a certain date and that the last 3 versions of my app used the
>one version of the grid.
That is true - a major plus
>IDE runs quicker which is vital for larger projects. The one I'm working on now has 300 forms and is slow enough as it is. I have 2
>projects loaded into the IDE usually, I can't imagine how slow it would be if the code from its 11 projects was all loaded at once.
It would not necessarily be the code from 11 projects
>Friend functions. This on it's own is enough of an arguement :-)
True
>Class scope. You can define a class as private or public not createable. The second means it can only be created from within your
>dll, so you can specify a function has to be called to create an instance of your class. This is a bit like contructors in more of
>an oop language. Marking a class as private makes it possible for me to use it to support a public class/control without it being
>visible to the outside world.
Yes - private Classes - Scope is a PITA in VB
>Usercontrols don't get those diagonal stripes on them when you modify the project.
Those can be unsettling at first - now I just keep punching Ctl F4
>Functions can be marked as hidden.
Not sure about that one - that may be a VB6 enhancement
>> I most certainly know /how/ to work with them, I simply do not like
>> working with them.
>
>OK, that wasn't really a fair statement of mine. On occasions ActiveX dll/ocxs can cause problems but they are usually fairly easy
>to get around. Maybe you didn't persist with them enough to get around the problems.
I did not have the motivation
>> Where I need DLLs for complex things used by many different EXEs then
>> I use Delphi.
>
>Personally I would think this is not a very good solution. I presume you need to use declare statements and have to know the names
>of the functions. With activeX you just add a reference and can see all the functions. Intellisense works and you can raise errors
>in the dll to be caught in the exe. Also, everything is in the one language. Generally I only use a second language if there is a
>really good reason and that's usually C because the main language couldn't do what C can.
Yes, you need the declare statements, often I wrap them in a
mini-Class - you get the Intellisense Ok
True one has to have the Declares, but with AX you need the Type Libs
Personally I like Delphi as a second language, it is a bit like VB on
steroids.
When writing Delphi DLLs I know that I am going into 'Tiger Country'
- and am extra careful, as I am aware that any stupidity on my part
will be hard to trace from the main App
>> But that is not very important nowadays.
>
>I agree, that's why we stopped doing it.
Sensible - a bit like not relying on incremental backups
>> So far I have only heard of one compelling reason for converting
>> UserControls into OCXes
>> - which was to prevent junior programmers tampering with the code
>
>Not just the junior programmers :-) At least with the juniors you can tell them off, the seniors have a tendancy to tell you to piss
>off :-)
How do you stop them just checking out the OCX's source
- years ago in another environment we came up with a solution
- each library module had an 'owner' (author) and a 'co-owner'
- so only two people were permitted to make mods
(everyone could see and play with the code, but if they altered the
library version then they were dead)
>> I am intrigued why you think it 'professional' to turn UserControls
>> into OCXes - personally I consider it slightly dangerous.
>
>I've done it fairly extensively and it works quite well as long as you keep good control over it. I just like they way that the
>control is encapsulated into a neat little project with good control over how developers can use it.
Ok, I can see that in your environment control is extremely important
- so that you are willing to put up with the annoyances
- and have probably put in some layers of automation
Quite a lot of my UserControls are also used by another software
house, and they /are/ OCXed by them - for most of the reasons you give
(their boss - who once worked for me - is quite rightly a control
freak)
There are other aspects though, like you I tend to develop
UserControls as part of the App, they are great for 'encapsulation'
Some of those eventually turn into 'generics' but many don't.
Even with things that may become 'generics' I'm developing them in
conjunction with the App, so having them as part of the Project is
very convenient.
One can quickly add properties and functionality and tracing is much
easier.
Often the App specific UCs are so much part of the App, that to have
them separately compiled would be a PITA
Once a UC has been promoted to the status of 'generic' it gets its own
location and Testbed. I then regard it as a .OBJ file.
Heck - I'm sure MS could have done a better job
- the Registry is such a fragile construct
- Next message: J French: "Re: Visual Basic for Autorun?"
- Previous message: Michael Cole: "Re: SQL SELECT"
- In reply to: Michael Culley: "Re: Visual Basic for Autorun?"
- Next in thread: Michael Culley: "Re: Visual Basic for Autorun?"
- Reply: Michael Culley: "Re: Visual Basic for Autorun?"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
