We have decided to use ExtJS for one of our large application's web-remake and we will have to generate screens/forms where we will have to render about thousand or more controls either in complete editable grid of in forms.
So may I know what is the best approach in doing so?
I have tried generating about thousand controls and it takes about more than 6 seconds on client-side and that too is going to be dependent on Client configuration about which I am positive that it will be at-least dual-core system most of the time.
But more than 6 seconds on localhost is like 10 seconds over the Internet so I am worried, I still have a choice of mixing normal html form/controls when there is high load but then it will miss the ExtJS touch (combo/number controls etc.), so any help or if you had similar experience do share.
Will XTemplate be faster in above case? I am still new to ExtJS so do share best practices if you know/used.
The best approach is not to do it this way. Creating thousands of controls will need huge amounts of memory, no matter how you do it. As you noticed, this makes an application extremely slow.
The solution is to keep the elements on the server and use some form of paging to create only the elements that the user can actually see.
Paging can be explicit ("Load next 10 rows") or implicit by firing an event when the scrollbar hits the right/bottom end and loading more rows.
Usually, you can even hide this from users. Always load a whole row (hiding elements in the same row which aren't visible because the browser window is too narrow usually doesn't help much).
On the server, you will know how many rows you have. Load the first 20 rows and display them. Find the height of the rows (ideally, they should be all the same height) and create an empty DIV below the 20 rows which expands the scrolled view. This makes it appear as if all the rows are there (user sees correct scrollbar which doesn't jump while scrolling).
As soon as that empty div comes into view, load more rows and shrink it.
Related
I've noticed that certain dropdowns, despite having e.g. five different options in the set, only display two at a time, which makes scrolling an inconvenience. On the very same form, another dropdown displays three and a half rows and, as far I could see, there's no relation between the number of rows displayed and the placement on the form nor does such a relation exist related to the number of the elements in the option set.
(How) can I control (or at the very least affect) the number of elements displayed in a dropdown? I didn't find any options for that in the settings (format has only the num er of columns to span across).
Judging from what I've seen, CRM lets dropdowns lower bound expand until the lower end of the container tab. Because of this, one is forced to add spacers (creating "holes" in the form) when the optionset sits at the bottom...
There doesn't seem to be a way to manipulate this behavior, unless one strays outside supported customizations and goes on manipulating the DOM.
Let's start with a confession: I came from a VB6 background, and I'm accustomed to coding within the events of objects on a form, and as such my code for events ends up in somewhat random order in the code window. With this habit, it's never been very important to remember the names of controls (although I name them well)... I just double click on a button in the design view, which brings me straight to the code for that control's primary event. If I forget the name of a control, I click it and view properties. It's not a habit I've moved away from.
Well, now this is catching up to me. Using VS Express 2013, I have a form that contains a HUGE number of containers-within-containers, labels, buttons, and other doohickeys. I ported my code from VS.NET Express 2008 where this wasn't a problem. But now the act of selecting any control in the design view takes around 10 seconds before I can view its properties. If I drag to resize a control, and another 10 seconds passes before I can select another control. It makes designing this form nearly impractical.
In this particular project, I'm using use a tab control (which is never visible to the user) to design many "screens" which each contain panels full of controls. The panels for each "screen" are moved out of the tabs and docked into the main form as requested by the user changing screens. (I'm using the term "screen" to mean a window full of controls, usually maximized.)
Within the same project, a simple modal password-change form isn't slow to edit controls visually, even if the complex form is still visible in the IDE.
My question is in three parts:
First, what the heck is it spending all that time doing?
Second, is there a setting I can tweak to improve the speed?
Third, should I give up on trying to speed it up as-is, and move each "screen" into its own form for design purposes to avoid this slowness? (It's a lot of work to do that now... see next paragraph.)
Thus far I have avoided separating "screens" onto separate forms because I don't want a new window to come up when users change screens, and because code for the controls in one screen may affect the properties of controls on other screens... In such cases I prefer not to write out
form.doohickey.text = "blah"
..but rather keep it as ...
doohickey.text = "blah"
I'm using VB but I don't think this question is VB-specific.)
First off, I feel your pain. I have a management section of the application that I'm writing and I'm using a TabControl as well. I have 10 tabs so far and I've only added controls to about 4-5 tabs. I just added up the controls I have and there are about 360 controls so far on this one form and the designer file is ~3300 lines long. Currently anytime I change a property value of one of the controls or go to save the Designer, it takes about 3-4 seconds each time. I have a fairly decent machine; i5-3320M, 8GB RAM, intel 330 SSD, and it still takes a bit for it to do things within the tabControl. It also takes FOREVER to open and load the designer on that form...
What I've found is that it is easier to open a new instance of Visual Studio, create a test application, add a TabControl with the same properties, and design a new tab page from there. When I'm done I do a copy-paste into my actual project. This works great except for the few custom controls I've written in my main application project, I just have to sit and wait while adding them.
I'm now answering my own question. This is the approach I've ended up using, and it helps a lot...
My overall goal was to have an interface that didn't present a lot of windows, but still presented many different "screens".
I used to place all the different controls of different "screens" on separate panels, which were each contained in separate tabs of an invisible TabControl. I would then move those panels to my main form as needed by changing their Parent property of each panel as needed. The only problem with this is that the Winforms designer got ridiculously slow as the number of controls on a form increased into the hundreds.
Now, I am now designing each "screen" as a separate form, each of which contains a panel whose Dock property = Fill. Such a panel contains everything else on the form. The form itself never becomes visible.
As needed for to view various screens, I execute:
ScreenForm.Panel1.Parent = Mainform
...or, depending on how I lay it out...
ScreenForm.Panel1.Parent = Mainform.PanelXYZ
...I also either unload or hide any panels which already exist in the panel's new container.
I was GLADLY SURPRISED to find that the code for the various events of the controls contained in the panels would still run, because such code exists in the first form's file, not the displayed form's file. Luckily, it seems I was wrong. Event code follows the control itself. I can copy/paste not only controls, but also their corresponding event code to new forms for easier development and a faster Winforms designer.
All of this is similar to a MDI interface with maximized windows, but no title bar or [X] is displayed.
Essentially I'm doing everything as I did before, except using separate forms with panels instead of separate tabs with panels. The WinForms designer is much quicker because there aren't so many controls on any form.
I think I accidently found a workaround for saving a lot of time when changing the name of a control on a overpopulated container/project. Before you change the name, toggle False/True the "Generate Member" property of the control you want to rename(I believe you can also locate this under the "Name" property). This adds a few more clicks to the procedure but saves a lot of time. My not-yet-finished project has over 4000 controls and multiple forms and some of them are very "heavy" (10 - 20 seconds to normally change the name of a control). This, of course, don't help in anyway with the loading time of the project (about 35 seconds for me) but I can live with it. Let me know if this works for you too.
I have a Silverlight 4 app with RIA services. It's based on Tim Heuer's video and I have pretty much the same setup.
I have a DomainDataSource, a set of DomainDataSource.FilterDescriptors, a Datagrid which display 15 items per page with the help of a DataPager. When the user enters their filtering options, the datagrid updates accordingly but is still multiple pages which is okay for viewing on screen. I want to implement a print function that essentially prints the datagrid but all items at once and on multiple pages, if need be.
I have played around with printing basics and I can print the datagrid as it is exactly displayed on screen but I want to be able to print all items.
I'm not finding any good examples on the web. Can anyone suggest an approach to tackle this?
Thanks
Edit:
Not sure how helpful it's going to be but here's the XAML outline.
So one problem will be that when the user says they want to print, you'll presumably then want to ensure all the data is on the client (by executing some larger query), but let's assume you've taken care of that and have all the data on the clien and just want to focus on printing now.
In that case, I'd point you to David Poll's excellent additional printing helpers ( blog post here : http://www.davidpoll.com/2010/04/16/making-printing-easier-in-silverlight-4/ ). He provides a library (with full source) that basically takes an ItemsControl (or lots of other things, but ItemsControl is particularly relevant here) and paginates it automatically.
So you'd create a separate UserControl that has a "print view" of your data, which contains a DataGrid not limited to 15 items, removes paging UI, and basically gets everything "print-ready" (sort of like a print CSS sheet if you're familiar with that concept). Just point his library at that print view of your data, with all the data already on the client, and you should be just about all set.
How many times have we seen this type of selector:
List Box Selector http://geekswithblogs.net/images/geekswithblogs_net/dotNETvinz/MoveItemsListBox.jpg
I was just about to start creating this in a WinForms app, when I thought that others may have some ideas for doing this better. We need it to sort - so the right hand list will need up/down buttons. But this seems so old school. I love devexpress components, and was thinking of asking them if they would consider adding a component that handles this functionality with a slick UI.
I am thinking that a graphical representation of the objects, and a graphical representation of the listboxes - that would be a more intuitive way to move items around.
Has anyone seen an open source project like this?
If a CheckListBox won't suffice (and it usually will), then the "modern" approach would be to use a ListView or similar component with a "Transfer" column. Render the button inline in that column, one for each row, so that it only takes one click to move an item from one to the other.
You see this everywhere in Vista, usually with hyperlinks as opposed to buttons. Instead of clicking on an item and then choosing an action, you click the action at the item level.
I wouldn't go overboard with slickness as it can impair functionality, but the dual-listbox screen is definitely old-school.
Also, if there's a very large amount of data to manage, it helps to provide a progressive search at the bottom of one or both lists.
I have done this type of selection using (essentially) a single CheckListBox that displays each item as an image. Part of the image looks like a LED, which is on (bright) if the item is selected or off (dark) if it is not selected.
This works well if you have a reasonable amount of data to select from, and also works well in a multi-column format if you can predict that the options will have reasonably similar lengths.
Allow users to drag items in/out of list 2, and also drag to reorder in list2.
(All items dragged out of list2, and dropped anywhere outside the list, get put back into list 1, in their correct place in the list by alphabetical or natural order.)
You can merge the two list boxes into one with the help of groups (LVGF_GROUPID flag): one group for selected and one for not selected.
You can also implement group membership changes with drag-drop between them. This way single drag-drop can move an item into the other group at the appropriate position, saving most/all of the other buttons.
Additionaly the bottom of each group can have one pseudo item with help text (i.e. "Drag items here to...") that is visible only when relevant.
I want the ToolStrips to remain on one row, and for the user to be able to rearrange on that row but not create additional rows. I tried using SetBounds on the LocationChanged event, if the user attempted to change the Y position it just sprung right back. However, this created some visual bugs, such as the mouse always jumping back to the location and the ToolStrips jumping around randomly (while dragging one, the other would hop around randomly on the bar...)
I also tried setting the MaximumSize of the toolstripcontainer panel, but it allowed the creation of a new row anyway (in which the toolstrips were hidden.)
EDIT: Its been a few months, still no answers...is this even possible?
I have the same question. Did you figure this out? You might want to take a look at this post. I think it answers your question but I'm just surprised one would have to write a custom layout class to do what I would think would be default behavior for a ToolStrip.