How does Access create a continuous form?

here's a more complex example (PER CHATGPT) of how you can programmatically create a continuous form in Microsoft Access using VBA code:
vbnet
Code:
Sub CreateContinuousForm()

'Declare the variables
Dim frm As Form
Dim tbl As TableDef
Dim ctl As Control

'Create a new form
Set frm = CreateForm

'Set the form's record source to a table or query
Set tbl = CurrentDb.TableDefs("Table1")
frm.RecordSource = tbl.Name

'Set the form's view to Continuous Forms
frm.DefaultView = acFormViewContinuous

'Set the form's properties
frm.AllowDatasheetView = False
frm.AllowEdits = True
frm.AllowFilters = True
frm.AllowDeletions = True

'Add the fields to the form
Set ctl = frm.AddNewControl("TextBox", acTextBox, acDetail, , "Field1")
ctl.ControlSource = "Field1"
ctl.Width = 100

Set ctl = frm.AddNewControl("TextBox", acTextBox, acDetail, , "Field2")
ctl.ControlSource = "Field2"
ctl.Width = 100

Set ctl = frm.AddNewControl("TextBox", acTextBox, acDetail, , "Field3")
ctl.ControlSource = "Field3"
ctl.Width = 100

Set ctl = frm.AddNewControl("ComboBox", acComboBox, acDetail, , "Field4")
ctl.ControlSource = "Field4"
ctl.RowSourceType = "Table/Query"
ctl.RowSource = "LookupTable"
ctl.Width = 100

'Add a label to the form header
Set ctl = frm.AddNewControl("Label", acLabel, acHeader, , "lblHeader")
ctl.Caption = "Continuous Form Example"
ctl.ForeColor = vbRed
ctl.Font.Size = 14
ctl.Font.Bold = True
ctl.Width = 500

'Save and open the form
frm.Save
frm.OpenForm

End Sub

In this example, the code creates a new form, sets its record source to a table named "Table1", sets its view to continuous forms, sets its properties, and adds four fields named "Field1", "Field2", "Field3", and "Field4". The code also adds a label to the form header with a caption "Continuous Form Example".

For each field, the code adds a control, sets its control source to the field name, sets its width, and specifies its properties such as the row source type and row source for the "Field4" control.

Finally, the form is saved and opened for viewing.

This is just one example of how you can programmatically create a continuous form in Microsoft Access using VBA code. You can customize the code to suit your specific requirements, such as adding additional fields, changing the form properties, or adding other controls such as buttons or images.
 
One more:

Could you produce a much more complex example of how to programmatically create a continuous form in access with using visual basic for applications code?


Sure, here's a much more complex example of how you can programmatically create a continuous form in Microsoft Access using VBA code:

Code:
Sub CreateComplexContinuousForm()

'Declare the variables
Dim frm As Form
Dim tbl As TableDef
Dim ctl As Control

'Create a new form
Set frm = CreateForm

'Set the form's record source to a table or query
Set tbl = CurrentDb.TableDefs("Orders")
frm.RecordSource = tbl.Name

'Set the form's view to Continuous Forms
frm.DefaultView = acFormViewContinuous

'Set the form's properties
frm.AllowDatasheetView = False
frm.AllowEdits = True
frm.AllowFilters = True
frm.AllowDeletions = True
frm.AllowPivotTableView = True
frm.AllowPivotChartView = True

'Add the fields to the form
Set ctl = frm.AddNewControl("TextBox", acTextBox, acDetail, , "OrderID")
ctl.ControlSource = "OrderID"
ctl.Width = 100

Set ctl = frm.AddNewControl("TextBox", acTextBox, acDetail, , "CustomerID")
ctl.ControlSource = "CustomerID"
ctl.Width = 100

Set ctl = frm.AddNewControl("TextBox", acTextBox, acDetail, , "OrderDate")
ctl.ControlSource = "OrderDate"
ctl.Width = 100

Set ctl = frm.AddNewControl("ComboBox", acComboBox, acDetail, , "ProductID")
ctl.ControlSource = "ProductID"
ctl.RowSourceType = "Table/Query"
ctl.RowSource = "Products"
ctl.Width = 100

Set ctl = frm.AddNewControl("TextBox", acTextBox, acDetail, , "Quantity")
ctl.ControlSource = "Quantity"
ctl.Width = 100

Set ctl = frm.AddNewControl("TextBox", acTextBox, acDetail, , "Discount")
ctl.ControlSource = "Discount"
ctl.Width = 100

Set ctl = frm.AddNewControl("TextBox", acTextBox, acDetail, , "Total")
ctl.ControlSource = "Total"
ctl.Width = 100

'Add a label to the form header
Set ctl = frm.AddNewControl("Label", acLabel, acHeader, , "lblHeader")
ctl.Caption = "Orders Continuous Form Example"
ctl.ForeColor = vbRed
ctl.Font.Size = 14
ctl.Font.Bold = True
ctl.Width = 500

'Add a button to the form
Set ctl = frm.AddNewControl("CommandButton", acCommandButton, acDetail, , "cmdCalculate")
ctl.Caption = "Calculate Total"
ctl.OnClick = "CalculateTotal"
ctl.Width = 100
ctl.Height = 25

'Add a form footer
frm.HasModule = True
frm.Module.AddFromString "Option Compare Database" & vbNewLine & "Option Explicit" & vbNewLine
frm.Module.AddFromString "Public Sub

Can you provide an explanation for the code previously supplied?


Sure, here's an explanation for the code previously supplied:

Declaring Variables:
Code:
vbnet

Dim frm As Form
Dim tbl As TableDef
Dim ctl As Control
Creating a New Form:
The first step is to declare the variables that will be used in the code. In this case, the variables are frm of type Form, tbl of type TableDef, and ctl of type Control.
Code:
python

Set frm = CreateForm
This line of code creates a new form object in Microsoft Access.
Setting the Form's Record Source:
Code:
python

Set tbl = CurrentDb.TableDefs("Orders")
frm.RecordSource = tbl.Name

In this section, the tbl variable is set to the "Orders" table in the current database, and the frm object's RecordSource property is set to the name of the tbl table. This specifies the data source for the form.
Setting the Form's View:
Code:
frm.DefaultView = acFormViewContinuous

This line sets the form's default view to continuous form view, which is what creates the continuous form.
Setting the Form's Properties:

Code:
python

frm.AllowDatasheetView = False
frm.AllowEdits = True
frm.AllowFilters = True
frm.AllowDeletions = True
frm.AllowPivotTableView = True
frm.AllowPivotChartView = True

These lines set the various properties of the form, such as whether it can be viewed in a datasheet, if it allows editing, filtering, and deletions, and if it allows pivot table or chart views.
Adding Fields to the Form:
Code:
python

Set ctl = frm.AddNewControl("TextBox", acTextBox, acDetail, , "OrderID")
ctl.ControlSource = "OrderID"
ctl.Width = 100

This section of the code adds the fields from the data source to the form. The first line creates a new control of type TextBox and sets it to the ctl variable. The ControlSource property is then set to the name of the field (in this case, "OrderID"), and the width of the control is set to 100. This process is repeated for each field in the data source.
Adding a Label to the Form Header:
Code:
python

Set ctl = frm.AddNewControl("Label", acLabel, acHeader, , "lblHeader")
ctl.Caption = "Orders Continuous Form Example"
ctl.ForeColor = vbRed
ctl.Font.Size = 14
ctl.Font.Bold = True
ctl.Width = 500
This section of the code adds a label to the form header. A new control of type Label is created and set to the ctl variable. The Caption property is set to a string, the ForeColor property is set to red, and the font properties are set to size 14 and bold. The width of the control is also set to 500.
Adding a Button to the Form:
Code:
python

Set ctl = frm.AddNewControl("CommandButton", acCommandButton, acDetail, , "cmdCalculate")
 
Have you actually tested the code supplied in post #23? Lots of errors
 
For each record in recordset, add user-defined form and recordset.record to user control. What is this thread about?
 
I don't think it's right to say that VBA offers pointers. To use your example, any variable is a pointer, but you can't easily use the address for anything useful.
What would be "anything useful"?
Can you give any example of something that could easier, simpler, faster, or better by any sensible measurement, be done using the raw pointers instead of the typed variables?
The only examples I can currently think of are cases where complex types (e.g. object variables) are not supported and you must resort to raw pointers because they are simple numerical values.

Access is super, but occasionally I feel it would be useful to manage some data by manipulating pointers and record structures. It generally ends up being easier to do this sort of stuff using a temporary table.
You second sentence very much shoots down the argument you are trying to build with the first one. ;-) - And rightfully so!

You can manage data by manipulating pointers. - But I very strongly agree that is much easier to use data structures managed by Access or VBA instead.
This is not specific to VBA. In every modern programming language it is usually *much easier* to use a higher level of abstraction, instead of working with raw pointers. There sometimes are cases where the raw pointers offer a performance benefit or can work around some framework or language limitation. In every case you pay a price of harder to read, harder to maintain, and/or riskier to modify code, which depends on knowledge of internal implementations or arbitrary assumptions.
 
@adhoustonj, can you please explain the purpose of your replicating AI gibberish here?

The prose text contradicts itself.
In the code it invented non-existing methods from thin air. It uses methods not available in the context it claims the code is for. Some comments describe something entirely different than the code does.
In short: The code does not work, and it's not just minor tweaks required to make it work, it's utter rubbish. - It just looks "reasonable" on first sight, which is adding to the danger of using AI generated code.

So, what is your point posting 3 long posts of non working code? You could also have posted 3 pages of Hamlet instead.
 
@adhoustonj, can you please explain the purpose of your replicating AI gibberish here?

The prose text contradicts itself.
In the code it invented non-existing methods from thin air. It uses methods not available in the context it claims the code is for. Some comments describe something entirely different than the code does.
In short: The code does not work, and it's not just minor tweaks required to make it work, it's utter rubbish. - It just looks "reasonable" on first sight, which is adding to the danger of using AI generated code.

So, what is your point posting 3 long posts of non working code? You could also have posted 3 pages of Hamlet instead.
The real danger of AI like chatGPC et al is not that it can replace developers or other professionals. The real danger of AI is that it can lead to a false confidence when it turns out pseudo code that appears to a less experienced person to be legit. In one sense, it could lead to an overall lowering of the general skill level of the developer community as more and more new-comers learn less and less while relying more and more on the pseudo results it can return. Uncritically accepting those results means no thought occurs in the process of copying and pasting it into a project, and no learning.
 
What would be "anything useful"?
Can you give any example of something that could easier, simpler, faster, or better by any sensible measurement, be done using the raw pointers instead of the typed variables?
The only examples I can currently think of are cases where complex types (e.g. object variables) are not supported and you must resort to raw pointers because they are simple numerical values.


You second sentence very much shoots down the argument you are trying to build with the first one. ;-) - And rightfully so!

You can manage data by manipulating pointers. - But I very strongly agree that is much easier to use data structures managed by Access or VBA instead.
This is not specific to VBA. In every modern programming language it is usually *much easier* to use a higher level of abstraction, instead of working with raw pointers. There sometimes are cases where the raw pointers offer a performance benefit or can work around some framework or language limitation. In every case you pay a price of harder to read, harder to maintain, and/or riskier to modify code, which depends on knowledge of internal implementations or arbitrary assumptions.
Anything useful? Like a binary tree, or a balanced binary tree, or a queue, or an ordered list? I find a VBA collection unusable compared with an alternative of creating records, and manually linking them together and managing the links with a few easily written functions to manipulate pointers to other records within the data structure.

A table is probably useable as a next best thing, but it's cumbersome in comparison.

I imagine the msxml library reads an XML file into some sort of pointer chain structure.
 
The only time I needed "real" pointers was in trying to evaluate some issues in my genealogical database work, looking for patrilineal or matrilineal family members among all the clutter of cousins by marriage. My own stepdaughter forced me to do some difficult work in deciphering relationships since she has (1) a biological father, (2) the father who is named on her birth certificate, (3) the father who adopted her when the first two fathers bailed out, and (4) me as a step-dad. I solved that little knot by using recursion and formal arguments ByRef plus careful ordering of how I visit person-entries.

Real pointers would have made it a bit easier. I've got to say that it was at first a nightmare, but eventually I tamed that beast well enough that it no longer went crazy on loops when I ran into persons who married more than once in their lifetimes. And before anyone asks, the data returned by sites like Ancestry.COM includes all of those cousins when you download the GEDCOM file that is their data format for ancestry information, stored in person-attribute-value style with four layers of attribute-tagging. The fact that I was able to do this without a free-range address variable is proof that it IS possible to do without such luxuries for complex data traversal.
 
Anything useful? Like a binary tree, or a balanced binary tree, or a queue, or an ordered list?
Forgive me my ignorance, I'm not familiar with binary trees.

What would be the advantage of using raw pointers to build a binary tree instead of this:
Code:
' in Class Module "BinaryTreeNode"
Public LeftChild       As BinaryTreeNode
Public RightChild      As BinaryTreeNode
Public ArbitraryData    As Variant

Sure, raw pointers would use less memory and thus induce less memory management overhead. However, usually you're not just storing the node relations themselves but also additional data, which relativizes the memory overhead for a class instance.

The above should be good for managing a couple of thousand nodes. Beyond that you might run into stack memory issues when manipulating significant chunks of the tree.

So, fair enough, a large binary tree of relatively small nodes might indeed be a use case for using pointers instead of complex types.
 
Well maybe I'm just not familiar enough with using classes. I don't automatically think of a class instance as being a pointer.

Eg, In your example would the leftchild and rightchild be null, nothing, or empty until it was set to a new binarytreenode?
 
@Pat Hartman
I was really just musing that one way of handling a continuous form might be to create a linked list of the visible records, and manipulating the linked list to reflect whichever records were currently visible on screen, then displaying the record with some sort of display record routine. A single form would only need to display a single record. A continuous form would call this for each displayed record.

At the same time, there must be some fancy indexing technique going on to organise the b-tree of the active index, and some sophisticated working set techniques to determine how the active data gets swapped back and forth from memory to disk and back. I just can't see how this can be achieved without using low level pointers.

I don't see that this is anything to with normalisation of the data in the database.

Having said that, I can't really conceive of the data structures and processes needed to manage a spreadsheet, or even to play chess.
 
Why does the term "Rube Goldberg Machine" keep popping into my head?
 
@adhoustonj, can you please explain the purpose of your replicating AI gibberish here?

The prose text contradicts itself.
In the code it invented non-existing methods from thin air. It uses methods not available in the context it claims the code is for. Some comments describe something entirely different than the code does.
In short: The code does not work, and it's not just minor tweaks required to make it work, it's utter rubbish. - It just looks "reasonable" on first sight, which is adding to the danger of using AI generated code.

So, what is your point posting 3 long posts of non working code? You could also have posted 3 pages of Hamlet instead.
I thought that was what the post was asking.. And someone said they didnt have access to chatgpt to produce the response.
In no way do i endorse or think it is correct, to be honest, I'm not good enough to deduce that, but I thought that was the purpose of the thread..\

And yeah i just checked - first two responses are about chatGPT, so I posted the chatGPT responses? I'm not going to argue if it is gibberish or not. I'd appreciate the value of you explaining why you think it is gibberish then? I thought so too - you can see i included the code tags where some said vb net, python, etc, and I don't agree with it, but i posted it because it was asked and I believe the experts are in the building here.
 
Like any other solution, the result has to be tested. It doesn't matter if the solution is given by an AWF expert or ChatGPT we still need to test it. The better the question is formulated the better chance the answer will be correct. "Garbage in garbage out" used to be the norm, but this doesn't seem to apply to ChatGTP.

Once tested any errors should be redirected back into the existing conversation so the AI has a fair chance to evaluate the code otherwise it's just air code.
 
I asked this Question myself once and tried find out myself. You may download a Demo database of Form Wizard Code from the Link given below:
 
@adhoustonj, sorry for my slightly harsh reply and thank you for clarifying. I acknowledge, there was ideed a case for bringing up the ChatGPT output here.

I'd appreciate the value of you explaining why you think it is gibberish then?
A quick elaboration of my main points:

> The prose text contradicts itself.

"Unfortunately, Microsoft Access does not have a code-based method for creating continuous forms." followed by "... if you need to programmatically create a continuous form in Microsoft Access, you can use VBA..."


> it invented non-existing methods from thin air.

Central part of the intended functionality are the methods Form.AddNewField and Form.AddNewControl. - Neither of these exists.


> It uses methods not available in the context it claims the code is for.

In the VB.Net version of the code, the methods CreateForm and CurrentDb can only be used after adding a reference to the Microsoft Access object library, which was not mentioned. You also need to import the Access namespace, which would be a line of code and is not there. Still you need to reference the Application object to invoke the methods, which the code fails to do.


> Some comments describe something entirely different than the code does.

There is a comment "'Add a form footer" above the code which creates an (incomplete, non-compiling) VBA procedure in the form's module.
 
Last edited:
@apr pillai
I haven't had time to study either of your articles as yet but for info, the download links no longer work in either article
Both show 404 errors
 

Users who are viewing this thread

Back
Top Bottom