More Forms or More VBA (1 Viewer)

Gazza1709

New member
Local time
Today, 12:24
Joined
Sep 9, 2018
Messages
7
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

Banishment Pending
Local time
Today, 07:24
Joined
May 11, 2011
Messages
11,611
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

Immoderate Moderator
Staff member
Local time
Today, 07:24
Joined
Feb 28, 2001
Messages
26,996
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

Nifty Access Guy
Staff member
Local time
Today, 12:24
Joined
Jul 9, 2003
Messages
16,244
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

Super Moderator
Staff member
Local time
Today, 08:24
Joined
Feb 19, 2002
Messages
42,970
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

New member
Local time
Today, 12:24
Joined
Sep 9, 2018
Messages
7
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

Immoderate Moderator
Staff member
Local time
Today, 07:24
Joined
Feb 28, 2001
Messages
26,996
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

Nifty Access Guy
Staff member
Local time
Today, 12:24
Joined
Jul 9, 2003
Messages
16,244
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

Registered User.
Local time
Today, 23:24
Joined
Jul 4, 2013
Messages
2,770
so the form will load blank

Easier to have form's recordsource as
Code:
select * from YourTable where false

Alternatively, set the form's filter to
Code:
False=true
 

Pat Hartman

Super Moderator
Staff member
Local time
Today, 08:24
Joined
Feb 19, 2002
Messages
42,970
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.
 

Pat Hartman

Super Moderator
Staff member
Local time
Today, 08:24
Joined
Feb 19, 2002
Messages
42,970
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.
 

Users who are viewing this thread

Top Bottom