I would like to do do the following thing:
I know how to use "freeze pane" that allow me to have a fixed part of a spreadsheet (the upper part) and another part that I can scroll.
Is it possible to do this on 2 axes (vertical and horizontal)
Something like this :
If I think I understand what you're looking to do, you could hit the Freeze Panes button on the "some" that is just below and to the right of the yellow limits you have set (Cell H5 ?).
If that isn't what you're looking for, use the Split button located near the Freeze Panes tool.
Related
I want the first node to stay on top and should not be affected during scroll. The first node will be like a column header(stays on top even scrolling). How can I do that?
This kind of behavior is something you can currently find in spreasheets:
Lock first column (Header.Columns[0].Options → coFixed)
Lock first row (?)
I'm trying to insert a picture for more explanation but I don't have 10 reputations. Sorry about that. Thanks in advance.
You can't as VirtualTree doesn't support such a behaviour. Besides, VT already has header support (include hoVisible to Header.Options to show it) why don't you use that? You can custom paint it (see OnHeaderDraw events) if you want it to look like ordinary node.
Is there a text editor which offers horizontal, rather than vertical, scrolling (showing two pages side by side)?
I currently use TextMate, but would switch to any editor which offers this layout. I'm getting really bored of scrolling up and down, over and over.
I've attached a screenshot of MS Word, which has a side-by-side horizontal scroll view for documents longer than a page.
I want something like that, Any recommendations?
Emacs offers a follow-mode which you might find helpful ( see for instance here http://www.emacswiki.org/emacs/FollowMode).
A short description of how it is used and what it does:
You need to open a buffer in two windows and enter follow-mode using M-x follow-mode. This is actually a bit of a drawback, because you need to learn how to use emacs, if you don't know it already (imho learning how to use emacs is worth spending some time).
After entering follow-mode the second buffer will skip to the place where the first buffer ends, similar to the page-by-page view offered by Microsoft Word. Now if you move the cursor down one line at a time and you leave the first buffer window at the bottom, the cursor will appear at the top of the second. If you move further down and you are at the bottom of the second window, both buffers will scroll simultaneously, the same holds for page-wise scrolling using C-v and M-v.
If your monitor screen is wide enough, you can open a third window to further increase number of lines being displayed.
I have made a screenshot, which shows a text file opened in this mode: Screenshot auf Follow mode
Hmmm, it seems you are looking for layout features which you aren't likely to find in a text editor. Text editors are generally line based and don't understand the concept of pages. Text editors do things like code folding and allow lines to be wrapped or not. That is why text editors scroll in the vertical direction. These factors would affect pagination.
The concept of a page (and being able to lay them out side by side) doesn't really exist unless you are using a presentation manager such as a word processor or a desktop publishing package.
In vim: <Esc>:vsplit will open a second column for the file.
In all fairness, I should warn you that Vim has a steep learning curve, and will force you to wrap your head around new concepts like command mode / edit mode / visual mode. The results are definitely worth it, if you have the time to learn it.
I'm not sure if I know exactly what you want. Does Sublime Text 2's two-column layout with File > New View Into File do what you want?
A change on one side is reflected instantly in the other side, and you can scroll them independently. You can have up to four columns per window.
In LibreOffice Writer, go to View -> Zoom... and set Zoom factor to Fit width and height, and set View layout to Automatic. You can also set the number of columns manually, and if you choose two columns, you can use Book Mode.
With scroll-binding in vim, you can edit two files side by side: scroll-binding in Vim.
Show a text file with two columns in vim: http://vim.wikia.com/wiki/View_text_file_in_two_columns
does any one know if there is an example available for sliding panels in jquery? If so, can someone send me a link? This is what I want to accomplish.
On my main screen I want to have three divisions. One right column that covers half the screen and then the left column divided in two rows. I want to expand and/or shrink the right column and/or left column and/or the top row in the left column and/or the bottom row in the left column.
Think og it as an IDE with the left side of the coding area and right side as project explorer and the properties. The coder would like to see any three of the sections at once or would like to expand each working area.
I am looking for a jquery solution for such!
Thanks
Sounds like the way jsfiddle.net works
This is available as a plugin. http://docs.jquery.com/UI/Resizable
You could also use the jQuery splitter plugin: http://www.methvin.com/splitter/
Also see (2011): http://jcubic.wordpress.com/2011/03/06/jquery-splitter-split-container/
Flexigrid is a new (2012) option: http://flexigrid.info/
The most robust solution for this is to use the jQuery layout plugin. You can find it here: http://layout.jquery-dev.net/
Is it possible to achieve a panorama-like scrolling effect in the pivot? I mean instead of flying items in, scroll them in. Like when you use the panorama control and drag the item in view you can already see the next and previous items, but in the pivot you don't - the current item flies out and the next / prev one flies in.
Why am I trying to do this?
Well, as you probably know you can not programatically set the SelectedIndex on a panorama because Microsoft decided to make that property read-only. I have tried several things to fix that including extending the control and using behaviors - but I didn't succeed so I gave up.
Finally I gave up an chose to use the Pivot control instead and it works just fine, except for the scrolling part, where I'd like to have the scrolling effect from the panorama.
Why am I trying to achieve?
A current page overlay. You know, like in the Android applications screen where you can swipe trough a couple of pages and you can see at the bottom / top of your screen on which page you are on (this is the easy part) and also, when you click on one of those bubbles it scrolls to the corresponding page (that's the hard part - because you can't set the SelectedIndex on the Panorama control).
So, any ideas on how to achieve that scrolling effect in the Pivot control? or maybe got another idea on how to change the SelectedIndex on the Panorama? (changing DefaultItem is not a solution).
Thanks.
This sounds way off from the regular behavior of the Panorama/Pivot control so you might want to have a look at the source code and adapt it: http://phone.codeplex.com/
EDIT
In changeset 80787 the panorama control and the pivot control were removed. So to get the code you need to go back to a changeset from before Oct 29 2012.
Is it possible to add gui components to blackberry screen beginning from the bottom instead of the top ?
Thanks
A quick response would be no but let me explain why and suggest afew work arounds;
Screens don't actually handle the laying out of fields onto themselves, to do this they delcare a delegate manager which can be any type of manager, vertical, horizontal etc. The problem is all managers begin painting themselves from the top left. For a manager to paint fields starting from the bottom it would have to know exaclty where the bottom is located and add components up rather than down which goes against all the low level code inside the manager class. You can read more on managers in the BlackBerry API documentation.
You could still achieve an effect similar to this though by tweaking how you add fields and playing with field styles. For example consider this code:
add(new LabelField("field 1"));
add(new LabelField("field 2"));
This would give us the results;
field 1
field 2
because field 1 is drawn then field 2 below it. However if we were always to insert fields at the begining of our manager e.g. position 0 like so:
insert(new LabelField("field 1", FIELD_BOTTOM), 0);
insert(new LabelField("field 2", FIELD_BOTTOM), 0);
We would get the results;
field 2
field 1
Which is the results you'd expect from a screen described in your question.
I'm not really sure how you'd get the fields to paint to the bottom of a screen though, you could try researching the "position relative bottom" styles but I'm honestly unsure.
You are probably using a VerticalFieldManager, and the documentation on that says:
A vertical field manager lays out
fields top to bottom in a single
column.
So if you
manager.add(field1);
manager.add(field2);
manager.add(field3);
The order of the fields on the screen will be just that.
But you could do something like this:
Vector v = new Vector();
v.add(field1);
v.add(field2);
v.add(field3);
for(int i=v.size()-1;i>=0;i--) {
manager.add((Field)v.elementAt(i));
}
Sort of. You can use the Manager#insert(Field, int) method and always insert at the zero index. If you do this with a VerticalFieldManager, it would simulate a bottom-up adding of Fields to the Manager.
Some of the answers so far are to use Manager.insert(Field, int), and keep inserting at position 0. This will work, but the running time of the insert is linear in the number of elements already added to the manager. Meaning this solution will have an overall quadratic running time. Not a big deal if you're adding under 10 fields, but if you're planning on adding more than that, the insert overhead will be substantial.
If you can do the inserts top to bottom, by reordering the fields as Muger's solution suggests, the running time will be much improved.
Finally, you can write your own BottomUpVerticalFieldManager that does the layout the way you want. When you write your own manager, you can layout the fields in whatever way pleases you. In this case, it would be bottom to top. Writing your own manager may seem daunting, but it will give you considerable freedom in the future when trying to solve layout issues.