We have encountered a subtle issue with ExtJS grid.
It is quite regular grid with standard 'cell editor' plugin and two editable columns (having at least two is important).
Once an editable cell is submitted, the store backing the grid gets reloaded.
However grid reload takes place in a subsequent time slot because it's a part of asynchrouous task completion.
All this works well unless the user submits editable cell with the Tab key rather than with Enter. Tab makes second column's cell editor visible and shifts input focus there. After that the store reloads, or at least I believe it happens afterwards.
At first glance nothing bad happens to the UI, it continues working as usual. However after some time an attempt to hover the mouse over any element to which a tooltip is attached causes crash and console gets flooded with errors.
We've been able to establish immediate reason of this: garbage collection cycle that follows grid reload treats the input field belonging to the second column's editor as garbage. As a result Ext.Element instance wrapping this field has its dom property erased. By itself it's seemingly not an issue. However, for some reason, when it comes to show a tooltip, the system tries to get its hands on the Element that was previously garbage collected. Strangely enough, that element has nothing to do with tooltips.
In order to reproduce this open the fiddle and then
Double-click any cell in the first column to make it editable
Type any value
Press Tab on the keyboard
Wait 30 seconds
Move and hover the mouse over the grid cells to view tooltips
It does not need to be a grid tooltip, the bug equally occurs even if the mouse hovering over any unrelated UI element with tooltips.
So the question is: how can it be that garbage-collected element is reused, and how to correct this?
Related
I am using "javafx.scene.control.ComboBox" on Java 8 and I noticed that whenever the combobox does not have room below and instead pops up, the bordering styling of the elements switches as if it still pops down.
How can I access the styling for that to fix it?
Managed to fix this by actually extending the ComboBoxListViewSkin. In there, I've stuck a method that updates the styling, and does that by calling super.getPopup(), gets the AnchorY of that and compares it with the combo-box Y. After determining if the popup is below or above the combo, I set the correct styling on super.getListView...
Also, that method I've added, has to be called from the "ON_SHOWN" event of the combo-box.
I've tried several other variants but the damn thing just yields unstable behavior.
I have a tab pane that contains a bunch of tabs (obviously). Normally you can set a listener to each tab by calling setOnSelectionChanged() on the Tab. However, if the TabPane is being reorganized in some way, the tab pane automatically selects the first tab in the list. This is causing some performance issues for me so I would like to know if there is a way to know if a Mouse Click caused the Tab to be selected. Apparently tabs cannot have onMouseClick() listeners.
Whilst the solution to the answer wasn't found since tabs aren't actually nodes and don't have mouse click listeners, the performance issues were solved.
When changing tabs, I was (lazily) recreating the entire view and applying the model to the view. This caused a delay of approximately 140ms or more every time the tab changed. It was a bigger issue when implementing a search box to find the correct tab because as the tabs were being recreated from the search, the views were being recreating as the selection of the tabs changed (Tab pane automatically selects the first tab when adding new tabs).
Ultimately the design was changed to having the controller create the view once, and simply hooking the model to the view as the tab changed instead of recreating the view over and over.
I highly recommend looking at this post if your having performance issues and are relatively new to MVC/JavaFX programming:
Scene loads too slow
Currently changing tabs take approximately 15ms which is a significant improvement!
So i am using a QTableWidget as a logger of sorts for a user, with new rows being inserted at the top, and bottom ones falling off eventually as i read in updates every second or so.
I am currently running these 3 commands to keep the user from being able to do anything with the widget.
summaryTable->setSelectionMode(QAbstractItemView::NoSelection);
summaryTable->setFocusPolicy(Qt::NoFocus);
summaryTable->setEditTriggers(QAbstractItemView::NoEditTriggers);
This works, the user cant select a box(doesnt get highlighted more on that later), cant edit a box, all is good.
Except even if a user clicks on a cell, even though its not highlighted visibly there is still something allowing it to be selected such that when that cell gets "pushed" down below the current scroll area from inserts at the top the table begins scrolling down to follow this cell all the way to the bottom.
Obviously this is confusing, if a user clicks a cell within a few seconds its going to keep scrolling them down the table over and over again and it becomes a fight for them to scroll back up and click on a header or something to prevent future scrolling.
How do i prevent this? I thought by preventing selection and turning off what i did it would stop this, but there is still some type of selection happening within QT even if its not visible as its tracking the selected cell.
Oops, didnt realize there is a SetAutoScroll method, setting this to false fixed the issue.
This Method May Work QTableWidget::scrollToItem() or
QTableWidget::scrollTo() is will Work :)
You can manually scroll the item by putting row index as -
self.ui.tableWidget.verticalScrollBar().setValue(index)
OR
You can auto scroll the item by current index:
row = self.ui.tableWidget.currentIndex().row()
self.ui.tableWidget.verticalScrollBar().setValue(row)
Situation: As the central widget of my application I have a QMdiArea in tabbed mode (wrapped in a custom class that inherited from QMdiArea). When I now add the first QMdiSubWindow via addSubWindow() everything is still fine, meaning the window and its contents are maximized to take up all the space of the QMdiArea. However, as soon as I add a second sub window, the following problem arises:
Problem: The content of the second window is not displayed, but instead the content from the first continues to (despite the fact that the second tab visually has the focus), but is reduced in size. It only takes up a few pixels. But if I now switch back to the first sub window/tab (either by clicking into the size-reduced widget which then automatically goes back to max size or by selecting the first tab header) and then selecting the 2nd again, all is fine = the widget/editor of the 2nd tab is now displayed and is maximized.
But only until I close the second tab, in which case the content from the first is displayed (as expected), but again only in the small size!
Screenshot:
Another related test case: 1st tab is created and is displayed full size as expected. If I now simply resize the overall QMainWindow, suddenly a faint border appears around the widget in my tab. So it appears to be in a mixed state between maximized and normal mode with borders. Does that create any new leads?
Screenshot:
I am so far not using any explicitly defined layouts, but given that the first tab works fine and after manual back-and-forth switching all others as well, I assume that it should work without.
Do I need to set explicit layout objects? Why does it work for the first tab, but not the second?
Some code as a base: This is the logic executed in my custom QMdiArea class that takes care of adding the new children:
// Note: pEditor inherits from / is a QMdiSubWindow itself
if(!pEditor->isInitialized())
{
pEditor->initialize();
pEditor->setWidget(pEditor->getEditorWidget());
pEditor->setInitialized(true);
}
pEditor->beforeDisplay();
addSubWindow(pEditor);
pEditor->showMaximized();
// HACK START
pExisting = subWindowList().at(0);
if(pExisting)
setActiveSubWindow(pExisting);
// HACK END
Update: Added the hack proposed by N1ghtLight. Marked as such in the coding.
Update 2: Edited / correct problem description + new test-case with screenshot.
After many hours of comparing the example project from N1ightLight to my own implementation, I finally came across the central differences. There were in fact two issues at play:
For some reason I had the following line in the creation of my MDI sub windows, which apparently screwed up the size handling. Getting rid of this line removed any need for the previously proposed hack. Combined with the layouting proposed by N1ghtLight, all size changes are now handled gracefully.
setWindowState(Qt::WindowMaximized); // do not use that state!
The second part regarding the tab closing (closing one tab did not bring up the next tab in the expected manner and size), is actually explained in the Qt documentation:
When you create your own subwindow, you must set the Qt::WA_DeleteOnClose widget attribute if you want the window to be deleted when closed in the MDI area. If not, the window will be hidden and the MDI area will not activate the next subwindow.
Since I was creating my own sub windows I had to set that flag, but I never did because I wanted to prevent Qt from automatically deleting my content widget as well. My solution now is that I set the flag, but whenever a MDI child is about to be closed, I remove the link to the widget, so Qt cannot delete it.
void CustomMDIWindow::closeEvent(QCloseEvent* pEvent)
{
setWidget(0);
pEvent->accept();
}
I will mark my own answer as the correct one, but will award the bounty to N1ightLight since his support eventually led to me finding the final solution.
The ugly workaround really can be the calling of setActiveSubWindow() twice: First for some available sub window and then for the newly created one. This should emulate the situation when you click on the first tab and then return to the second one.
One of my end-users just reported an odd problem in an ASP.NET 2.0 application, which I've confirmed, but which seems rather odd to me. I have a DropDownList control on my web form, which displays several dozen different items. The easiest method for them to navigate the list is by typing the first several letters of the item they want to select. No problem, and we're all familiar with this approach.
The issue arises when they pause typing, wait a second or so (to consult a document for a serial number, for example), and then resume typing the next letters of their target selection. As soon as they resume typing, the position they had in the list is ignored, and the cursor moves to the value which begins with the new sequence of characters they have keyed in. For example, if they are trying to select a value of "PREAMBLE", and they type the letters PRE, the first item containing "PRE" is highlighted. However, if they pause for a moment, then continue with "AMBL", the list jumps back to the beginning, and the first list item containing "AMBL" is highlighted. Since the users are typing serial numbers in one of the dropdowns, this habit of pausing for a moment is completely natural, but it also causes them some frustration, as they have to type in a longer string of characters without stopping.
I've tested this on Chrome and Internet Explorer and Firefox, so I conclude it isn't browser specific. Is there a time paramater I can adjust on the dropdown list, to allow for a longer pause? Is there a way to disable the behavior I've described here? I can duplicate the behavior on a list with as few as seven items. On a list of seven items, it isn't a problem, but on a list with a hundred items, it gets to be a hassle.
Any insight in to this would be most appreciate, as would any suggestions on how to avoid it from happening, especially if I can disable it on a control by control basis. Thanks in advance!
what you are witnessing is the normal behavior of any dropdown..
till you keep typing it works as an auto complete.. but as soon as you stop it starts to search again in the list of item it comtains
if you wanna just keep the current state of the also.. then look for solutions like Jquery AutoComplete present here and it will keep the state and will give due importance to all the characters typed the problem that you might face with it is that it is applied on a textbox but then it would be easier for users to type all the way and look for hints simultaneously