using infopath 2010, sharepoint 2010
To do - I have 3 view forms and in first form i have checklist of information when i tick/select it should appear in third form which is repeating table.
Step1
what i did is create a set field rule if checklist A is true then repeating table equal 'A' it only work for one selection from checklist if more than one select the answer is still one selection in repeating table.
Step2
created the data connection of datalist in sharepoint connected with infopath repeating table but doesn't work
so how to autoupdate the repeating table by selecting the checklist of information, kindly guide me.
thanks..
To do this it takes a little bit of coding - I don't believe there is any way directly in the interface (rules/conditions/etc). You found out the drawback pretty quickly - the rules only populate the first item. It isn't a huge pain but isn't exactly easy.
What you want to do is use the "changed" event for the checkbox list and have your code manually update the form XML (add nodes under the repeating section). They will automatically show up on your form as you manually change the XML.
It is a bit of work but comes out quite nicely. Only try to implement it if you really need the functionality and know a bit about infopath and coding. We used the technique to create a "summary" list of many separate checkbox lists.
Related
I am brand new to Apache Isis but was curious to know one thing. My work depends alot on filling forms but the forms should be able to handle conditional rendering of UI elements. For example a form can ask the question 'how old are you?', and if the response is above 18 years the following question is 'did you vote in the last election?' whereas if the response is below 18 years the following question is then 'are you working or studying?'. So elements rendered depend on previously answered questions, is this possible in Apache Isis?
Thanks
The short answer is no, not particularly easily.
If you use an action prompt then you can easily tab through multiple fields (these being the argument values of the action) but the framework currently does not support the hiding of argument fields based on preceding fields. We have an idea of how to implement this, but it has never got particularly close to the top of the "to-do" list.
Alternatively, you could use a view model to represent the form being filled in. Here a view model does support optional hiding of fields - this time they are properties of the view model. The caveat here though is that each property is entered individually from the next (similar to how JIRA works); the user cannot just tab through multiple properties.
HTH
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I want to present a list of data in an Access query and highlight specific rows which contain certain text. I also wondering if there is any great way to sort up, lets say "Transports" with different orders in groups with spaces between every unique transport.
I believe that I have to make a query and build a form for that with a bunch of macros? Or is it there any easier ways to go? Maybe any great guides similar this to follow? I'm kinda new on Access :)
Thanks for all the help, Cheers!
In Access you first design a database model by creating tables representing your entities and setting relations between them.
Then you create forms and reports based either directly on your tables or on queries. Tables and queries will very rarely be presented to the user directly in an application. This is very different from Excel, where a worksheet is the "database", the business logic (calculations), the user interface and the report at the same time. In Access you separate the data holding from the user interface (data input and reporting). It is also a good design principle to place the business logic in modules and class modules instead of "behind" the forms. Access is an application development environment and not just a tool for entering data.
In forms you can set the Allow Datasheet View property to Yes and the Default View property to Datasheet in order to simulate a table. In the TextBoxes you can use conditional formatting (Menu Format > Conditional Formatting...). Here you can define up to three conditions and formattings that will be applied when the condition is fulfilled. Together with the base formatting of your TextBox this gives you four possible looks for each column.
Grouping in forms is not possible; however, in reports you can insert several nested grouping levels and insert group headers and footers.
I have a table consisting of three columns; the first is an ID, the second describes the activity assigned to that ID and the third defines the category that the activity falls into. I have a combo box, which contains a list of all of the categories lifted from another table. I would like to have a second combo box, which, on selection of a specific category, allows the user to pick an activity from that category.
My knowledge of access and databases is quite limited, so any help would be appreciated.
This is a fairly complex thing to actually do, but it is doable. If you're dead set on it, it will require learning a bit of both VBA and SQL. You essentially need to write VBA code that will first define SQL queries as a string based on your choice in the comboboxes and then passes that string as the source of each following combobox.
If your experience with access and databases is limited as you say it is, you may want to opt for a simpler solution for the time being. If you want to see more in detail how something like this would work check out http://www.fontstuff.com/access/acctut15.htm
There is a walkthrough here at MSDN on synchronizing two comboboxes. It is a common feature so internet searching will locate other similar examples.
Is there a quick and easy way to make a VB.NET user interface for managing the data in a normalized DataSet?
I know that is a very subjective question, so let me explain. For a brief period early in my career, I used to create user interfaces in Microsoft Access. I developed a simple, but very effective approach to user interface design. Here are some details of that approach:
Create one form per table. Put on
each form all controls necessary to
completely manage one row in the
table.
Use combo boxes for
foreign-key columns.
Give the user a
standard way to add rows and delete
rows.
Use Apply and Undo buttons.
Let
the user navigate from one row to
another with a list box.
Provide a
search box and filter options for
more efficient navigation.
Let the
user double-click on controls
representing foreign-key columns to
quickly navigate from one form to
another.
Make the state of each form
persistent (so the user always
returns to the last navigation point)
etc.
Simple, right? I found that Access encouraged this approach. It has many built-in features that make this kind of UI easy. For instance, creating a combo box to represent a foreign key relationship takes about 10 seconds.
Well, I haven't worked in Access for a while. A couple of years ago, however, I was hired to write an application in VB.NET on the NET 2.0 framework. To get a data management user interface up and running quickly, I used my Access experience to write a quick & easy prototype in Access -- that took me about one week. Then I hired a programmer to implement that same UI in VB.NET. What a nightmare! We've been working on that implementation for a year, and I'm still very unsatisfied with the results. Some of the problems we are having:
Apply and Undo buttons don't work quite right. We can't find an event that tells us when the form is "dirty" (thus making Apply and Undo relevant).
Navigation from row to row and from form to form requires surprisingly complicated code. I get the impression that we are fighting against NET's binding features, not working with them the way they were intended to be used.
The NET controls seem buggy. For instance, when the user types a value into a combo box (as opposed to choosing it from the drop down), it doesn't trigger the SelectedValueChanged event.
We seem to be repeating a lot of information. For instance, the DataSet knows there is a relationship between the columns in two tables, but we must nevertheless effectively repeat the details of that relationship when we program the combo boxes, binding, navigtation features, etc.
We still don't have good solutions for the filter and search features. There are lots of little details to work out. (For instance, what if you choose a filter that doesn't include the currently displayed row?)
We are writing many helper functions and classes to simplify the work, and I can't figure out why that effort hasn't already been done by others -- I'm certain we are reinventing the wheel.
etc.
By themselves, none of the above are a big deal -- there are effective solutions to each one. Taken together, however, these problems are making my UI development go much slower than expected.
In an ideal world, I should be able to create a small amount of code relevant to my specific data model (for instance, one user control per table establishing the layout and logic relevant to the rows in that table) then integrate that code into a template which interprets the data model and handles everything else -- navigation, adding and deleting, apply and undo, search and filter, etc.
Thus, my question: Is there anything out there which makes this type of UI development easier?
I've searched the web for various combinations of "generic forms", "UI templates", "data managment forms", etc., but I haven't found anything on topic. Perhaps I just don't know the buzzwords. Is there a specific name for this type of UI development task?
Create UCs for each table. Drop a grid control onto the UC and bind it to the tables dataset using VS's wizard. Select the options that allow for insert, update, delete. Each row on the grid will have those buttons/actions automatically added for you.
How would you create a database in Microsoft Access that is searchable only by certain fields and controlled by only a few (necessary) text boxes and check boxes on a form so it is easy to use - no difficult queries?
Example:
You have several text boxes and several corresponding check boxes on a form, and when the check box next to the text box is checked, the text box is enabled and you can then search by what is entered into said text box
(Actually I already know this, just playing stackoverflow jeopardy, where I ask a question I know the answer just to increase the world's coding knowledge! answer coming in about 5 mins)
My own solution is to add a "filter" control in the header part of the form for each of the columns I want to be able to filter on (usually all ...). Each time such a "filter" control is updated, a procedure will run to update the active filter of the form, using the "BuildCriteria" function available in Access VBA.
Thus, When I type "*cable*" in the "filter" at the top of the Purchase Order Description column, the "WHERE PODescription IS LIKE "*cable*" is automatically added to the MyForm.filter property ....
Some would object that filtering record source made of multiple underlying tables can become very tricky. That's right. So the best solution is according to me to always (I mean it!) use a flat table or a view ("SELECT" query in Access) as a record source for a form. This will make your life a lot easier!
Once you're convinced of this, you can even think of a small module that will automate the addition of "filter" controls and related procedures to your forms. You'll be on the right way for a real user-friendly client interface.
This is actually a pretty large topic, and fraught with all kinds of potential problems. Most intermediate to advanced books on Access will have some kind of section discussing "Query by Form," where you have an unbound form that allows the user to choose certain criteria, and that when executed, writes on-the-fly SQL to return the matching data.
In anything but a flat, single-table data structure, this is not a trivial task because the FROM clause of the SQL is dependent on the tables queried in the WHERE clause.
A few examples of some QBF forms from apps I've created for clients:
Querying 4 underlying tables
Querying a flat single table
Querying 3 underlying tables
Querying 6 underlying tables
Querying 2 underlying tables
The first one is driven by a class module that has properties that reflect the criteria selected in this form, and that has methods that write the FROM and WHERE clauses. This makes it extremely easy to add other fields (as long as those fields don't come from tables other than the ones already included).
The most complex part of the process is writing the FROM clause, as you have to have appropriate join types and include only the tables that are either in the SELECT clause or the WHERE clause. If you include anything else, you'll slow down your query a lot (especially if you have any outer joins).
But this is a big subject, and there is no magic bullet solution -- instead, something like this has to be created for each particular application. It's also important that you test it thoroughly with users, since what is completely clear and understandable to you, the developer, is often pretty darned mystifying to end users.
But that's a principle that doesn't just apply to QBF!
At start-up, you need to show a form and disable other menus etc. That way your user only ever sees your limited functionality and cannot directly open the tables etc.
This book excerpt, Real World Microsoft Access Database Protection and Security, should be enlightening.
For a question that vague, all that I can answer is open MS Access, and click the mouse a few times.
On second thought:
Use the "WhereCondition" argument of the "OpenForm" method
If the functionality is very limited and/or specialised then a SQL database is probably going to be overkill anyhow e.g. cache all combinations of the data locally, in memory even, and show one according to the checkboxes on the form. Previously you could have revoked permissions from the table and granted them only on VIEWs/PROCs that queried the data in the prescribed way, however security has been removed from MS Access 2007 so you can you now really stop users bypassing your simple app using, say, Excel and querying the data any way they like ...but then isn't that the point of an enterprise database? ;-)