Impact on execution speed and application size from modules and func.. 3

[rickyoswaldiow]

Good afternoon everybody.
Today I am working on some project design work. I am reverse-engineering parts of an application that have been built in VBA. I have all of the technical information required for the project but I am wondering; If I go for a highly modularised design using many functions, often to call just half a dozen lines of code, will there be a high impact on application size and execution speed?

As I understand it, the application size will increase as I add more modules. The execution speed will NOT decrease as functions are a human concept and a way of helping us build programs - the computer reads it the same way after compilation. Is this true?

 

[three57m]

<Is there a way for a control to reference it's own name>


I do this to reference controls quickly

'I place this in a module

Public MyRTB As RichTextBox

'Then I place this in the form code

Private Sub Form_Load()
	Set MyRTB = RichTextBox1
End Sub

In this way I can now reference the MyRTB from anywhere
in my program with without needing to type: Form1.RichTextBox1.Text.
This example assumes that the form load event in which you set
the value of MyRTB is the first loading form or "Sub Main

 

[tedsmith]

three57m, do you know if doing this, when the app is compiled,
will make a program runs slower or not or use more memory?

I would suspect it would because you have 2 ways of describing the control. If it gets compiled to the same code then I suppose it would be the same but if there is an intermediate translating step, it could take longer.

 

[rickyoswaldiow]

I can see what you're saying three57m but that is not really what I was looking for. What you describe is setting up a variable for every control - not really viable when you have hundreds of controls... What I am looking to do is somthing along these lines:

Sub Control_Change()
   intArray = intArray + 1
   strArray(intArray) = [Control Name]

End Sub

 

[tedsmith]

If you had 3 text boxes called Name, Age and Sex on a MyForm
For a=0 to (MyForm.Controls.Count-1)
strArray(a)=MyForm.Controls(a).name
Next

strArray(1) would contain "Age" and so on through all the controls on the form

If you have controls with the same name, they will all show the same name so you have to use the MyForm.Controls(a).Index to get their index to differentiate between them.

 

[rickyoswaldiow]

tedsmith: When you run that block of code, the array would instantly be populated with every control on the form?

What I want is for an individual control to add itself to an array on its own change event...

 

[rickyoswaldiow]

Since this has wandered off from the original topic, I am going to make a new post...

 

[strongm]

> runs slower or not or use more memory? I would suspect it

Although best practice suggests that the use of global variables should be avoided where possible for a vaiety of reasons, you don't need to worry in this case about it slowing anything down. All we've done is add another pointer to an object. VB doesn't hold any object whatsoever; the only overhead is 4 bytes for the new pointer.

I'm not even going to begin to comment on the interesting view that VB was a backward step from previous versions of BASIC, or that is only good as a training tool, or that idea monolithic programming is the best way to do things.

But just for the heck of it, here's one bit of feedback:

Another convention I hate is
txtName.txt = strDfm 'Default family name
It only muddles the code text in the editor and makes some items look the same
Easier to understand if you have with my system using long real words.
EntryBox(Index).txt = DefaultFamilyName 'the comments are virtually unnecessary unless it has to be also in 2 boxes

Like many of your apparant criticisms of VB as a language, this is more a criticism of style than the language itself. Adopting a different style can bring bigger improvements. For example:

txtDefaultFamilyName.txt=strDfm

is at least as clear as your

EntryBox(Index).txt = DefaultFamilyName

but with the advantage that if I come to modify my code later on I can directly and immediately see from the name what the control is holding. I can't do that with your version at all; I'd have to search through the code to see what was first assigned.

 

[BobRodes]

<txtDefaultFamilyName.txt=strDfm
<EntryBox(Index).txt = DefaultFamilyName

Dare I observe that neither of these lines of code would compile?

 

[BobRodes]

<I update the database on each item if the data has changed at the point you leave that control

Not me, I believe a record update should be atomic. Furthermore, I've found that users in general prefer to look over the entire record before deciding to commit changes. There may be exceptions to this, of course.

 

[strongm]

>neither of these lines of code would compile?

That's what comes of typing examples rapidly into tek-tips without passing them through VB for a sanity/syntax check first ...

 

[BobRodes]

It's Ted's fault, he started it.

 

[strongm]

<heh>

 

[tedsmith]

rickyoswaldiow whats wrong with just using the controls name?
Sub Text1_Change()
intArray = intArray + 1
strArray(intArray) = text1.name
End Sub

Yes I looked at txtDefaultFamilyName.txt=strDfm for a long time and had to put it in a project and run it before I realised what the trouble was. Thank goodness for the VB editor environment!

These are my opinions only and nobody has to use them if they don't want to. I have tried both methods and found my style easier to decipher when I haven't seen the code for a few years. I end up with a heck of a lot less code in total.
You can use the select case routine to go to other subs or modules so the overall strategy is easier to understand. Its not my idea anyway and I've seen it before.

EntryBox(Index) is necessary when I use the created controls or indexed controls method as previously referred to.
You wouldn't be putting a default family name into a "TotalToPay" amount box.

Personally I think DefaultFamilyName is easier to understand 3 years later than StrDFM.

To Bob Rhodes. <users in general prefer to look over the entire record before deciding to commit changes.>
Yes I agree when creating a new record but I was talking about changing a record. I think it is better to do it on each control because you can't otherwise see what you have changed. Alternately you could change the color of any box that is changed then save them as one on exit.

I had a case where there were arguments that my app wasn't changing records. The operator would make a change or two, answer the phone then maybe go and make a cup of tea. Someone else would want to look up something else and discard all then changes so we made every change save on the spot and no problems occurred after that.

 

[strongm]

>I think DefaultFamilyName is easier to understand 3 years later than StrDFM

My point was nothing to do with strDFM (I only used it because you had)

>EntryBox(Index) is necessary when I use the created controls or indexed controls method

Well quite. And there's the rub; I suspect few VB programmers use that technique as their default method of populating forms with controls (sure, there are appropriate times to do that, as I mention in thread222-1399116 where you suggest a control array solution) and can thus be more meaningful with their class names

>because you can't otherwise see what you have changed
I don't see how your solution solves this particular issue

>I had a case ... when someone else would ... discard all the[n] changes
But that just suggests a problem with the interface design rather than anything else. And your solution then immediately leads to the problem of partially updated records.

 

[JoeAtWork]

I have tried both methods and found my style easier to decipher

I guess we are going to have to agree to disagree. If someone wanted me to take over a project that uses this style I would quote double or triple my normal time because of all the extra time it would take me to figure out what is going on in the code.

You can use the select case routine to go to other subs or modules so the overall strategy is easier to understand.

Sorry, I just don't see how scrolling through a monolithic function, looking for the Select Case that applies to the control I am interested in, is easier then double-clicking on the control and going directly to the code that is relevant.

Personally I think DefaultFamilyName is easier to understand 3 years later than StrDFM.

Nobody is arguing that strDFM is a good variable name. StrongM's point was that if you want to assign DefaultFamilyName to the appropriate control, he has to search through your initialization procedure to discover which index to use in the control array.

Someone else would want to look up something else and discard all then changes

That sounds like a pretty unique business environment. Most of the businesses I deal with have a computer dedicated to each employee. Even if someone else takes over the computer, most users will not simply discard somebody else's changes when faced with a "This record has been edited, do you wish to save changes?" prompt.
Maybe in this case saving on each field change solves your problem of untrained users.
But in general I see problems with this approach:
1. Frequent unneccessary calls to the database
2. No chance for the user to cancel his changes
3. Validation rules are often at the record level, not the field level. E.g. one field may be valid depending on the value of another field. As the user is editing data, the record may temporarily be in an invalid state until the user gets to editing the field that will make it valid.

 

[BobRodes]

<I would quote double or triple my normal time because of all the extra time it would take me to figure out what is going on in the code

I would quote double or triple my time too, although it wouldn't really take that much extra time because I'm psychic. However, I believe that if I have to use my psychic powers I should be compensated a good deal extra, due to the fact that such powers are in limited supply.

<I was talking about changing a record

Me too. I basically agree with strongm and Joe on this one, Ted.

Bob

 

[tedsmith]

Whatever turns you on!