Split Forms

[KitaYama]

Its already been mentioned but have a look at the emulated split form which has both single and continuous views using the same form.
No subform needed. Search feature built in.
A datasheet could be used instead of the continuous form if preferred but then of course a subform is needed

Emulated Split Form

The emulated split form was created as a project to overcome the difficulties inherent with the built-in split form supplied with Access

isladogs.co.uk

@isladogs I've read your article several times in the past. I've always had a question and hesitated to ask. Now that you give a link to the article, I think I better ask it.

The following is from your link :

However, unlike the standard split form, the data can be filtered as well as sorted.

What does it mean?
Because I use a standard split form, I can filter it by :
Me.Filter=......
Me.FilterOn = True

OR

Me.RecordSource="SELECT * FROM qry WHERE " & Filter.

I can also right click a textbox and select one of Access default filter context menu items: , greater than,...Less than....equal to... etc,
And clicking each title, sorts the form.

The image I posted in #11 has more than 10 textboxes, listboxes, checkboxes, options and combo to filter the form.
And users are actually filtering the data.

So both Access default Sort & Filter tools & user defined methods can be used.
I appreciate if you explain what do you mean by above statement?

thanks.

 

[isladogs]

@KitaYama
Split forms do have limitations and, IIRC many years ago that was one of the limitations.
However, I agree that comment no longer applies - you certainly can filter a standard split form

I will update my article at some point

Sorting was of course never an issue due to the datasheet view

Here are some issues that do still apply and which I will add to the article:

1. You cannot use a standard split form as a subform. Only the single form part is shown.
That also prevents its use in a tab control

The emulated split form works perfectly as a subform, including in tab controls

2. Standard split forms don't play nicely with automatic form resizing (AFR) and can give peculiar results like this

The display can be fixed by moving the splitter bar but its a PITA to do so each time
Emulated split forms behave perfectly with AFR

3. I use overlapping windows display & find it impossible to control the height/width of a standard split form.
It always appears too tall and wide
However, its fine if used with tabbed documents or maximized

 

[isladogs]

UPDATE
Thanks to @KitaYama for the prompt in post #21.
I have just updated the web article including all the above info / corrections and additional screenshots

I have also started work on the next update which will allow the columns in the continuous form section to be moved/resized/hidden at runtime as can be done in datasheets.

 

[KitaYama]

I have also started work on the next update which will allow the columns in the continuous form section to be moved/resized/hidden at runtime as can be done in datasheets.

It would be great if it remembers the setting (by saving the changes to an options table?) for each user.

 

[isladogs]

Assuming each user has a different workstation, that should happen automatically if the form is saved on close.

 

[Thales750]

Thanks for all the input. I've never used them, like Pat, all of our systems are on SQL. After looking through the responses, It doesn't seem like there is any compelling reason to use them in my world.

 

[Thales750]

I have also started work on the next update which will allow the columns in the continuous form section to be moved/resized/hidden at runtime as can be done in datasheets.

I didn't even know that was possible?

 

[isladogs]

It is possible but needs APIs or similar code.
In fact, @CJ_London provided an example here some time ago

continuous form that allows users to resize and reorder columns like a datasheet

I developed this because datasheets have some useful functionality, but limitations as well - among them Datasheets can't show controls such as buttons, images, attachments, etc Datasheets can't show a record over multiple rows within the detail section Datasheets don't have header and footer...

www.access-programmers.co.uk

@arnelgp also created his own version some time later

Move/Resize(Width) Column of Continuous Form

this is somewhat similar of the same demo here, but with full code that you can inspect (not an .accde). there may be some errors or unwanted behavior, since this is the initial upload. if you see any errors or unwanted behaviour, you try to fix them. there is no documentation on the code at the...

www.access-programmers.co.uk

PersonaIly, I never use split forms in my own applications other than for demonstration purposes

 

[isladogs]

I thought it might also be useful to write an article explaining how you can create a simulated split form using a single form and datasheet or continuous subform which are kept synchronised.

Build Your Own Split form

The Access split form has several important limitations. This article shows how you can create your own simulated split form which doesn't have the restrictions inherent with the built-in Access split form

www.isladogs.co.uk

Each of these also overcomes the 3 issues I discussed in post #22 above

 

[Galaxiom]

The severe limitations of their object model and the consequent limitations on automation is why I eschew Split Forms..

 

[isladogs]

The severe limitations of their object model and the consequent limitations on automation is why I eschew Split Forms..

Yes I agree, So you either scrap them or replace them
I've chosen to make replacement forms that do not have those limitations

 

[KitaYama]

limitations of their object model

@Galaxiom
May I ask what these limitations are? or any article to read about them?
Because the only thing I've noticed was the problem of resizing them.

Thank you.

PS: @isladogs The link in top of this page is broken. Just a notice.

 

[KitaYama]

I thought it might also be useful to write an article explaining how you can create a simulated split form using a single form and datasheet or continuous subform which are kept synchronised.

Build Your Own Split form

The Access split form has several important limitations. This article shows how you can create your own simulated split form which doesn't have the restrictions inherent with the built-in Access split form

www.isladogs.co.uk

Each of these also overcomes the 3 issues I discussed in post #22 above

@isladogs
May I ask a stupid question?
For your enhanced continues split form, why do you need a subform? I can create a continuous form and copy and paste the exact controls to the header. It behaves like a split form. I can add, delete & edit a record both from the single and continues section.

 

[Galaxiom]

@Galaxiom
May I ask what these limitations are? or any article to read about them?
Because the only thing I've noticed was the problem of resizing them.

I've not tried them for years but there were many missing members that were available on other form objects. The column properties was one of the issues. Maybe they fixed some stuff since but I couldn't be bothered revisiting them when the emulated versions work well with no surprises.

 

[KitaYama]

I've not tried them for years but there were many missing members that were available on other form objects. The column properties was one of the issues. Maybe they fixed some stuff since but I couldn't be bothered revisiting them when the emulated versions work well with no surprises.

Well, seems everybody hates them without knowing exactly what's wrong with them. (at least in recent versions of Office)
I'll try google to see if I find anything.

Thanks for taking your time and replying.

 

[isladogs]

@KitaYama
I’m on a different time zone to you so can’t respond in the middle of the night UK time. I will respond later with a long list of issues both in terms of layout and run time risks.

Split forms are fine if you are happy with the layout presented BUT if you try to modify that in any significant way….it’s a fight between you and the form which basically says oh no you don’t change me...

More later …

Yes you can simulate a split form with e.g. a single form in the header and a continuous form below. The advantage is it needs no code to stay in sync. A minor disadvantage is the record highlighter feature covers the first row if the columns are sorted by the header. Replacing with a record selector solves that.

 

[KitaYama]

I will respond later with a long list

I really appreciate it.
No need to hurry. Any time would be just fine. Take your time. Lowest priority would be OK.

It's just for educating myself.

Million thanks.

 

[isladogs]

OK - these are the main points I can remember but there may be other things I've overlooked
My criticisms of split forms fall into two main areas: display issues & runtime risks

Display Issues

• Using a standard unmodified split form with tabbed documents generally works fine
• However, if you use overlapping windows display, controlling the height & width of the form seems to be impossible EVEN if layout guides are removed. The form seems determined not to allow changes. When the form is reopened, it is always larger in both dimensions than it needs to be. Even the position of the splitter bar isn’t always retained when reopened

Disabling the splitter does not fix the above issues

Making any significant alterations to a split form can be very problematic as the form often doesn’t behave as expected. For example

• Trying to use a split form in a subform fails. Only the single form section is displayed
• Dragging the split form controls to a tab control MAY work OK …but see below
• Placing any object such as a label or subform in the unused footer section is allowed but causes problems.
• The footer items are displayed over the single form controls and partially or wholly cover them. To fix, increase the detail height or reduce the footer height
• Placing the subform in a tab control doesn’t alleviate this issue
• Split forms don’t behave properly with automatic form resizing unless the splitter bar is disabled

Run time risks
Datasheets are designed so that users can resize/move/hide/unhide/ delete fields at RUN TIME.
This can, of course, be useful, particularly in a standalone datasheet form

However, this can be confusing/dangerous in a split form where the single form section can only be altered in design view.

Despite this, the single form can be altered by changes to the datasheet section. For example:
A user right clicks on a datasheet field and, possibly unintentionally, clicks Delete instead of Hide.
The corresponding label in the single section immediately disappears (though not the textbox).
If any such changes are saved when the form is closed, the textbox control is also removed from the single form section on reopening.

Changing the datasheet properties to Read Only doesn’t prevent this. It only stops data changes in the datasheet (whilst allowing them in the single form which can be confusing). The right click context menu still allows fields to be deleted.

Setting the shortcut menu to No removes the context menu and solves this issue, but of course this also affects the single form section.

Code limitations

From memory, there are certain things you cannot do in a split form that are possible in separate single, continuous or datasheet forms. I haven't checked recently to see if this still applies. With all the above issues, it no longer really matters in my opinion.

Replacements to the Split form

If instead you create a SIMULATED split form using a single main form with a datasheet or continuous subform (or vice versa), the end result can be almost identical for the end user. Code is needed to keep the form & subform in sync but this isn’t difficult.

The form can be searched/filtered/sorted as for a standard split form

More importantly, NONE of the above issues still apply. The simulated split form can

• Be used in a subform or tab control
• Be used with a subform or objects in the footer
• Deletions to the datasheet fields do not alter the single main form

See attached database for examples of the above split form issues and solutions using simulated split forms. See also my article:

Build Your Own Split form

The Access split form has several important limitations. This article shows how you can create your own simulated split form which doesn't have the restrictions inherent with the built-in Access split form

www.isladogs.co.uk

Alternatively, the EMULATED split form combines the single & continuous sections in a single form. This has a further advantage that no code is needed to keep both sections synchronised as each is in the same form. See my article:

Emulated Split Form

The emulated split form was created as a project to overcome the difficulties inherent with the built-in split form supplied with Access

www.isladogs.co.uk

Overall conclusions
Split forms are fine provided you use tabbed documents display, don't need to modify the form and disable the shortcut menu

Otherwise, I would avoid them completely
OR if you want the split form functionality, it is FAR better to use one of the replacements described above - either SIMULATED or EMULATED

Finally, Richard Rost created a video on split forms that is worth watching. He covers some of the same points as me in his own inimitable style:

OK rant over. I'll get off my soapbox now

NOTE: So I can easily find this info again in the future, I'll update my web articles on this topic

 

[KitaYama]

OK - these are the main points I can remember but there may be other things I've overlooked
My criticisms of split forms fall into two main areas: display issues & runtime risks

Display Issues

• Using a standard unmodified split form with tabbed documents generally works fine
• However, if you use overlapping windows display, controlling the height & width of the form seems to be impossible EVEN if layout guides are removed. The form seems determined not to allow changes. When the form is reopened, it is always larger in both dimensions than it needs to be. Even the position of the splitter bar isn’t always retained when reopened

Disabling the splitter does not fix the above issues

Making any significant alterations to a split form can be very problematic as the form often doesn’t behave as expected. For example

• Trying to use a split form in a subform fails. Only the single form section is displayed
• Dragging the split form controls to a tab control MAY work OK …but see below
• Placing any object such as a label or subform in the unused footer section is allowed but causes problems.
• The footer items are displayed over the single form controls and partially or wholly cover them. To fix, increase the detail height or reduce the footer height
• Placing the subform in a tab control doesn’t alleviate this issue
• Split forms don’t behave properly with automatic form resizing unless the splitter bar is disabled

Run time risks
Datasheets are designed so that users can resize/move/hide/unhide/ delete fields at RUN TIME.
This can, of course, be useful, particularly in a standalone datasheet form

However, this can be confusing/dangerous in a split form where the single form section can only be altered in design view.

Despite this, the single form can be altered by changes to the datasheet section. For example:
A user right clicks on a datasheet field and, possibly unintentionally, clicks Delete instead of Hide.
The corresponding label in the single section immediately disappears (though not the textbox).
If any such changes are saved when the form is closed, the textbox control is also removed from the single form section on reopening.

Changing the datasheet properties to Read Only doesn’t prevent this. It only stops data changes in the datasheet (whilst allowing them in the single form which can be confusing). The right click context menu still allows fields to be deleted.

Setting the shortcut menu to No removes the context menu and solves this issue, but of course this also affects the single form section.

Code limitations

From memory, there are certain things you cannot do in a split form that are possible in separate single, continuous or datasheet forms. I haven't checked recently to see if this still applies. With all the above issues, it no longer really matters in my opinion.

Replacements to the Split form

If instead you create a SIMULATED split form using a single main form with a datasheet or continuous subform (or vice versa), the end result can be almost identical for the end user. Code is needed to keep the form & subform in sync but this isn’t difficult.

The form can be searched/filtered/sorted as for a standard split form

More importantly, NONE of the above issues still apply. The simulated split form can

• Be used in a subform or tab control
• Be used with a subform or objects in the footer
• Deletions to the datasheet fields do not alter the single main form

See attached database for examples of the above split form issues and solutions using simulated split forms. See also my article:

Build Your Own Split form

The Access split form has several important limitations. This article shows how you can create your own simulated split form which doesn't have the restrictions inherent with the built-in Access split form

www.isladogs.co.uk

Alternatively, the EMULATED split form combines the single & continuous sections in a single form. This has a further advantage that no code is needed to keep both sections synchronised as each is in the same form. See my article:

Emulated Split Form

The emulated split form was created as a project to overcome the difficulties inherent with the built-in split form supplied with Access

www.isladogs.co.uk

Overall conclusions
Split forms are fine provided you use tabbed documents display, don't need to modify the form and disable the shortcut menu

Otherwise, I would avoid them completely
OR if you want the split form functionality, it is FAR better to use one of the replacements described above - either SIMULATED or EMULATED

Finally, Richard Rost created a video on split forms that is worth watching. He covers some of the same points as me in his own inimitable style:

OK rant over. I'll get off my soapbox now

NOTE: So I can easily find this info again in the future, I'll update my web articles on this topic

@isladogs Thanks for the detailed reply and the list of shortcomings of split forms.

We don't use tab control and we have our customized context menu for each form. (I think every developer has)
So although we are safe against some of the points you explained, I emailed your reply to the admin of our databases. I also included a link to your site and split forms.

The most interesting part was code limitation.
I'll try Google to see what exactly is not available in split forms. I'll add a link later if I find still any code limitation for split forms is in place.

Once again I really appreciate your time and sharing your experience.
Thank you.

PS : Still the broken link in your site is not corrected. (#11) Just a notification.

 

[isladogs]

One code issue with split forms has just been reported. They don't currently support the code context object

Open a split form and add this code to the Form_Load event:

Debug.Print Now, "CodeContextObject", (CodeContextObject Is Nothing)

Run the form, and you will get error 2467: The expression you entered refers to an object that is closed or doesn’t exist.

Open any type of form and the code runs without issues
The split form error has been reported as a bug

I looked at post #11 and couldn't find any link mentioned. Just fixed the broken link you did mention in post #32

Currently writing up post #38 as a new web article & will modify the two earlier articles to remove duplication