I created a form in ACCESS based on previously created table that was empty. Before any cosmetic changes to the form I was able to add records, and using the little < > buttons at the bottom of the form, I was able to scroll through the data in the table. I then made some cosmetic changes, changed the tab order, and now the scrolling buttons don't work. Are they supposed to work on a data entry form, or do I need to add controls for scrolling.
Related
I am working on an Angular app where a user clicks a button which causes data to be added to or removed from the data source of a table elsewhere on the page.
When the user clicks the button, data is fetched and added to the table's data source. So it now has a new row.
I am trying to make this accessible to screen readers, for example they might speak "row added" and speak the row's contents.
Can this even be accomplished?
I have a MS Access form that is bound to a query in the database. I added a textbox and added a row source to a Hyperlink datafield in the query. When I open the form, it won't allow me to drop a file into the textbox.
Here's the deal. When I follow this EXACT same process on a new form, it works perfectly. That is, I open a blank form and I bind the form to some new query, let's say qryNewIdeas. Then on the blank form i add a textbox, let's say Text0. Then, when I select Text0, I go to the data tab - row source and choose the dropdown arrow to select the hyperlink field, lets say NewIdeasAddress. I click SAVE and open the form. It works PERFECTLY.
BUT, when I repeat this on an existing form (the one where I need the thing to actually work), it does nothing. It adds and changes the textbox to a hyperlink box (I note this because of the blue underlined word that appears in the box). But it won't allow me to drop files to this location.
I tried commenting out ALL of my VBA code to try to make sure that something wasn't hindering it (say in an OnLoad event) AND I've checked all of the form and control box properties and they seem to be the same in both the existing form and the test form.
I can't determine why it works on one form and not the other; Solution needed.
If you have access to "the data tab - row source ..", you are in design view.
When you later open the form, you are in form view, a completely different animal which specifically prohibits design changes.
It sounds like you will have to rethink your concept.
This is an ongoing problem, and I'm hoping there is just a property that I'm missing.
Scenario: I have a form that contains subforms. The Default View property for the subforms is set to Datasheet. (The main form is set to Single Form). Due to changes in what I'm tracking, I want to include another field that wasn't part of the original record source. So, I changed the record source (a query) and added the field to the subform. The new field is added to the end of the Datasheet view by default.
Here is the problem - when I drag the column to a new location on the subform (in Form view or Layout view), it does not stay put. I have made the change using Form view and Layout view, and I've changed the Tab Index property for the field to the proper number. The new position never stays on the first, or second, sometimes third and fourth try. I have tried saving in Form view, Layout view and Design view, but I always have to drag the column back to the new position and try to save again . This goes on until Access actually saves the change. drag, save, didn't take; drag, save, didn't take; drag...
What I'd like to know is this - how do I rearrange columns on a form that is set to "Datasheet" for the Default View property, and make it stick the first time?
Thanks for any suggestions - I must be missing something....
This is a known "limitation" of datasheets. Some want the columns fit or preset, other sticky, some either as selected by the user.
To control the order of the columns, adjust the ColumnOrder property of the displayed controls.
I'm creating an Access database for data entry, so I put together the form shown in the image below. It works great besides one problems I'm having that I can't seem to nail down.
I want to create a form that navigates by hiding and un-hiding subforms when clicking the buttons in the top bar. The subforms themselves are linked directly to the table (not a form, but the table itself). I did this in order to have an easy way to enter multiple entries in an excel like fashion that the users are familiar with. Entering the data works fine. Closing the form and re-opening it however causes the subform to show each individual record and the record navigations must be used to cycle through each one.
The intention was for the records be shown in the same fashion as if I just opened the table. Is there any viable way to accomplish this?
I am creating a page and the page has an editable data grid (I'm actually using jqgrid). The user can add, delete, and edit the rows of the grid. There are also some other form fields on this page such as text boxes and drop downs, but they are not part of the grid.
From a usability perspective which of the options do you think is best and why?
User manages the grid separately from the rest of the page. This means that there is a save button on the grid. So the user can save a grid row to the db without clicking the submit button. When the submit button gets clicked, the non-grid form fields get sent to the server.
user manages grid and other fields dependent upon each other. This is like an "Everything or nothing scenario." When you click the submit button, all of the form fields get submitted an saved the db along with the grid fields. If there is a validation error, nothing gets saved.
If there is a better way to handle this type of situation that I did not list, please let me know.
What I was thinking when I was in a similar situation, is how important it's that the user fills the other form fields. If they are optional and the grid is more important I would have the submit button in the grid but if I want the user to fill all the fields, the button should be at the end. In the case where the button saves the whole form, you can have a type of warning if the user skips some fields or you can have a deactivated button.
The second thing I thought was the height of the page. If the button hides 'above the fold' there is a high posibility that some users won't see it and the data won't be saved. So in that case, maybe you should have it in the grid. I would check analytics about screen resolutions.