I am printing a details subreport that gets printed let's say 5 times on the overall report, for 5 query results. I compute some stuff for it with my code, and so I use BeforePrint event on an XRTable widget that I have in that subreport. So far so good.
What I don't like is that when the BeforePrint executes for that table for the first time and I change its cells' text to something, that this renders on all subsequent instances of this report and table being printed. Now, obviously, since BeforePrint gets called again, I get the opportunity to reset the text to what it should be. So this is not a show stopper.
Yet, this somehow fills wrong, and an invitation to bugs. Is there a way for me to explicitly access "the instance of the table/other widget being printed" rather than "the widget in general, with changes being rendered in all instances that it prints"?
Indeed, you are right. If the formatting should be based on the earlier created data or summary, formatting rules won't work. A possible solution to this problem is to implement a special approach when a developer manually browses all printing system bricks and changes their content manually. You will find some examples on how this can be done at:
Implementing Page totals
subtotal on page bottom and on next page on top
Related
If the view which serves for creating an item contains some dropboxes / checkboxes / whatever with values from the server, should it send separate requests for filling up those controls with values (one request per each collection of data) or it is better to have a single api endpoint that returns all of the necessary data for filling up the form on front-end?
For the sake of simplicity, I've simulated here an example: Say we're building an app for a car servicing company where clients can make appointments:
Should the front-end app make 2 get requests to api/models and api/services, or these collections can be returned from the server in a single response (from api/appointments/createformdata), What are the best practices regarding to this?
Thank you in advance!
Well, since in your example, both combo boxes need values, then I would load up on first page load. There would be no need for separate requests unless those combo boxes are dependent on data in the form, and then in that case you have no choice but to wait for user input to determine that.
so, say you have two combo boxes, and the 2nd one is cascaded by the 1st combo choice? Well, the first combo box does not change - so load it up at page load time, and you have to do that anyway. No use writing out separate events or code to load that first combo that MUST be loaded in the first place.
however, the 2nd combo box? Well, since its values are based on the first one, then once again, you have no choice, do you?
So, I don't see any real use case, that if two combo boxes are independent to each other, then I see next to no reason why separate requests would be required, and that just loading up both combo boxes on first page load would not suffice here? (then you don't need ANY separate requests).
Now, if there is some kind of tab, or UI and the user can't see nor use the combo boxes right away, or may never even select say some tab out of a tab control? Well, ok, in that case then you speed up the page load by not filling out the combo boxes until such time the user gets to that part of the form (maybe some pop dialog, or maybe some kind of wizard steps).
But, once again, if the two combo boxes are not dependent on each other? Then I see no reason to use two requests or events to load up both of them. But then again, it would beg the question as to how you did in the past load up the combo boxes anyway?
I mean, if each combo box was some ajax call, then keep using two of them, and keep the two requests. Since attempting to merge, or put two ajax calls that fill out two combo boxes as one call is a pain, and does not follow a re-use design patter. The result is messy code, and worse force you to write code that does two things.
I mean, if you build a nice general routine to call + fill out the combo box, then continue to use that code to fill out the 2nd one. I would not blow up really nice working code to somehow fill out two simple combo boxes on a page and attempt to use one request for that filing out of the combo boxes.
And as I stated, if the combo boxes are in plain view from the start of the page load, then code behind on first page load is the place to do this unless some rather huge performance issue were to crop up. As a result, you now don't have ANY separate requests to fill out the combo's, do you?
But then again, a combo box is good for what, 30, maybe 50 choices tops, and after that, you need a different UI, and thus once again, you don't have a problem performance wise by doing this either way, do you?
And if you are trying to fix or avoid a performance problem? Then you putting too many choices into the combo box, and that is the wrong ui choice, and then once again, you don't have this issue, do you?
I have in my application a larger textbox and offer user the possibility to enter text on several rows like this:
first piece of text
second piece of text
and so on...
Each row is a distinct piece of data that has a significance. The thing is I would like to use ajax auto complete extender functionality after the user types a certain character on a row, such as #, and filter the records in the database according to the first letter the user typed after #, moment when the auto complete suggestion list would appear. For example, third piece of text #Action1, means that after the user typed A he would be prompted with a list of values to choose from.
There are several items of concern for me: first, it is possible to use autocomplete extender only for part of the text in the textbox, and second does it work like this for multiple rows (i.e. one time - in each line behaviour)? Regarding its position, I guess I have no other choice than at the bottom of the textbox it refers to, despite I would have liked it to appear below the # symbol.
Thank you very much.
Update: I found something similar to what I am looking for here: Twitter-style autocomplete in textarea, but the author only explained briefly his solution. Any help much appreciated, thx!
Each row is a distinct piece of data that has a significance.
Why are you using a textarea then, and not multiple <input> fields?
Sounds to me like your error in UI design lies right there already, so the rest of my answer is rather theoretical; I probably won’t go into more details as the sensible fix for your problem is the one above.
first, it is possible to use autocomplete extender only for part of the text in the textbox,
Why shouldn’t it be? Cursor position in a textarea for example is readable (although it requires some working around cross-browser issues).
and second does it work like this for multiple rows (i.e. one time - in each line behaviour)?
So long as the line breaks are “hard” ones (made by the user themselves, using enter/return), splitting the actual textarea content by "\n" to have each row as a single value is no problem.
Regarding its position, I guess I have no other choice than at the bottom of the textbox it refers to, despite I would have liked it to appear below the # symbol.
You could try to roughly measure the #’s position, by line and col number it is on, and match that to the character width and line height, when using a monospace font. For other fonts, some more “magic” might be required to measure the actual width of the previous text before the # character.
I have created a Meteor package for this, which allows both free text and multiple autocomplete sources. Meteor's data model allows for fast multi-rule searching with custom rendered lists. If you're not using Meteor for your web app, (I believe) you unfortunately won't find anything this awesome for autocompletion.
https://github.com/mizzao/meteor-autocomplete
See the link for pictures of how it works. Fork, pull, and improve!
I come from the Delphi school. I was really used and pleased with Delphi grids with the plus features of InfoPower. Not just me, my users loves all features that include grids. Some motives for that are:
With grids they have the ability to insert detail information using only the keyboard. Input, Tab, Input, Tab, Input Tab (automatically insert new row), input, tab, etc.
They were able to simply click in a row and edit it´s data.
They could navigate between records using only arrow keys.
In my flex apps I´ve being working arround this quite often, sometimes using a popup to insert data, sometimes using repeater instead of grid. But now I really really need some intuitive, fast way for my users to insert this data.
I am trying to use DataGrid (or AdvancedDataGrid) with inline editors and I am living a real hell to do that. For the last 3 days I am struggling, tweaking and workarrounding in order to try to mimic the features that I had with Delphi.
Main problems are:
DateField simply don´t work as an inline editor. It gets focus but never looses, only with pressing ESC, wich makes me loose the inputed data.
AdvancedAutoComplete: I have a component descendant from AdvancedAutoComplete with a custom browser. The custom browser is a popup, when I try to PopupManager.remove flex raises an exception of a null pointer inside it´s focus managing engines.
I couldn´t get to insert a new line focused in it´s first column when TABing in the last column of last row.
Having all these problems and not getting substantial material to solve them makes me think the (now obvious) fact that it is just not the way grids are intended to work in flex. My question is: what are the patterns used in flex applications to make sequencial, intuitive, fast, keyboard only insertions in a detail?
To answer your question bluntly, there are no specific established patterns to make editing or inserting data in the DataGrid fast and easy. Not being able to Tab between fields is one of the things I really wish Adobe had added to the DataGrid by default.
In order to get the functionality you want, you'll have to do some custom coding and extend/override the DataGrid's default functionality. Switch On The Code has an example up on tabbing between fields, but you would have to build upon their sample a bit further to include features like adding a new row when pressing tab in the last field of the last row in the DataGrid.
You may also want to consider Flexicious. Based on the Flexicious Ultimate demo, it looks like they have the functionality you're looking for (and then some!).
I have a single web page with master detail form/input layout. Currently the form works in a way like
User opens the page containing both master/detail data entry controls and enters the master information (The details save button is disabled)
When he saves the master information, the save master button gets disabled and save details is enabled
User continues to enter multiple details which get populated in a gridview at the bottom of page
All works well
Problem is that, the master part contains a lot of data entry controls (drop down lists gridviews etc)
How do I facilitate the user much more then the current layout? Should he be redirected to a new page after he enters the master record ? How can I improve on this?
If the user doesn’t need to refer to the entire master to complete the detail, and isn’t navigating among multiple masters to view/edit their details, then you don’t need a master-detail, and you can divide the input into two or more windows. A window for the details can repeat a few fields from the master that users need to complete the details.
Assuming it is desirable to keep everything on the same page, I think I see few things you can do:
Use edit-in-place for both the master and detail, so you don’t need space for both editing/creating a record and space to display it. Every field should only appear once.
Pack your controls more tightly together. You can do this without appearing too cluttered if you adopt a quieter visual style (e.g., lose the reverse-video and the rules). Allocate about 20 vertical pixels per single-row control
Adopt an object-selection-action syntax so you don’t need to take space repeating the same command buttons/links for every record. That leaves mores space for fields.
Put your tables in their own panes with vertical scrolling. The tables you have now are already pretty short (5 or fewer rows), but limiting them to 5 or fewer visible rows will keep the window from being too long for cases when there are a lot of rows.
Assuming you have edit-in-place, use wider tables, each set in their own pane with horizontal scrolling in order to reduce the height by moving fields out of the “overflow” spaces and into the tables. Be sure you have row headers that do not scroll away.
Divide fields up into tabs, especially on the master. That reduces the space the master needs to a fraction. You can have tabs within a portion of the master if your users need to keep key fields constantly visible.
Put some fields within the master or detail in expanders or secondary windows, especially for fields the user doesn’t necessary need to interact with (e.g., where usually the default values are correct). Show an aggregate, abbreviation, or summary of what the users don’t see to cue them on when they do need to interact with the fields.
Consider using a “paging” interface for your stack of multi-row text boxes at the bottom of the master so they’re “stacked” in the z-dimension rather than the y-dimension and thus take up the space of a single text box.
Consider using more compact drop-down lists rather than radio buttons, especially for fields the user is less likely to change (e.g., the default is very often correct). A dropdown list is more work to set a value (takes two clicks) but no more to see the value, and you can weigh the editing effort against navigation effort (scrolling, tab-clicking, etc.)
Consider putting the entire master in its own scrolling pane so the detail is always in view at normal window size and the user can scroll the master to whatever portion is relevant for entering details.
If users are telling you that everything in the window must be constantly in view, then you’re going to have to dig deeper, prioritize fields, and make trade-offs because that’s not going to happen unless your client buys everyone a suite of big-ass monitors. Some fields will be out of view, even it that just means scrolled out of view.
There can be various options:
Page may show master and summary (gridview) of details. Save button will only work for master data. Add/Edit details will happening in a modal pop-up.
Have a tabbed view - one tab will show master while other tab will show details. There will be one save button per tab. Tab switching will happen on client side.
Have both master and details always open for editing. Any changes in details will be temporarily held in view-state/session-state. The save button for master will save changes for both master and details. No need to disable any UI.
We typically prefer #1 - IMO, its simple UI from user's perspective.
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?