How does Access create a continuous form? (1 Viewer)

[MsAccessNL]

I am really curious how Access assemblies a continuous form. I tried googling it , and found out that it’s quite a special feature.

 

[theDBguy]

Just curious, what would ChatGPT say? I can't check right now.

 

[MsAccessNL]

I am curious to, but chatgpt is cant’t be accessed for many days know (from Holland), I think they get to many requests. We are already depending on this new feature on the internet.…On the otherside, i am surprised that google (after all these years) stil comes up with all these useless hits like the how the continious past tense form of a certain lenguage is created. The search engine still works with just searching for compliant words, and not the actual intent of the search. What has Google being doing for the last 20 years?

 

[The_Doc_Man]

A continuous form is somewhat analogous to the detail area in a report, where you have many detail lines based off the same template line. You have as many detail lines in the detail section of the report as there are records in the grouping for that subset of details. You generate the rows of a continuous form just like you generate the rows of the detail section of your report.

For forms, you have the .RecordSource for the continuous form and a single form definition that is based on fields that will be in the same record (just like a normal form) - but instead of having only the single record in a "normal" form, the continuous form repeats the form definition for each record selected by the form's filter and other criteria. I believe that you CAN define a detail area that actually occupies more than one line, but that is not the way it is usually defined.

Since there is only a single ... call it a "row template", there will be a number of rows that look exactly like each other except for details of data. BUT since there is only a single row template, anything you do that would affect the layout of the template does what it does to EACH RECORD. Which is why you need to use conditional formatting options if you want the rows to appear differently. Doing things to the row template will in that case not be selective at all. AND if any of the fields are unbound, loading a value to any unbound field (regardless of which record has focus) loads it to ALL unbound founds within the range of the .RecordSource.

In a limited sense, a "datasheet view" of a table/select-query is a continuous form except that it is harder to get to the form's properties during run-time activation. I could be wrong on this, but I believe there is an Access-generated continuous form template generated by opening something in datasheet view and it is not easily accessible. Access is like the rest of Office in that it has a template source, but I'm damned if I can tell you offhand where it is for Access. Still, that is where default datasheet views originate. Unless MS has changed everything around since the last time I looked at this particular feature, and I wouldn't put it past them.

 

[Pat Hartman]

A single or continuous form is essentially the same. There is ONE template for the form layout which means that only ONE set of properties or variables exists at one time. To understand this better, take one of your forms that is defined as single view and change it to continuous. Same form, same code module, just shows multiple instances depending on the screen real estate.

The confusing aspect is that people think there are different instances of code that run on the different records simultaneously. That's not how it works. It is ONE set of code that runs for what ever instance of the RecordSource is current. I.e. that the form is focused on. To understand this concept better, make sure that you have the RecordSelector property set to Yes so that in continuous view, you can easily see which record has the focus. The RecordSelector for the record that has the focus shows as a right triangle. use the up or down arrow to move the focus. Notice how the RecordSelector moves. Only the record with the focus is ever affected by running code. For example, if you have code in the form's Current event. When you move the focus to a record the code in the current event runs for the record with the focus. Show this to yourself by adding a message box to the Current event to display the recordID of the current record.

Msgbox " current record = " & Me.YourRecordsPrimaryKeyID, vbOKOnly

As you move into each new record, you will see the message box display a different value.

When you type into a control, notice that the RecordSelecor for that record changes to a pencil. That is a clue that the record is dirty. When the record is saved, the RecordSelector changes back to a right triangle. In a multi-user environment. Open the app on two different computers. Open the same form and click into the same record. One of you change the record. Your RecordSelector will turn into a pencil but on the other computer, the recordselector will become a circle with a line through it so you know that another user is editing the record you are viewing. Now before, the original user saves the record, the second user should make a change and try to save. Do you get an error message? Then have user #1 save. What does his message say? What is the result to the record depending on how user 1 responds to the error message?

 

[arnelgp]

I am really curious how Access assemblies a continuous form.

only those ms people who programmed it can answer that.

 

[KitaYama]

Just curious, what would ChatGPT say? I can't check right now.

Question:
How Access assemblies a continuous form?

Reply:
In Microsoft Access, a continuous form allows you to display multiple records in a single form, with each record appearing as a separate row. To create a continuous form in Access, follow these steps:

1. Create a new form: Open the database and click on the "Create" tab in the ribbon. Click on the "Form Design" button in the Forms section to create a new form.
2. Choose the Continuous Form option: In the New Form dialog box, select the "Continuous Form" option and click "OK." Access will create a new continuous form with a single blank record.
3. Add fields to the form: From the Fields tab in the ribbon, drag and drop the fields you want to include in the form onto the form design. You can also right-click on the form and choose "Add Existing Fields" to add fields from the underlying table.
4. Adjust the form layout: You can adjust the size and placement of the fields on the form to fit your needs. You can also add labels or other controls to the form to help users understand what information is being displayed.
5. Save the form: When you're done making changes to the form, save it by clicking on the "Save" button in the Quick Access Toolbar or by going to the "File" menu and choosing "Save."

Once you've created the continuous form, you can use it to display and edit multiple records at the same time.

I asked "How Microsoft Access creates a continuous form?

The answer was the same.

 

[sonic8]

I am really curious how Access assemblies a continuous form.

As @arnelgp remarked, only the people at Microsoft working on Microsoft Access development can know for sure. AFAIK this was never published in any way.

From the behavior we see when using continuous forms, we can deduct a couple of things.
Only the area of current record is a normal Access form. The areas of all the other records are only drawn on the screen as an image, and do not contain any "real" controls or windows. All direct references to form controls in VBA will only get the controls of the current record.

 

[ebs17]

If you look in the object catalog (you know this one?), you will see at the latest that a form is a class, a control is a class, a text box is a class, etc. A class has properties, methods and events. Classes can interact according to programming. The DefaultView form property is a switch between different views and possible uses.

 

[MsAccessNL]

only those ms people who programmed it

 

[MsAccessNL]

Can’t we track the guy who invented this option? Assuming he is still alive, he/she should be out there somewhere.
May be we canask this guy:
https://www.linkedin.com/in/clint-covington

 

[Minty]

I'm perplexed as to the overall purpose of this question?
Assuming ( and I doubt you'll ever get an accurate answer) someone tells you "We use black holes and mirrors with some unicorn dust", what will you do with that information?
Buy shares in unicorn dust?

 

[arnelgp]

"We use black holes and mirrors with some unicorn dust", what will you do with that information?

maybe ask some "dust" to bite it (another one byte the dust..)

 

[sonic8]

Can’t we track the guy who invented this option? Assuming he is still alive, he/she should be out there somewhere.

In addition to @Minty's comment: How Access works internally is Microsoft confidential information. No current or former Microsoft employee will disclose this just because you are curious.

If there is a sensible and understandable need to know details of the implementation, you should elaborate and state your case here. If it is reasonable, there is a chance some of the readers here will pick up your inquiry and relay it to people who would be able to answer.
In any case, be aware that this is proprietary and undocumented and even if you would get any information, it may change anytime without notice.

 

[ebs17]

Knowing certainly means wanting to intervene and control individually.

Since, as described, it is difficult to find out how MS Access programmed, it may be easier for you to program your OWN development environment that does and can implement what you want.

 

[sonic8]

I am really curious how Access assemblies a continuous form. I tried googling it , and found out that it’s quite a special feature.

The feature is not so special after all.
There was a control included with VB6 with similar capabilities. The DataRepeater control from the VB.Net PowerPacks is its successor in the .Net Windows Forms context.

There is a Continuous Forms demo on CodeProject with full source code included, which you can download and analyze.

Of course, neither of the above gives information on how continuous forms work in Access. Nonetheless, they should demonstrate how such a feature can be developed in general.

 

[GPGeorge]

Can’t we track the guy who invented this option? Assuming he is still alive, he/she should be out there somewhere.
May be we canask this guy:
https://www.linkedin.com/in/clint-covington

Access was released in 1992. Clint's tenure on the Access team was a more than decade later. He, and others who have worked at Microsoft, might know names of people involved at the time, but as others pointed out, information about the code is not now, and will probably not ever be, released publicly for reasons that should be obvious. I say probably not ever be made public only because there may come a day when Microsoft doesn't feel the need to continue supporting Microsoft themselves

 

[gemma-the-husky]

I doubt a continuous form is so complicated. It's just a matter of whether one detail item is displayed on the screen, or whether more than one is.

The hard bit is using VBA.

With a different language it would be pretty easy to represent a linked list (for example) as either a succession of single record elements, or a full collection of all the record elements. It's hard to do in VBA because VBA doesn't have a pointer type. (I imagine). It's pretty hard to manipulate a simple structure like a linked list without a pointer.

I will have a look at the example mentioned above.

 

[sonic8]

It's hard to do in VBA because VBA doesn't have a pointer type. (I imagine).

Every object variable you use in VBA is a pointer type.

It's not particularly hard building a continuous form. - I happen to know because I'm currently working on something in VB.Net that could be considered a continuous form. - The (slightly) hard bit is that you need to keep the visual representation of the items in sync with their state in memory (and the database).

The particular weakness of VBA in this regard is that it has only a very limited set of available UI controls (the Microsoft Forms library), if you can even count those. Anything beyond that must be provided by the host application, Access in our case. The Access UI elements are pre-built for displaying data forms on screen, and they are reasonable good at that task. However, if you don't want to use the built-in forms, but build your own, Access is a very, very poor tool to achieve that goal.

 

[Pat Hartman]

And the nice thing about Access is that the Access development team built us a class module that can render a form using one of three views and we don't have to worry about recreating the wheel. They also gave us hooks (events) we could use to customize the form's behavior under specific conditions that translate to events caused by actions taken by the user or Access itself. For example, the user may initiate a record save action but so can Access. In our code, we respond to this in the form's BeforeUpdate event and decide if WE will allow the save to actually happen.

We do need to have a basic understanding of how a "single" view form works so we can understand that interacting with a form in either of the two continuous views is NOT different from interacting with a single view form in any way at all. The form's class module handles the visual representation and pagination. All we ever interact with is THE Current record which is always ONE at a time. All of the code we write and attach to event procedures operates ONLY on the Current record. And only ONE record can be Current at a time no matter how many rows are visible.

Having worked in other environments, I have created single and multi-record forms. Because the environment I was working in used a fixed "form" space, the multi-records that could be displayed at one time were limited to the restricted display space of rows and columns so we had pagination controls to scroll forward and backward just as an Access form does. It wasn't WISIWYG so you couldn't make it taller or wider on the fly. It was fixed in width and in length.