My app shows long lists of containers and when the user edits the content one of them, the whole list must be refreshed since the content in the other containers may change (they may also change size).
Currently I do this simply by getContentPane().removeAll(), followed by recalculating all the containers, and then revalidate() to show the updated form. However, when I do this the list scrolls back to the top.
How can I keep the same scroll position in the list, eg that the new instance of the just edited container stays in the same place on the screen as before? I know scrollComponentToVisible(Component) but as far as I can see it doesn't allow me to place a container in exactly the same spot on the screen as before the refresh.
Since you rebuilt the position might change so calling setScrollY() directly probably won't provide the same position I don't think that's doable since you need functionality that's closer to scrollComponentToVisible.
Related
Hoping you can help me as I have searched a lot of forums and did not find the same question, never mind the answer I need :)
I have a power point pack which I have put together. It is built to be a template for my team to use repeatedly and is set up using slide masters to control the layout. Each layout slide in the slide master includes two checkboxes to identify either a pass or a fail. My problem is that when you insert a new slide (by either duplicating an existing slide or adding a slide from the slide master layout), and change the checkbox value it also changes on the other slide. Is there a way either using some quick VBA or otherwise to stop this from happening and break the link between the two slides.
Any help would be really appreciated.
In a weird way, this is reasonable behavior from PowerPoint, though it certainly does seem bizarre.
Shapes on a master layout appear on any slide based on that layout. Though they appear on the slide, they're not editable on the slide; it's as though the slide were a clear layer above the layout, one that you can add more stuff to but that you can't "penetrate" to get at the stuff on the layout below.
Placeholders are a special case and so, apparently, are ActiveX controls like your checkboxes, which DO allow editing. So what's happening is that when you change a text box, you're changing the text box on the layout, not on the slide itself (the checkbox doesn't even exist on the slide ... you can't select and move it in normal view, for example, unless you go to the layout in Master view).
When you change the checkbox, you're changing the one on the layout, and since the checkboxes appear on any slide based on the layout, when you change the checkbox, you're changing the one on the layout, ALL of the slides based on that layout get the changed checkboxes.
Some mildly tricky VBA could look at each slide and if it's based on the layout that contains the checkboxes, COPY them to the current slide from the layout and finally make the checkboxes on the layout invisible.
The simpler solution might be to supply a sample slide with the checkboxes ON the slide and let the users copy/paste it into their presentations.
[later]
I've reported this to MS as not so much a bug as a design oversight; the behavior may make sense, but it's not useful and can mislead users (as you well know).
I'd suggest that you visit https://powerpoint.uservoice.com and suggest that ActiveX objects on masters/layouts behave more like placeholders ... spawn new instances of themselves when a new slide based on the layout is added rather than letting the user THINK that's what's happened.
I need to setup a quite huge Application with arround >20 main views plus forms. A mainview will at least contain one grid but can contain upto ten grids. There are also some mainviews that contains a Portal-Panel.
Now it comes that it take quite some time till a mainview opens which don't happends as I tested it with just one instead of >20. The Application lays within a Viewport with fit layout which holds a container with Borderlayout. The Mainview always render within the center while the other regions are used for navigation.
My first approach caching things within a tabpanel
My first approach was to got with a Tab-Panel with hidden tabs. Parallel to that I manage a MixedCollection where I make lookups if the View has already been inserted into the tabpanel or has to be created. If it has already been inserted I fetch the positon from the MixedCollection and run the setActiveTab(). But it seems worthless cause it takes all the same time to insert a new mainview or to activate a existing with setActiveTab().
So what I am doing wrong and how can I make this better?
Edit
The problem seems to come from the rendertime and that the component seems to get reredenred each time setActiveTab() is used. It takes up to 2-3 secs to render a view into the center panel. Therefore I thought I can be speed it up by caching a already created view so that the rendering and sizing didn't need to be done. I guess I should mention that in the north region a menu is also rendered each time, which not get's chached but that shouldn't matter, shouldn't it?
How the views are switched
I have a extra controller that manages the menue-view and the main-view changes. For that the menue gets removed from the container and the new menue is added and for the main-view a lookup is done in the mentioned mixed-collection if the view has already been created and if so the tab-index is received and the tab activated. If not the view get added as new tab and is afterwards added with it's ident and index to the mixed collection.
It may help you to take a look at suspendLayouts() and resumeLayouts()
You run Ext.suspendLayouts(); before you begin changing the views and Ext.resumeLayouts(true) after you are done with all views.
You should also check for overnesting, meaning you have nested to much components into each other.
Example:
If a grid is the only component within a tabpanel then it would be overnesting if you place that grid in a extra panel and then into the tabpanel.
Firstly what I found that non active tabs will be populated anyway. I don't know why. But my stores for not active tabs loaded anyway.
Second, it is really doesn't matter the size of your app. We have a lot of views and everything works pretty fast.
In most cases it is depends:
First is nesting - review your code. Less nesting more speed. For example instead of panel if you dont need all stuff that panel provide- use container. Because all this stuff is add more divs to your dom.
Depends how you create your view. Without your code it is really hard to say, why it is slow. Maybe you create your view every time when you open tab, or go to another view.
As mention #sra try to use suspendLayouts - it means that your browser will render your stuff only resumeLayouts, instead of rerender everything everytime when you add any component.
If you use windows - use closeAction:hide instead of destroy.
Not use Ext.getCmp(). I also hear that refs can slow down application because they start searching your component from the body. But it not proved info :) Use component.down('id'), component.up('xtype') it will search only from your component not from the body.
Not create your view from controller everytime when you do something using Ext.create('Panel'). It means it will created everytime.
Use less global events because this is also slowdown your app.
It is really hard to say what is the issue in your case without code. This is only few point that can help you. But my suggestion to looking to nesting and how and where you create a view.
Before I begin, I'm no SL or WPF master, so I need some guidance. What I have is a List<CustomObject> . I then have a view that I can bind a "CustomObject" to and have all the data displayed. Now to keep intack with the Metro guidelines and Navigation guidelines, I want to be able to use the SL Control Toolkit Gesture Service to detect a flick (this part is done and working). When I flick left, it binds current list position -1 when I flick right is binds current list position + 1.
Now, I need to make it pretty. I'd like it to behave similar to the pivot control, as when I hold down, it moves the grid to the left and when the full flick is created it slides away to the left or right and loads the the next item.
These lists can have 100's of items, so dynamically adding them to a Pivot control isn't an option.
I know I have to capture the OnDelta and start moving the grid, but I'm really trying to find a sample that's similar to what I'm looking for to give me all the peices. There used to be a few custom implementations of the Pivot and Panorama control but I can't find them.
Any ideas that can point me to the right place?
Thanks!
Because you need to create multiple instances of whatever displays your CustomObject I would consider using a Pivot control with three items in it. The three items should be the current item and the ones either side of it.
As the user navigates between items update the DataContext/Binding of the other items so they reflect the itesm next to the one currently displayed. (You'll only need to set one at a time.)
I've used this technique successfully in apps where each page wasn't excessively complicated to load. (When it was there was a lag when navigating quickly between items.)
I have this situation where I have a ListBox which is being populated from a background thread (it's an address book and the data is coming from AD).
The problem is that since the list is sorted (using CollectionViewSource) and also available to the user while more data is being retrieved, it's bouncing all over the place as new items are being inserted at various places in the list. So it's available to the user, but mostly unusable since the user's selections keep going out of view.
Is there a way to keep Focus to the item selected, and preserve the selection, even if items are being inserted above and below the selection from the background thread? I would prefer not to sort on the server, which I understand can be a bad thing when it comes to AD.
I'm going to respond to this from a UI design perspective rather then a technical code perspective. (I'm sure someone else will have a way to have the list box keep the selected item in view)
I would argue that the use of a list box while large ammounts of data is being added to it is fairly impossible to do nicely. Lets just say you do get it to keep the selection in view, what about while the user is still searching for their required item, you wouldn't be able to keep it still then.
Firstly if the expected total load time is under 10 seconds you could just disable the list box until loading is finished. (Obviously grey it out with a spinning animation or something so the user can see it's doing something.) I'm assuming you have already dismissed this option otherwise you probably wouldn't be asking here. But I do think this is worth considering. If the load time is farily small consider if your users will really gain anything by being able to browse the list while it is still being loaded.
Secondly, I would propose that you find a way to restrict the contents of the list box so that only small quantities are every displayed at one time. You could do this by only displaying names starting with a single letter of the alphabet (along with a letter selection control). Or you could provide a filter entry text box at the top where the user could type the first few letters and the list box would only display the names starting with those letters. This would allow the user to type say "sa" and the list box would display "sam", "samantha", "sacha", etc. Now you only have a small number of items in the list so you don't have to worry about it jumping around. If the number of items in the list grows too large (because of the loading on the background thread) and the list goes beyond the height of the box the user can simply type an extra letter to futher filter the list.
Sorry if this isn't really what you wanted, but I thought it would be worth bringing alternative design up incase you'd overlooked it.
I'm developing a Winforms application which has been running for years with an explorer view (TreeView left, screen right). I means that:
All the screens have an hierarchy organization
All the nodes on TreeView have one and only one screen related.
A screen gets activated when a node on treeview gets selected.
One of the advantages is that the user has an ordered stucture and one of the inconveniencies is that with hundreds of screens the user gets confused.
I see other options: use classical menus, use tabs or a mix of everything.
Any advice for a good way to show a lot of screens to user in a user-friendly way?
Update: I'm changed "hundreds screens" by "a lot of screens". The most important thing is not show all at time but that the user can find what they need easily.
Update2: In this proposal, the user only see one screen at time.
Update3: I'm talking about handling multiple screens not showing multiple screens. No MDI, only one ontime.
I have used other applications similar to this is the past, and the major problem is trying to find the exact screen you want. There are two common solutions to this problem, shortcut codes and favorites menu.
With the shortcut codes, allocate a short code (5 or 6 characters) to each screen. The user then inputs this shortcut code into a text box which will then jump to the correct screen. Users will create their own list of often used codes.
For the favorites menu, allow users the ability to be able to create their own menu list in the structure they want. They will find things easier, if they organize it themselves.
Why do you need to show so many seprate screens at once? Why not just show the screen for the currnetly selected node, why are all needed at once?
If it is all tabular data is is probably too much to be consumed all at once, if it is graphical data, could it not be combined?
There may be a valid reason to show all the data at once or there may not, hard to tell from what is provided in your question. With that said, better to keep it simple than overload the user. MDI apps are never easy to use.
Tabs may work for a small set of items but still is not a good UI for hundreds of items.
If you are only showing one element at a time, out of hundreds possible on the tree nodes, then that is fine. The one screen showing at a time would be contextual to the item selected as the user moves through the nodes. Think of the Outlook approach where what is selected in the left pane is displayed in the right pane in whatever form fits the data being displayed.
Have you considered the Office Ribbon?
The Ribbon gives you a lot of flexibility on how to show and
organize functions and it's highly visual.
Here is a good link about the Ribbon and also here
To use the Ribbon you have to license it from Microsoft. You can do that online.
Providing the user with ketboard shotcuts is usually a good thing too.
I also like to provide the user with an "autocomplete" field on the menu
so that they can can find the function by name (or part of it) and be
able to navigate directly to where they want to go.
I general I find trees to be a bad idea, especially if your "hierarchy" is of a small fixed depth.
If you have a small fixed depth, consider replacing the tree with a list. At the top of the list can be drop-downs for filtering based on the node-level properties. It will use up less screen real-estate because it is vertical-only, with no horizontal component.
Clicking on an item can display it in the view (like currently), but it may be a good idea to allow a user to double-click on more than one item which could launch more windows, or tile with the existing displayed items. (I am assuming that currently, the user only sees a single detailed view at once in any given window.)
Actually, it’s hard to beat a hierarchy for organizing large numbers of items. I wouldn’t favor a classical pulldown menu for vast numbers of windows because it would be even harder to keep track of where you are than in a tree (e.g., a tree lets you look in multiple branches at once). But here’s a few alternatives:
I’m not clear how you ended up with so many windows, but maybe it comes from combinations of classes, views, content, and detail, or maybe it comes from using a task-centered UI structure for something far too complex (I’ve more on that at http://www.zuschlogin.com/?p=3). For complex apps, you want a different primary window for each significant class of data object (e.g., invoices, employees). These are listed on one menu, and typically there’s few enough (15 or less) that it can be single non-cascading pulldown menu. The content of each window is set by a separate menu, perhaps by a menu item that opens a dialog that may include a list box (like an Open dialog) or other controls for querying/searching. The “view” of each window (how the data objects are shown, e.g., table versus form) is set by menu items in the View menu. Details for any given object in a window can be shown in a separate pane within the window in a master-detail relation, essentially turning you data objects into a menu for details. A single window can have multiple detail panes for the user to open and close to select the specific detail to show. Tabs may also be used within a single pane to fit subdivisions of content.
You say it’s not important to show all window options at once, but often showing all options at once makes it easiest for users to find what they need. Maybe you need a “home” window that lists all the other windows in organized, labeled, and separated categories. This is will be easier to use than the tree if your users select a window then stick with it for most of the session. Your tree is better if there's frequently selection of windows throughout the session, owing to the overhead of getting to the home window. If all windows/options don’t fit on a single home window, then show only selected common windows for each category on the home window and provide a button or link to show an exhaustive list.
If you’re talking 100’s of windows, maybe you should have Search, perhaps in addition to a menu-based browse approach to getting to a window.
In any case, providing easy access to the few most commonly used windows is a good idea. Such windows can be explicitly selected by the designer, based on user research, or selected by the the user (favorites), but it also typically works well to make it automatic with an algorithm that uses some combination of frequency and recency of use.