I'm trying to display multiple columns with a wxTreeListCtrl. I'm using wxWidgets 3.0.5 and developing with GTK, although I'm intending to use this code in OSX and Windows.
The screenshot below shows what I'm seeing (the application is a file browser, in case that's not obvious). The first column, Filename, is always sized to the width of the tree view. The other two columns are pushed off the right; you can see the scroll bar.
If I manually resize the window, the two columns pop into view, which makes me feel that the tree view hasn't been laid out properly, but the right-hand column's manually set width is always ignored and as I continue to resize the window it gradually gets larger and larger.
I've tried manually setting and getting the column widths, and it appears that the tree view control is mostly ignoring the numbers I give it --- if I call SetColumnWidth(...) and then GetColumnWidth(...) immediately afterwards, I get either 0 or an incorrect number.
The actual code is trivial --- this is all generated with wxformbuilder, so I'd expect it to work:
browserTree = new wxTreeListCtrl( browsePanel, wxID_ANY, wxDefaultPosition, wxDefaultSize, wxTL_MULTIPLE|wxBORDER_THEME );
browserTree->AppendColumn( wxT("Filename"), wxCOL_WIDTH_DEFAULT, wxALIGN_LEFT, 0 );
browserTree->AppendColumn( wxT("Size"), 100, wxALIGN_RIGHT, 0 );
browserTree->AppendColumn( wxT("Mode"), 100, wxALIGN_LEFT, 0 );
(I should add that this behaviour manifests in the wxformbuilder GUI viewer, too.)
The main thing which makes me suspicious is that the widget hierarchy is pretty complex, so it's possible one of the parents is doing something to upset the tree view, but I've tried moving the tree view into a new box sizer in a new frame and exactly the same thing happens there. But there's a screenshot of the hierarchy below in case that helps.
I have found some very old bugs describing this behaviour (e.g. this one: https://github.com/wxWidgets/wxWidgets/issues/17476) but they're all really old and have been fixed anyway. If this were a real bug I'd expect to see a lot more complaints, as it makes the widget essentially unusable; therefore, this must be something I'm doing wrong, probably something really basic.
But what?
Welp, five minutes later I have an answer. I'm going to post this here in case someone else has the same problem, even though it makes me look really stupid.
Short version: it is that five-year old bug I found. It's just that the version of wxWidgets on Debian, which I'm developing on, is so old it hasn't picked up the bugfix.
The good news is that wxWidgets 3.2, which does have the bugfix, is being packaged right now (last post August 28 2022: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919903). But I don't think that'll help me much, so I'll need to find a workaround. At least now I know what's going on.
Related
In order to refresh a part of the grid, i.e., when font or alignment changes, I was using the following approach:
wxRect rect1=CellToRect(TopLeft);
wxRect rect2=CellToRect(BottomRight);
wxRect r(rect1.GetTopLeft(), rect2.GetBottomRight());
RefreshRect(r);
This was refreshing only a part of the intended block and was not working correctly.
From the suggestions of intellisense I came across RefreshBlock function and it works correctly. I searched the docs and have not found any information on it. I wonder if it is not recommended to use RefreshBlock for some reason? What does RefreshBlock do, does it refresh a block (as the name suggests) or is it equivalent to Refresh?
I am using wxWidgets 3.2 on Win10.
Thanks in advance.
The function RefreshBlock() is indeed the best way to do what you want and it was only undocumented by mistake, i.e. we simply forgot to do it. I've added documentation for it only now, so it will only get included in 3.2.1, but you can still use it in your code, the function itself is available since 3.1.3.
It seems from the source code that, depending on the location of its parameters, RefreshBlock refreshes any of the following:
corner grid
frozen cols grid
frozen rows grid
main grid
Since the area I wanted to refresh was on the main grid the following approach works (the idea is similar to RefreshBlock's approach):
auto GridWnd = CellToGridWindow(TL);
wxRect rect = BlockToDeviceRect(TL, BR, GridWnd);
GetGridWindow()->RefreshRect(rect);
Now everything is refreshed correctly.
Notes:
If only RefreshRect(rect) is called, things will NOT work as expected.
Little experiment showed that BlockToDeviceRect(TL, BR) also works, therefore eliminating the need for auto GridWnd = CellToGridWindow(TL);
I'm having a problem with the datatables plugin.
I have table within a modal, which I edit in the table itself.
However when I'm adding a new row via table.row() the pagination gets weird.
Somehow instead of updating the pagination a new one appears beneath the old one. The new one gets updated while the old one doesnt.
double pagination
I have checked, the table is not declared again, but even if it were, "retrieve" is set to true so that's not it. If I knew where the problem came from, I'd be able to fix it but I have no clue. Any ideas?
Edit: I foud out that the problem is with deleting rows, not with adding them. Why exactly, I still don't know
I had some problems with Regex for my inputs and once I fixed those, everything worked just fine. So my guess would be that if an error is thrown, dataTables might be stopped while running, which in turn causes this behaviour. In actuality I have no clue, why this fixed the problem, but it did. If you have a similar problem, try eliminating all errors/uncaught exceptions, etc.
If anyone knows more, I'd be glad to find out about it
I want use Gridster for my web site, but i need to add lot of widgets with "add_widget" command. I do a test and i think there is a problem with "add_widget" function : grid is more and more slow and there are memory leak.
You can see that in this video : grister problem video
However, as you can see on the video, if i add widget at beginning (not with add_widget function) there is no problem. Can you help me ? Something wrong with my code ?
Thanks in advance !
In my own experience, the main culprit was using the autogenerate_stylesheet setting. The problem is that it regenerates the css on every call to add_widget(), and this just absolutely kills browsers. Additionally, gridster has/had a bug where stylesheets get duplicated, filling the <head> with tons of duplicate style rules, making it tough on the browser(this bug was supposedly fixed, but my experience was that the fix only worked in specific scenarios, definitely not in mine).
When I used gridster, my widgets were always the same size. So, in my case, I was able to generate the stylesheet once, never needing to regenerate it.
I don't think its part of the public api, but you can just call generate_stylesheet() method once manually.
var gridster = $(".gridster ul").gridster({
autogenerate_stylesheet: false,
widget_base_dimensions: [140, 140],
//other options...
}).data('gridster');
gridster.generate_stylesheet({rows: 30; cols: 8});
//freely call gridster.add_widget(...); as many times as you like
Since you're only going to generate the stylesheet once, you need to make sure gridster will generate style rules for enough rows and columns to accommodate all your widgets, otherwise once you exceed the range, you'll experience broken layouts. Just supply an upper bound on rows and cols when calling generate_stylesheet(opts). If you don't, it seems like it defaults to whatever value your gridster instance is using for max_rows and max_cols.
The nice thing is by manually generating the stylesheet, is that you completely avoid the duplicate style bug too.
The exponential slowdown will be gone. Happy gridstering.
I know I'm a bit late on this but I had the same problem and none of the above solutions worked.
However, I found that I was generating the size and coordinates of the widgets as a string rather than an integer on the back-end.
By making sure they were integers I managed to speed things up loads.
The best way to fix it, is not to disable the autogenerated stylesheet, but to edit the fn.generate_stylesheet function in jquery.gridster.js
At the end of the function, just before these lines:
return this.add_style_tag(styles);
};
add this line:
this.remove_style_tags();
The final result would look like this:
this.remove_style_tags();
return this.add_style_tag(styles);
};
With this, each time a stylesheet is generated, the previous one is removed, so there no duplication problem!
Dojo has a basic issue, amongst other things... with its dojo.dnd.move class. The issue which you can see here:
http://archive.dojotoolkit.org/nightly/dojotoolkit/dojo/tests/dnd/test_parent_constraints.html
Is that when you click on a node, and start dragging, the node itself jumps. It actually moves its position. This is extremely problematic and I was wondering if anyone has seen this happen before.
I am creating an application that requires the moving of nodes but it needs to be precise and thus can't have the initial jump.
Any help would be greatly appreciated.
This is caused by the following highlighted code in Mover.js:
https://github.com/dojo/dojo/blob/master/dnd/Mover.js#L91-92
The odd thing is, based on the comments, it seems like this code is causing the very problem it aims to prevent.
That said, if your body has padding: 0 applied to its style, this code shouldn't affect you. (You can test it on that test page by running document.body.style.padding = "0" in the console before dragging.)
You might want to enter a ticket on the Dojo bug tracker at http://bugs.dojotoolkit.org (or maybe search and see if one has already been entered for it).
After setting up a table model in Qt 4.4 like this:
QSqlTableModel *sqlmodel = new QSqlTableModel();
sqlmodel->setTable("Names");
sqlmodel->setEditStrategy(QSqlTableModel::OnFieldChange);
sqlmodel->select();
sqlmodel->removeColumn(0);
tableView->setModel(sqlmodel);
tableView->show();
the content is displayed properly, but editing is not possible, error:
QSqlQuery::value: not positioned on a valid record
I can confirm that the bug exists exactly as you report it, in Qt 4.5.1, AND that the documentation, e.g. here, still gives a wrong example (i.e. one including the removeColumn call).
As a work-around I've tried to write a slot connected to the beforeUpdate signal, with the idea of checking what's wrong with the QSqlRecord that's about to be updated in the DB and possibly fixing it, but I can't get that to work -- any calls to methods of that record parameter are crashing my toy-app with a BusError.
So I've given up on that idea and switched to what's no doubt the right way to do it (visibility should be determined by the view, not by the model, right?-): lose the removeColumn and in lieu of it call tableView->setColumnHidden(0, true) instead. This way the IDs are hidden and everything works.
So I think we can confirm there's a documentation error and open an issue about it in the Qt tracker, so it can be fixed in the next round of docs, right?
It seems that the cause of this was in line
sqlmodel->removeColumn(0);
After commenting it out, everything work perfectly.
Thus, I'll have to find another way not to show ID's in the table ;-)
EDIT
I've said "it seems", because in the example from "Foundations of Qt development" Johan Thelin also removed the first column. So, it would be nice if someone else also tries this and reports results.
I use Qt 4.6.1 in PyQt and the problem is still here. Removing "removeColumn(0)" solves the issue.