Design Time vs Run Time 
Author Message
 Design Time vs Run Time

I am taking a VB class at U.Texas Arlington.  Some VP professors allow
students to set all attributes at design time (properties window). Mine on
the otherhand only allows us to set limited attributes at design time and
all others at runtime, creates some fairly cryptic coding for database
controls ,we are focusing on the ado's.  I was wondering it there is any
real world advantage to runtime attribute setting or if most real world
programming is done at design time whenever possible.  ( I must say VB is
quite {*filter*}ing )

Dan Magee
danmagee at ticnet dot com
antispam measures are in place!



Sun, 20 Apr 2003 11:41:43 GMT  
 Design Time vs Run Time
The curious thing about programming in a Compiled language, is that
you land up writing a form of Interpreter.

The advantages of parameterization, either from within the code or
from INI  (or any other) files, generally far outweigh the advantages
of designing 'on screen'.  

You eliminate repetitive code, you can add/modify things without
recompiling, alignment becomes 'logical'. And the code becomes
reusable.

On Tue, 31 Oct 2000 21:41:43 -0600, "Daniel Magee"

Quote:

>I am taking a VB class at U.Texas Arlington.  Some VP professors allow
>students to set all attributes at design time (properties window). Mine on
>the otherhand only allows us to set limited attributes at design time and
>all others at runtime, creates some fairly cryptic coding for database
>controls ,we are focusing on the ado's.  I was wondering it there is any
>real world advantage to runtime attribute setting or if most real world
>programming is done at design time whenever possible.  ( I must say VB is
>quite {*filter*}ing )

>Dan Magee
>danmagee at ticnet dot com
>antispam measures are in place!



Sun, 20 Apr 2003 16:12:58 GMT  
 Design Time vs Run Time
But, there are quite a number of things that there's never any need to
change that can quite reasonably be set at design time. It's all a
matter of applying good business judgement... you speed and ease
development (to a lesser or greater extent) by setting properties at
design time; you increase the flexibility and reusability (and perhaps
the usability/user friendliness) by setting them at runtime, either
from a public or private INI, or other record of user's options. It's a
tradeoff that should be taken into account. Neither approach is always
right or always wrong.

AAMOF, after being in the computer business since 1958, one of the
primary lessons I've learned and had reinforced time after time, is
that very few approaches, methods, or techniques is always right or
always wrong. And, I've learned to be wary of those who are so obsessed
with some approach, method, or technique that they claim loudly and
longly that it IS always right.

Notice I did not mention using The Registry. It is, IMNSHO, an evil and
an abomination, a work of the Dark Side of The Force, and possibly an
indication that malevolent alien beings inhabited some architects and
designers in Redmond. Microsoft may have realized this, as well...
insider scoop says they don't use the Registry in the .NET world. I
have also heard that the _majority_ of support calls that Microsoft
receives these days turn out to be Registry problems of one kind or
another. Now, you should be a little wary of me, or at least of my rant
on this subject. <G>

Quote:

> The curious thing about programming in a Compiled language, is that
> you land up writing a form of Interpreter.

> The advantages of parameterization, either from within the code or
> from INI  (or any other) files, generally far outweigh the advantages
> of designing 'on screen'.

> You eliminate repetitive code, you can add/modify things without
> recompiling, alignment becomes 'logical'. And the code becomes
> reusable.

> On Tue, 31 Oct 2000 21:41:43 -0600, "Daniel Magee"

> >I am taking a VB class at U.Texas Arlington.  Some VP professors
allow
> >students to set all attributes at design time (properties window).
Mine on
> >the otherhand only allows us to set limited attributes at design
time and
> >all others at runtime, creates some fairly cryptic coding for
database
> >controls ,we are focusing on the ado's.  I was wondering it there is
any
> >real world advantage to runtime attribute setting or if most real
world
> >programming is done at design time whenever possible.  ( I must say
VB is
> >quite {*filter*}ing )

> >Dan Magee
> >danmagee at ticnet dot com
> >antispam measures are in place!

--
 L. M. (Larry) Linson
  http://www.*-*-*.com/ - North Texas PC User Group - Visit and Join
  http://www.*-*-*.com/ - NTPCUG Developer SIGs
  http://www.*-*-*.com/

Sent via Deja.com http://www.*-*-*.com/
Before you buy.



Mon, 21 Apr 2003 01:28:21 GMT  
 Design Time vs Run Time

Quote:
> I am taking a VB class at U.Texas Arlington.  Some VP professors allow
> students to set all attributes at design time (properties window). Mine on
> the otherhand only allows us to set limited attributes at design time and
> all others at runtime, creates some fairly cryptic coding for database
> controls ,we are focusing on the ado's.  I was wondering it there is any
> real world advantage to runtime attribute setting or if most real world
> programming is done at design time whenever possible.  ( I must say VB is
> quite {*filter*}ing )

I think your professor is right in forcing you to learn it the way you are.
You aren't likely, from my experience, to be using controls for DB access
anyway when it comes down to it, so you will benefit from focusing on how to
do it at runtime.  I'm guessing he allows you to set properties that are
commonly set at design time that way, while insisting that you set others
that are often set at runtime that way.
You get to learn both, which is to your benefit.

--
"Fear is the start of wisdom."
-Miguel de Unamuno



Mon, 21 Apr 2003 03:18:50 GMT  
 Design Time vs Run Time
LMAO Larry!  You are too funny but I agree 100% with 100% of what you said!

Kim


Quote:
> But, there are quite a number of things that there's never any need to
> change that can quite reasonably be set at design time. It's all a
> matter of applying good business judgement... you speed and ease
> development (to a lesser or greater extent) by setting properties at
> design time; you increase the flexibility and reusability (and perhaps
> the usability/user friendliness) by setting them at runtime, either
> from a public or private INI, or other record of user's options. It's a
> tradeoff that should be taken into account. Neither approach is always
> right or always wrong.

> AAMOF, after being in the computer business since 1958, one of the
> primary lessons I've learned and had reinforced time after time, is
> that very few approaches, methods, or techniques is always right or
> always wrong. And, I've learned to be wary of those who are so obsessed
> with some approach, method, or technique that they claim loudly and
> longly that it IS always right.

> Notice I did not mention using The Registry. It is, IMNSHO, an evil and
> an abomination, a work of the Dark Side of The Force, and possibly an
> indication that malevolent alien beings inhabited some architects and
> designers in Redmond. Microsoft may have realized this, as well...
> insider scoop says they don't use the Registry in the .NET world. I
> have also heard that the _majority_ of support calls that Microsoft
> receives these days turn out to be Registry problems of one kind or
> another. Now, you should be a little wary of me, or at least of my rant
> on this subject. <G>


> > The curious thing about programming in a Compiled language, is that
> > you land up writing a form of Interpreter.

> > The advantages of parameterization, either from within the code or
> > from INI  (or any other) files, generally far outweigh the advantages
> > of designing 'on screen'.

> > You eliminate repetitive code, you can add/modify things without
> > recompiling, alignment becomes 'logical'. And the code becomes
> > reusable.

> > On Tue, 31 Oct 2000 21:41:43 -0600, "Daniel Magee"

> > >I am taking a VB class at U.Texas Arlington.  Some VP professors
> allow
> > >students to set all attributes at design time (properties window).
> Mine on
> > >the otherhand only allows us to set limited attributes at design
> time and
> > >all others at runtime, creates some fairly cryptic coding for
> database
> > >controls ,we are focusing on the ado's.  I was wondering it there is
> any
> > >real world advantage to runtime attribute setting or if most real
> world
> > >programming is done at design time whenever possible.  ( I must say
> VB is
> > >quite {*filter*}ing )

> > >Dan Magee
> > >danmagee at ticnet dot com
> > >antispam measures are in place!

> --
>  L. M. (Larry) Linson
>   http://www.*-*-*.com/ - North Texas PC User Group - Visit and Join
>   http://www.*-*-*.com/ - NTPCUG Developer SIGs
>   http://www.*-*-*.com/

> Sent via Deja.com http://www.*-*-*.com/
> Before you buy.



Mon, 21 Apr 2003 04:00:44 GMT  
 Design Time vs Run Time

Quote:


<cut>
> > Notice I did not mention using The Registry. It is, IMNSHO, an evil
and
> > an abomination, a work of the Dark Side of The Force, and possibly
an
> > indication that malevolent alien beings inhabited some architects
and
> > designers in Redmond.

<cut>

But how do you really feel? <g>

IMHO, you are too forgiving of the registry.  There's a good idea under
there somewhere but it's a horrible immplementation.

--
Please reply via the newsgroup only

Sent via Deja.com http://www.deja.com/
Before you buy.



Mon, 21 Apr 2003 05:09:47 GMT  
 Design Time vs Run Time


<SNIP>

Quote:

>Notice I did not mention using The Registry. It is, IMNSHO, an evil and
>an abomination, a work of the Dark Side of The Force, and possibly an
>indication that malevolent alien beings inhabited some architects and
>designers in Redmond. Microsoft may have realized this, as well...
>insider scoop says they don't use the Registry in the .NET world. I
>have also heard that the _majority_ of support calls that Microsoft
>receives these days turn out to be Registry problems of one kind or
>another. Now, you should be a little wary of me, or at least of my rant
>on this subject. <G>

</SNIP>

Mark Twain said :

 "Some people say : don't put all your eggs in one basket - but I say
put them in one basket and watch that darn basket"

Well Micosoft really screwed it with the registry - if, in their
wisdom, they must decide to use such a crass approach, they could at
least have ring fenced it and made at least a token effort to 'ring
fence' it - instead of the shoddy, opaque, unreliable, unmaintainable
piece of scheit that they produced.

And then they say that you might not be able to use the Win9x logo if
you use INI files insttead of the registry ..... cretins !



Mon, 21 Apr 2003 16:31:11 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. web service and updating web reference with vb.net design time vs run time

2. web service and updating web reference with vb.net design time vs run time

3. Design time vs Run time

4. Run Time vs Design Time - No Current Record

5. Design time vs. Run time

6. Assign a treeview at design run time to other at design time

7. Code running in design time or run-time?

8. ADO data control Design -vs- Run Time

9. Paint Event different design vs run-time?

10. getting run-time behavior of a contained control in a user control at design time

11. MsgBox pauses App at Design time but not run time

12. design-time functionality at run-time

 

 
Powered by phpBB® Forum Software