Is there any way to change the behaviour of the scrollbar inside qcombobox?
The behaviour is:
position of the scrollbar corresponds to the pointer position of the record in the dataset. While changing the position of the scrollbar the records are added and removed from the combobox.
So it becomes possible to browse the dataset (~1000000 records) but without adding all the records to the combobox (it's very slow after 1000 records).
The standard Qt way of doing this is with a QAbstractItemModel to populate the portion of the view that is visible.
That said, I'm not sure you have fully considered the implications of a combobox with 1 million items from a user interface point of view. That many items and your users will have difficulty finding what they are looking for. To make this usable, you would probably need a way of sorting or categorizing entries in a way I don't think QComboBox provides. There must be a better way. That question might be better suited for the guys at http://ux.stackexchange.com, though.
Related
I know that topic about multi-select arise at least once, but honestly neither can't find it anymore, nor remember that it had and decent solution.
There are two questions I propose to discuss:
1) Creating a behaviour similar to MS Excel cell's selection. So user click one cell in QTableView and gets clicked cell highlighted and in additional several 'dependant' cells change appearance (get selected or just gets highlighted in any way). In Excel it's widely used to show cell formula dependencies.
I know there are several approaches to solve it. Most simple one is to modify view selection with dependant cell in any of appropriate signal handlers (for example QAbastractModelView clicked()). That way does the job but has ugly side effect, that due to fact that signals delivered after redraw of selected cell occurs so dependant selection is drawn after first cell which produce flickering.
Second approach is go Delegate way.. That's also have some issues because you get paintEvent only for selected cell, so there is not that much you can do about 'dependent' cells. Actually I was able to solve it through this way, by catching on-click, modifying selection and using completely custom delegate which draws everything as soon as complete selection is formed, so actually it skips first redraw, but again I wasn't completely satisfy with results although visually it looked completely right.. mostly because overall TableView response time decreased a lot. Reasons for that is Qt draws native selection right after mouse click received before sending any signals to user classes and in case of this approach paintEvent in delegate arrives after several main loops. So there is a noticeable delay in case of using 'draw selection in delegate' in compare to 'draw native selection'.
I am already starting to think that best option can be completely overwrite most of QTableView to add support for such selection schemas, but may be there are more straight approach?
2) Second question (I put them together because there are something common issues).
Let say you have a grid representing financial information by months and within a month there are several columns of information, so block of N columns repeated M times. Obvious way to make such grid more readable is to use different style for vertical lines in grid for first data column in each month. Let's say to make them 1-2 pixels wider.
As you cannot specify grid style per cell, what I did was to setGrid(false) and then draw my own grid lines as a cell content in delegate.
But then I faced a problems from point 1. Then you instruct Qt to use delegate on certain cell, before delegate will get a paintEvent Qt clears a background of the cell. And in case of hidden grid the background rect which Qt clears is one pixel bigger then required. Probably it can be consider to be a Qt bug because they dont respect grid visibility, but this results in removing grid lines in neighbour cell, so you have to draw in delegate not only cell own grid, but also recalculate proper cell rectangle, check if Qt made a mistake (by analysing QPainter rect), decide if whats being removed from neighbour cell needs restore and repaint it also. This leads to really complicated delegate logic and I cannot consider it to be a decent solution.
So question 2 can be rephrased as do we know a decent way to style a grid per cell in QTableView?
OMG,so many words,can you just pick the most important info?
I'd do something like that:
Create a delegate. Subclass QAbstractTableModel and reimplement data method. Your implementation should return cell text for Qt::DisplayRole, but also can return whatever you want if role is one of your user-defined roles (like font or color or whatever of cell's text. You can use any role number above Qt::UserRole). Your model should emit dataChanged signal to notify QTableView that the content is changed and should be redrawn.
Then in delegate you just request this data using your overloaded QAbstractTableModel::data and draw it the way you want.
I'm having a QTableWidget with 10,000 records. I need to show only 30 rows at a time and hide the remaining rows. While dragining/clicking vertical scrollbar it should show corresponding rows and hide the other rows.
ie, if one clicks on upper scroll button it should show one more upper item and hide one lower item and vice versa. It should happen while scrolling as well.
Can anyone help me in doing this?
I think you can trap the events of up/down buttons as Nicholas said, for the tracking of slider/scroll bar u need use 'setTracking(true)'followed by the handling of signal either 'valueChanged(int)' or 'sliderMoved(int)'.
Thanks,
Pradeep
Qt unfortunately won't make this easy for you, there is ways and means of doing it however. Depending on how you're populating your widget I'd recommend setting it up so you initially populate your 30 rows, you then need to trap the signals coming from the scroll buttons being clicked and tell the table widget to remove the upper/lower item and add the next one, there's trade off's to this method, but it'll make it easier than trying to maintain a large list of hidden rows.
I don't know if explicitly showing/hiding things is the way you want to go. Instead, take a look at Qt's model and view classes. If you are using a database, have a look at QSqlTableModel, which should handle these things for you. Otherwise, have a look at the Model-View programming document, their related examples, and especially the portion about optimizing for performance (although in a model, 10,000 records isn't really all that many for most uses).
There is a way to change table scrolling from pixels to items. In Designer Property Editor for the table, in the QAbstractItemView section, there is a VerticalScrollMode selection. This can either be ScrollPerPixel or what you probably want, ScrollPerItem.
That may change the behavior of the signal from pixels to items which would make your calculations easier.
I'm using 4.4.3.
I've been toying around with Qt and ran into a small issue.
I want to display a list of pictures as a table of icons. Right now, I'm doing this by subclassing QAbstractTableModel, and plugging it into a subclass of QTableView.
This, in my opinion, overly complicates the code, the model and the view (especially when trying to edit/append items). When trying to implement the model as a QAbstractListModel, the items are displayed as table rows.
Is there a way to make QTableView display items as columns, instead?
Edit: Such that the items are rendered in a single row from left to right, and wrapped to a new row.
Or is it preferable to use the table model for table views in any case and work around the issues?
It's worth mentioning I'm using C# bindings for Qt based on Qt Jambi.
The QListView has exactly the functionality you are talking about.
If you don't need any functionality specific to QTableView, then I would suggest switching.
If you set "isWrapping", then the list will start from the top, go down to the bottom, then wrap to a new column.
Set "flow" to LeftToRight to display the list in rows instead of columns
You might also need to set "resizeMode", instead of Fixed, to Adjust. Which will automatically move things around when the list is resized.
Hope that helps.
Just as a side note, here is FlowLayout example. So if you just want to display a set of images in a self-adjusting grid, this would do it for you without all the overhead of a list/table. However, it doesn't give you any selection/editing capabilities or anything just layout.
I don't understand something here. You implement TableModel, so you can prepare data for view in the most desirable way. Suppose you have data A,B,C,D, then you can return A(00),B(01),C(10),D(11), or for example A(00),C(01),B(10),D(11). Is it what you want to do?
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've got a flex app with a DataGrid with several columns (defined in the MXML file), and I need to "introspect" the grid columns. That is, I need to write some ActionScript code which, given the DataGrid object, can determine various things about the grid (and more specifically, the columns of the grid).
In particular, if a column is just plain text output, I don't really care about it... but if it's got "actionable" controls within it (checkboxes, linkbuttons, etc) I do.
First, I'm assuming that columns which contain "actionable" contents will be within <mx:itemRenderer> tags (else it would just be plain text); please let me know if this is incorrect.
Next I need to "dig down" into the structures, pulling the AS object corresponding to the <mx:DataGridColumn> out of the <mx:DataGrid> (I've got this), then pulling the AS object corresponding to the <mx:itemRenderer> out of the mx:DataGridColumn (two diff ways to do this; neither seems very useful), then pulling the AS object that corresponds to the <mx:Component> out of the mx:itemRenderer (if any; it's unclear to me whether the mx:Component actually creates an object), and finally pulling the AS object corresponding to the <mx:LinkButton> (or whatever) out of the mx:Component.
Does anyone know how to do this?
P.S. I understand that there's almost no limit to what could be lurking within the itemRenderer; if I can dig down that far, I'm willing to test for a handful of things that I expect and ignore the rest.
To clarify somewhat, I've been asked to provide Section 508 compliance (accessibility) to an existing application. There are a lot of pieces to this, of course, including screen readers, etc... but one of the first steps is making sure that the application can be used without a mouse.
Many of the existing screens have a UI technique consisting of a DataGrid with item renders which place controls like radio buttons and linkbuttons and whatnot into the cells (same type of control all the way down the column). All well and good, except I can find no way to interact with these controls via the keyboard.
So, I modified one screen to have a hot key which pops up a context menu, allowing the user to arrow up/down among the actionable items, and press ENTER to choose one (toggle the checkbox, press the linkbutton, etc). But this was screen-specific, and it will be too easy for someone to update the screen (e.g. adding another actionable column) and neglect the menu.
A better (?) approach was suggested: subclass the data grid, introspect to find the actionable columns, build the menu automatically, and now all we have to do is swap out the SuperDataGrid for the DataGrid, and our screens will be 508 compliant.
If someone can recommend a better way to make the screens 508-compliant (without redesigning the UI) and with minimal per-screen effort, I'm all ears.
Maybe I'm not being clear enough, since you keep missing the point, so let me try again.
I'm NOT writing application-level code... if I were, I'd know exactly what the logic is doing and I'd be able to use the bound data in the normal way. In fact, the application-level code DOES use the bound data in the normal way. But that's totally beside the point.
What I'm TRYING to do is write "infrastructure-level" code: that is, code which runs "below" the level of the application logic. I'm trying to effectively add a feature to DataGrids which Adobe should have included, but didn't. If I can get this class working, it will be possible to just drop it into dozens of screens WITHOUT ME, AS THE CLASS AUTHOR, KNOWING ANYTHING ABOUT THOSE SCREENS OR THE LOGIC WITHIN THEM. The only way I can imagine this working is to look into the datagrid and discover, at run time, what types of controls lurk within it, and possibly what they're bound to (actually, I can probably just execute whatever the click="foo()" attribute says to do, and I won't need to know what they're bound to).
Does this make sense?
Is it possible?
Item renders interact with the outside world through their data property. They should render the data as desired and make changes to data as required. They should not reach outside and you should not try to reach in to affect an item renderer directly.
As far as the underlying problem you're trying to solve, you haven't stated it at all. You're describing a desire to follow through on a particular solution only but haven't described the underlying problem. What are you really trying to accomplish? Don't talk about getting access to item renders or digging into the DataGrid, but what interaction or affect on the rows do you want? The problem is your approach is somewhat backwards and that's why it's not working out.