I'm coding a GUI in Python/Tkinter that includes a listbox with a scrollbar. I've gotten the scrollbar operating as expected (i.e. you can click and it scrolls up/down through the listbox contents), but something's off with the way scrollbar itself behaves. The image below should help clarify.
The listbox is sized for 8 lines and contains only 12, so first off the slider should be a lot larger (2/3 of the scrollbar length). Second, whenever I scroll down (regardless of how I do it), the slider stays 'glued' to the top of the bar. This prevents me from ever using the upward fast-scroll method where you click above the slider but below the arrow -- so upward scrolling is limited to using the arrow and going one line at a time. A downward fast-scroll works fine, although as noted the slider still stays 'glued' to the top. I can click and drag the slider down, but then it pops right back up to the top. Clicking the arrows (either up or down) works normally.
I've tried using the alternative scrollbar in ttk, but it's not really any better:
In this case the slider fills the entire bar and you can't fast-scroll either direction, up or down. Grab-and-drag works (somehow), the listbox scrolls but you get no visual cue as to how close you are to the top or bottom. The arrows (again) work normally.
In short it's usable, but just very glitchy and weird. Is all this just a known limitation with using Python/Tkinter on Windows OS? (My machine has Windows XP (32-bit) with SP 3. It's Python version 2.7.3.)
It sounds like you aren't configuring your scrollbars correctly. You have to make a two way connection. You need to configure the listbox to know about the scrollbar (so that it updates the thumb) and you need to configure the scrollbar to know about the listbox (so that it scrolls the contents of tne listbox).
The behaviour you describe makes it sound like you forgot to do the former. Perhaps if you show us your cod we can confirm that. Are you doing something like the following?
my_listbox.configure(yscrollcommand=my_scrollbar.set)
my_scrollbar.configure(command=my_listbox.yview)
Related
I am using MVC for my project. And I have few views in View. However, I want to know how to add a scrollbar to one view and only make that part can be scrolled vertically.
I have tried using CreateWindowW() for adding WM_VSCROLL parameter, but it does not work.
This is a TUI application, so I think the professor try to make us using a cell as bar, so you can scroll the cell up and down
In PreCreateWindow(CREATESTRUCT& cs), set cs.style |= WS_VSCROLL;.
You may have to respond to WM_VSCROLL to process scroll messages.
Sorry for the confusing. I am resisted to use TUI only. And I misunderstood what the professor needed. So he wanted us to move a color cell so you can scroll up and down for checking player's moves. I am making a Gomoku Game by using C++. So I figure it out, right now my move list view can move up and down for viewing full moves. Thanks for all the answers
enter image description here
I want to make my own scrollbars for a custom drawn plot, like this image, what would be the best way to go?
Scrollbars should:
Only be visible when mouse hover over it (with fade in/out)
Be a part of the x/y axis of the plot, like in the picture
Not have any arrow buttons, just the thumb Thinner than the normal scrollbars
Would you suggest to:
Create everything from scratch, handling paging, scrollwheel etc.
Try to inherit CScrollBar and do my own drawing?
From what I've read, it's not very easy to customize scrollbars in MFC, for example here)
First off, these have to be scrollbar (or other) controls, not window scrollbars (used for scrolling a window).
Second, the statement "it's not very easy to customize scrollbars in MFC", is only partially true. MFC is a "thin wrapper" of Windows API, so you should better refer to the documentation of the Windows scrollbar control.
Then there is the CScrollBar class, but took a short look, and indeed, it does not really offer anything more than the Windows scrollbar does. As for the sample in the link you posted is a new (custom) control (painting everything on its own), i.e. literally "from scratch", not inheriting anything from CScrollBar.
So, you have to look into the Windows scrollbar control, and what it offers. Did take a look, and saw few things. Unfortunately there seems to be no owner-draw functionality. You can process the WM_CTLCOLORSCROLLBAR message, but this only allows you to change colors.
And according to the documentation the background color only. This appears to be the only possible customization, apart from the SBM_ENABLE_ARROWS message, which can hide the arrows. And no fading effect. If these are enough to you, you could try the Windows/MFC scrollbar, otherwise try writing your own.
So I am making a Gtkmm application using a Gtk::notebook and during run-time I'm adding new tabs to the notebook. But when I add more tabs than there is space on my screen it just keeps going moving out of the screen.
Now I know most Gtk widgets have a lot of properties that can be configured, so I'am wondering is there such a property for notebook that automatically collapses tabs or scales them in some way to make it fit inside the widget/screen.
If not it would be great if you could give me some pointers to how to implement this functionality myself.
set_scrollable() is your best bet. It will add scrolling arrows on the sides of the tab labels at the top when there isn't enough room to show them all.
Note that GtkNotebook will always ask for enough space to show the contents of all tabs, not just the one that's currently visible. If one of your tab pages is really big (say, contains a 10x10 grid of 100x100 buttons), you won't be able to resize the GtkNotebook smaller than that tab page (in that case, 1000x1000 + the height of the label area), even if the current tab page is just an empty container. All set_scrollable() will do is let you resize smaller than the width needed to show all tab labels at the top.
Put this in your .xml GUI file in the GtkNotebook object:
<property name="scrollable">True</property>
This causes the tabs that go out of screen to be horizontal scrollable by adding arrows beside the last tab at the right and the most left tab at the left.
I have an MFC app that uses Rogue Wave's Stingray Studio Objective Grid to display a dialog with a grid in it. When doing a print preview, the grid uses the MFC print preview mechanism to generate the print preview dialog. On the dialog I see all the buttons you would expect, including next and previous, and zoom in and zoom out. I have more than one page worth of data in the grid and so I see a scroll bar on the right, the Next button is enabled and the previous button is disabled. If I click on the next button, the dialog advances the preview to the next page of the data, and I see the scroll bar move down accordingly, but the Prev button does not become enabled. I can use the scroll bar to scroll in both directions, but the 'Prev' button never becomes enabled and the Next button never disables when I reach the last page. I see a similar problem with the Zoom buttons. I can zoom in, but the zoom out button never enables so I can never zoom out anymore.
Has anyone seen this sort of behaviour before and know what causes it?
So it would seem that my problem boils down to the toolbar not getting messages to refresh itself. It should be getting a WM_IDLEUPDATECMDUI whenever the preview invalidates itself, but it is not. A sample app I found is working correctly and it does get those messages. What I believe is happening in my situation is that My code is in a DLL for an app which I do not control, and when the app catches messages, it swallows certain ones, including this one. I was able to resolve the issue with a kludge. I find the preview window and in the OnPrint virtual function I send the message to it's toolbar. This works quite well, but it is not very pretty.
I have a wxpython application, and I'm using both a toolbar and a wx.glcanvas.GLCanvas sub-window to draw my client area content. The toolbar is vertically just above the GLCanvas. When I roll over a tool and the tool tip pops up, it often (but not always) gets overdrawn by the GLCanvas, so the part of the tooltip that extends into the canvas area gets whited out by the all-white canvas rect. As I say, it doesn't happen all the time -- sometimes the tooltip shows over the canvas area just fine. I assume the difference is just in whether wxpython (or Windows?) happens to decide to sent me a paint message to repaint the canvas while the tooltip is shown. But even if the canvas is repainted, you'd think it could just respect its z order and repaint under the tooltip. But I realize opengl canvases might be special in not playing nice with the window z order.
Any suggestions for a solution or work-around? I was hoping to be able to tell the tooltips to show above the tools instead of below them, but there doesn't appear to be a way to set that.