I am trying to let an info part's dynamic link work so that it only opens the queried values in a list on the new form.
Basically now, if i click Installation No. on the form part below.
Then this form opens up with all the Installations, not only the related Installations.
What i want to happen is when the Installation No is clicked then the list should look like when the "more" button is clicked or like the image below.
It seems like this is the standard function but i want to know if there is a way to change it.
Does anyone know a solution to this or know if there is any?
Dynamic links should work on info part forms provided prerequisites are met:
A data relationship exists between two tables, usually as one-to-many (one parent row relates to many child rows).
Each table has a field of the same extended data type.
In the parent table, the extended data type field values uniquely identify each row.
The extended data type has a relation defined on it for the field in the parent table.
Each table is a data source for one of the two forms.
The parent form contains a button that launches the child form.
Related
I am trying to develop an interface that binds to a complex backend model. What I need is a way for scripting to enable me to have a page load different page fragments based on what list row a user clicks on. As an example, on the left side of the page there would be a vertical list displaying different sections in a large assessment 'document' (mental health assessment) (each section would be it's own data model [e.g. presenting problems family history, trauma history, etc...). In the main section of the page to the right, you would have room for a page fragment or some type of container that would contain the actual page or page fragments associated with each section listed in the list on the left. When you click on the section name in the list to the left, scripting would be able to have the correct page fragment or page loaded inside the container.
The data model needs to be this complex because there are multiple types of "documents' and the system needs to be able to dynamically load a list of document sections and allow the user to load the form for each section type.
THIS IS FROM Markus Malessa: The dynamic page content is definitely possible, however since it sounds like a lot of your items are going to be based on hard data, the models really are not dynamic, so you really can't build in dynamic data at run time for example. Rather than visible/invisible properties I might suggest navigating to different pages instead and maybe having many-to-many relations to your list item and if your list item has OldFamilyHistory and NewFamilyHistory data relations incorporate a popup to select which page you may want to navigate to.
I have a master/detail relation similar to the relations sample provided.
In my example department has a one to many relationship with employee
I have a form widget(department) which has a button to insert an employee.
when I click on that button the correct dialog form is displayed but I am allowed to enter any department which I do not want.
I am looking to have the relation defaulted to the "parent" widget where it was clicked and ideally not be editable.
It's hard to give an exact answer without seeing your app, but you should probably replace the dropdown in the form with a label, that will make it not editable. You can bind the value of the label to the relation just like the value of the dropdown was bound.
A slightly easier option would be disabling the dropdown (look for the Enabled probably in the property inspector). But that could be confusing for your users since they might think it should be editable.
(Alternatively, you could just remove the field altogether if it's not important to show the relation.)
I think this only answers the "not editable" part of your question, if you want it to be pre-filled you either need to do some scripting, or use relation data sources.
I suggest using relation data sources, so right now you probably have something like:
app.datasources.Emp.create(), which creates a new employee.
Instead, you can use widget.datasource.relations.Emp.create(), which will create a new employee which has a relation to the current item in widget.datasource. If this button is placed in your department form widget, then that means it will create an employee related to whatever department is shown in the form.
Note that none of this stops users from changing the department of an employee, it just changes the UI. In lots of cases that is enough, but you may also want to add some server-side security controls if it's important to limit which users can create employees, change departments, etc: See https://developers.google.com/appmaker/security/secure-app-data
I'm stuck with an issue in the sales order Grid in Dynamics AX 2012 R2. Somehow after adding new columns to the grid via personalization, the newly added columns always shifts to the left side after closing/opening the sales order list page.
Is there any Grid property that handles the arrangement of the columns?
how can we modify the grid columns?
Thanks!
Well, it sounds like an error, this is not how it works for me.
Consider adding the fields to the SalesTableListPage form. The fields are initially (or after reset of user settings) listed in the order in the form grid.
Might look into the list page interaction classes which is responsible for form behavior instead of the AOT on listpages.
more information on the available methods can be found on msdn
https://msdn.microsoft.com/en-us/library/listpageinteraction.aspx
but it is possible for example that a var/isv customization modifies the form after it is loaded
I have four different tables and I want the data from each table to be shown on four different tabs?
Create four subforms, each based on a different table. Place one subform on each tab's page. If your tables are related, you'll need to either base your main form that contains the tab control on a table or query that contains your key column.
While #Joey's answer is certainly the way to place different tables on different tabs, it can lead to a slow-loading form. In general, I prefer to have one subform control into which I can load different forms as required. The user does not see any difference, in that there is not much difference between clicking a button and clicking a tab.
Me.TheSubFormControlName.SourceObject = "frmForm1"
You can also set the link child and link master fields at runtime, if required.
I have a very simple webforms app that will allow field techs to order parts from the warehouse.
Essentially it work like so:
User selects a category from a filter dropdown, which then binds items of that category to a gridview control
User finds an item in the gridview and inputs a desired quantity (in a text box in a template field in each row)
User repeats 1 & 2 as needed
User sees a summary of the complete requisition
User confirms items and submits the requisition for processing
My no-brainer UI design so far is the generic dropdown-above-a-gridview where there's a category drop-down list that filters a gridview, like in the eye-catching asp.net ado tutorials:
http://static.asp.net/asp.net/images/dataaccess/15fig01vb.png
Each gridview row (in my app, not in the image above) lists an item's details and can accept a quantity input in the template textbox if the user wants to requisition that item.
Given that a user will want items from different categories during a single usage session, I'm trying to figure out a good, user-friendly way to allow users to input a quantity for an item, have a warm fuzzy feeling that their input has been accepted/stored, then change the category filter (thus binding the gridview to a different set of data) and select other items from the gridview as many times as necessary before summing up their order and submitting it.
I've thought about putting another grid below the first and adding items to it dynamically as the user selects each item. But that seems awkward. Ditto with an unordered list or similar simple structure under the grid.
I've also thought about just storing the user's picks in view state or session state and displaying a summary on another page, kind of like a shopping cart sort of functionality. Maybe do that and use some sort of ajaxy goodness on the main page to display something warm and fuzzy when a quantity is input?
WWYD? What Would You Do?
TIA.
I strongly agree with your first choice: users need to see somewhere what they have chosen or they will probably keep choosing it over again thinking it failed. Waiting to display it on a summary page shouldn't even be an option. I don't see much wrong with binding to another grid, although a repeater is also a decent option. Well, there are many options. Anyway, if there is room to do this off to one side or another - especially the left- I definitely would, rather than at the bottom. Also, bonus points for enabling users to change the quantities (or delete all) of an item they already selected, wherever you choose to display this.
I like the idea of a search, but be careful with auto-complete. Google style is good where it displays results below, but I've seen people develop some that are way too aggressive and love to write over what you're typing: this is awful. Good luck.
Probably because both your choices are fine - it comes down to personal preference. The shopping cart idea is well known. But sometimes it gets old if you have to keep going back and forth between the cart and the item selection.
What's wrong with the separate grid? -That way you keep the selection list separate from the ordered items list?
Why tie the user to selecting the correct category and then selecting the quantity and hitting a button?
Why not use some type of autocomplete search so they can type in the produce name they want? Then a user could type "widg", get a drop town of choices, hit tab to go to a quantity field, enter a number, and then hit enter.
Display a quickie preview with the aucocomplete too, like as single row of your data.
Then throw all these into another grid at the top of the page if its a critical part of the application, maybe at the bottom if you think the actual grid results are important.
The reason I don't like category drop downs is people who are familiar with their jobs or company usually know the names and even skus numebers for what they are trying to do. Having them select a category instead of typing just slows them down. Also I hate running into the "which category is this?" moment. For example, is a chicken a pet, food, livestock, or food producer?