More Forms or More VBA

[Gazza1709]

Hi all,

I have a form that I use for all my sales side orders (Quotes, Orders, Invoices etc), I use vba code to setup the form when it opens and also set the subform to use depending on the type of order.


My question is - Is it better to create different forms for each order or use vba code as I am to setup the form?

 

[plog]

Not really enough to go on. If they all use the require essentially the same data, then use just 1 form and then VBA to slightly customize it for each.

 

[The_Doc_Man]

Unfortunately, there is no answer to that question without a lot more data AND without us knowing if YOU have a preferred way to work. There are cases where either answer is right and the other is wrong. And only YOU know what you really want to do.

plog's comment, however, is quite correct. The closer the special sub-forms are to each other, the easier it will be to just use the same form and maybe tweak it a bit. So you would use VBA to tweak the form. On the other side of that coin, if you have a single sub-form, you would be using VBA to redefine the form that gets plunked down into the sub-form slot and would have to reassert parent/child form linkages. So I don't see you avoiding SOME type of VBA no matter what you do.

 

[Uncle Gizmo]

Hi all,

I have a form that I use for all my sales side orders (Quotes, Orders, Invoices etc), I use vba code to setup the form when it opens and also set the subform to use depending on the type of order.


My question is - Is it better to create different forms for each order or use vba code as I am to setup the form?

Well, quotes, orders, invoices, are essentially different stages of the same thing. In that a quote becomes an order and an order becomes an invoice. If there are only minor changes between the stages, then a single form presenting a VBA modified interface to manage each stage is ideal.

I'm not sure what you mean by "creating a different form for each order"?

Sent from my SM-G925F using Tapatalk

 

[Pat Hartman]

What are you saving by having a single form serve multiple order types?

My first inclination would be to use a single form but if the code is completely different for each type then it is better to clone the form and have clean code behind each version.

 

[Gazza1709]

Hi all,

Thanks for the answers.

This wasn`t really a specific question as such, I was just wondering what the experts prefer to use. the orders example above was just an example of a business process.

From the answers I am guessing that if that more code is the way to go if it is all part of one business process.

Is there any speed and performance gain in doing it either way?

 

[The_Doc_Man]

Having the multiple forms ready to load with no other customization required is the fastest way. Having a lot of customization code that has to be executed during Form_Load events is probably not so fast, particularly if domain aggregates like DCount or DLookup get used.

 

[Uncle Gizmo]

As doc man alludes to, the biggest problem in loading speed is the number of Records loaded.

One trick I use is to have the default record source of the form set to select the zeroeth (0) record. You are practically guaranteed not to have a record number 0 so the form will load blank.

However I have never tested this, so I have no real idea if it does much good, I just think it does!

Sent from my SM-G925F using Tapatalk

 

[Cronk]

so the form will load blank

Easier to have form's recordsource as

select * from YourTable where false

Alternatively, set the form's filter to

False=true

 

[Pat Hartman]

In the olden days we learned about coupling and cohesion. Programs/Objects should be losely coupled (have the fewest dependencies possible) and highly cohesive (about one and only one process - there should be almost no If's that execute different logic paths).

I once ran into an error routine that someone built with a nested If that went on for hundreds of tests. In the calling procedure, a number was assigned to a variable and then the "common" code was called. In the "common" code, the nested If looked for each possible error value and displayed the associated error message!!. It was a completely useless procedure. The procedure that found the error could just as easily have passed the error message into the "common" code to write the message which would have made the "common" procedure about 10 lines of code and the 200+ nested If could have been eliminated. This is of course what came to mind immediately as I read your question.

So again, if the code for the different types is not almost identical, then I would not attempt to reuse a common form. You actually have to be saving something to make this form uncohesive.

 

[usama_hawas]

i prefer to use one form and then use VBA to customize it

 

[Pat Hartman]

There is no benefit to reusing code that is not common. You make dependencies where none should occur and you save neither design time nor execution speed.