I'm getting strange behavior in Access 2007 on a form designed in Access 2003.
I have an unbound main form with a data-bound subform. Within the Form_load of the main form, I set the subform sourceobject, which loads the subform recordset, etc. After the subform loads, but still within the Form_load of the main form, I set Me.FormHeader.Visible = True. After this line runs, for some reason the subform seems to close and reopen -- its Form_Unload fires, and it runs through its load process again.
Any idea why this would be happening? It's annoying, because its recordset is based on a parameter query, and the parameters get zapped when it reloads so it ends up prompting users for parameters.
Sometimes you have to live with (and work around) the behavior of MS Access, no matter how strange or annoying it is.
In this case I would probably advise that you move away from a parameter query and instead prompt the user for their input using VBA, store their input in a form level variable, and use that input to set the recordsource during the subform's Form_Load event. This way the user will only be prompted one time and never need to know that the form actually loaded twice.
Related
I'm working on a Squarespace website in developer mode where I can create the website with code.
In the file site.region, I noticed that I can insert a footer block using this code:
<squarespace:block-field id="footerBlocksMiddle" class="Footer-blocks Footer-blocks--middle sqs-alternate-block-style-container" columns="12" label="{localizedStrings.footerMiddleBlocks}" />
However, I haven't been able to figure out how to insert a form block preferably so that I can set it as email storage.
I tried <squarespace:block-form but that does not work.
The error looks like this on the squarespace configuration page:
"Something went wrong."
How do I write out this code?
What's actually going on in the footer code you mentioned, is that a block field is being inserted. Within that block field, you can add whatever blocks in whatever arrangement you like.
So to accomplish your goal, you'll insert a block field and then add only a form block to it. Then, in other places where you want that form block to appear, you add the block field (containing the form block) into the code.
As long as you use the same id, the same block field will be reused, allowing you to edit the form in whatever area you happen to be in, and changes will affect everywhere else the block field was placed.
<squarespace:block-field id="myFormOnlyBlockField" columns="1"/>
Place that where you want the form block to appear. Of course, initially, you have to add the form block to it and configure it. From then on, adding the code above throughout your site template will show the form, and changing any instance of the block will affect all instances.
Note that I've set 'columns' to '1' in the example above, figuring that you're just adding a single block so no need to have more columns. you could set it to something else and it'd work just as well. Also note that the areas where you add the block field might have a bit too much spacing/padding/margin around it, so you may need to CSS to adjust for that.
Alternatively, it is possible to execute JavaScript within a code block to make an AJAX/Fetch request to the page with the form block on it, and have that form block replace the code block within which the JavaScript is executed. Such an approach would work even without developer mode.
I am a research student working on an access database where I have created a continuous form that is to be used in a sort of scrolling electronic health record format. The header includes information about the patient and the continuous form aspect is a series of patient visits. In the header, I have a few subforms, which populate based on linking on the patient_ID number which is posted in the header (generated by vba macro such that previously reviewed patients aren't revisited). These subforms seem to significantly lag such that they the results from the previous patient stick around going into the next one. The subforms contain user-selected pertinent data. Each form has its own table. They are linked primarily based on patient_ID.
I have tried:
macro on the header detail: on click, refresh. - seems to work, but not very elegant/intuitive
macro on the main form - same as above but on load, click, got focus, lost focus, open, activate -- none of them seem to do anything.
forced requery via vba (see below) on opening/etc of the form. Neither way has worked. Tried to run these on opening the header form.
Public Function RequeryMain()
Dim frmMain As Form
Set frm = Forms("FRM_continuous_reports_patient")
frm.Requery
End Function
Public Function RequeryHeader()
Dim frmHeader As SubForm
Set frmHeader = Forms("FRM_continuous_reports_patient").FRM_continuous_header_working
frmHeader.Requery
End Function
In the end, it is frustrating for users to have to click to clear the form for new entries. It works otherwise.
The end goal is for the form to open and have all the subforms load based on the newest patient_ID. This would likely have to involve a staggered load: (1) VBA script selects the next patient based on certain characteristics and passes the patient_ID to the main form; (2) load main continuous form based on patient_ID submitted to it; (3) load the header subforms and any pertinent data within (although should be blank for the first time these are seen); (4) on completion, back to (1).
From what I understand, this is already how it is working, however the subforms are loading too quickly? How can I fix this?
Hopefully someone can help explain how to remedy this/correct any misunderstandings I have about the mechanics of forms.
I know this will sound odd, but subforms actually load before parent form. Lag in subform display is not something I have encountered. Code should not be needed and likely will not correct. Must be something about the form/subform design, maybe their RecordSource. Would have to examine db to determine.
It is not necessary to create form objects in VBA just to requery. Is code behind the main form? Me.Requery will be enough for the main form. I always give subform container a name different from the object it holds, like ctrPatient. Then just Me.ctrPatient.Requery.
Why not put subforms in Detail section?
To answer your questions, and provide a condensed version of the logic referenced at: https://accessexperts.com/blog/2014/01/07/delay-loading-subforms-in-access/
is to:
In design view, set your subform SourceObject to "" (and save your form)
When you are ready to show the subform, just execute: Me..SourceObject = ""
When you are ready to navigate to the NEXT patient, clear the subform link: Me..SourceObject = ""
Now that should solve the issue of out of sync data between the main and sub.
You don't need to use the CASE statements, but they operate as if you had a bunch of "If" / "ElseIf" all nestled together -- except the CASE makes it easier to follow. It basically gets a value from a variable (i.e. Select Case MyVariable); then checks to see if it equals what you want (Case 1, Case 2, etc.), and if so, does whatever you code.
I would like to ask for your help on the following issue in MS Access.
I had created a form "CustomerListF", filled with command buttons for each client. For each button, I had created the following code:
Private Sub cmd_outlets_ABC_Click()
DoCmd.OpenForm "OrderFormF"
Forms!OrderFormF!Outlets = "ABC"
End Sub
The button would then open another form "OrderFormF" and enter "ABC" in the textbox named "Outlets". However, I realized the second line of code (Forms!OrderFormF!Outlets = "ABC") would always create a phantom record in my subform, which is located in "OrderFormF", and this record would travel to other clients' forms. This phantom record is usually created when the commandbutton is clicked twice (double clicks or subsequent clicks). It is a headache when the record starts to shift around.
enter image description here
I would like to seek your advice for vba code to edit the second line of code.
Thank you.
This approach for filling the field in opened form is not good. OrderFormF initialization and second line of your code with assigning value to the field may be executed in different sequence, they are not synchronized.
In order to avoid this, you should pass the argument to OrderFormF by another way. I would recommend to use OpenArgs parameter:
DoCmd.OpenForm "OrderFormF",,,,,,"ABC"
And then in Load event of OrderFormF assign the value to textbox:
Me.Outlets = Me.OpenArgs
In this case the "ABC" value will be assigned to first row in the form or to new record, if form is empty. Before assigning you can select the row if you need to assign value not to the first row. Also this way will protect you against double click on button, Load event executed only once during first form opening
On a GUI based on forms, I try to open and close some forms in order to do calculations.
I want to do it only with Access macros (for easier maintenance by non-technical personnel).
The problem is not to open and close the forms, I've found a way to do this with:
Close Window
ObjectType
ObjectName
Save: With Confirmation
OpenForm
Form Name: destinationForm
Display
Filter Name
Where Condition
Data Mode
Window Mode: Standard
But when the forms are part of bigger form (that I called Layout for explicit reasons), this macro close the main form and open destinationForm as a new one.
I know this behaviour is perfectly normal, but I haven't found marcos closing subform and opening other ones yet, or, even easier, changing Object Source of the subform object of my Layout form.
A Form is opened in Access as a sub form, if the SourceObject of a SubForm Control is set to it, and the parent form is loaded. So there is actually no such a thing as opening or closing a sub form.
Use SetProperty Macro Action to either set SubForm's IsVisible property, or it's SourceObject Property.
You could also use a Tab Control.
I call a jasper report through an independent URL through which I pass one of the input controls needed to run the report.
E.g. http:// localhost:8080/jasperserver/flow.html?_flowId=viewReportFlow&standAlone=true&reportUnit=xyz&ParentFolderUri=abcd&j_username=xyz&j_password=xyz¶meter1=value1& . . .
As you can see in the above independent URL, I pass the JasperServer username and password, reportUnit name and location and other mandatory parameters, along with the report input parameter, i.e., "parameter1" which can have a value like "value1".
I used a mandatory, read-only and visible input control for this input value. Its value would come from the independent URL, showed in the box but was read-only and hence could not be changed.
The report was working absolutely fine upto this point.
But the tragedy began when my client rejected this idea. He wanted a completely invisible input control to my report and the input value would be passed through the independent URL, just like illustrated above.
And then my client asked me to refer to this and made me work on cascading input controls.
Recently I added a cascading input control to this report. The input control type is a single select query, which utilizes two parameters that I pass to the report through the independent URL.
Now when the Jasper server responds to the independent URL with the input parameters, all the other static parameters work properly, except for the cascaded one.
When I click the select box of the cascaded input, I can see the desired options for a second, and then, it just goes empty while I'm viewing the select list.
But when I make the "Parameter1" input control visible, the cascading input control works!
And then I turn in invisible, the cascading input control turns into a beast that does things by itself and not listen to his master.
I am not able to understand why this is happening. Could anybody please provide me a solution to this?
I have found a temporary solution for this.
I made the "Parameter1" input control visible and read only.
Next, I used a stylesheet and defined a style rule that would affect that input control's display on the web page, making "display: none".
I passed the name of the stylesheet through the URL. So this stylesheet is used for the report.
Now, the "Parameter1" input control is invisible to the end user and my report still runs with no one knowing it's just a fix.