STRANGE BEHAVIOUR OF QTableView and QFileDialog
-
**Hi. I have this application that is supposed to operate on at least two custom data repositories. The app handles them through a Qt's model/view famework where the main repository is linked to the only table view provided. The second repository is linked to the said tableview-model implementation through some sort of signals and slots and the two models are dependent on the tableview and on the overall application operations. i.e the data rendered/edited by the table view is from/to both repositories.
Data is loaded through a QFileDialog that allows selection of the two repositories. However, I have encountered two strange behaviours that i would like someone to help understand what is happening.1). When the QFileDialog loads and one fails to select any file by way of canceling or closing the dialog window, control is not returned gracefully to the main application, but the whole application crashes and the windows system throws a segmentation error. I haven't been able to figure out whether the bug is in my codebase or with the Qt framework itself but I have so far debugged my code sufficiently.
2). Secondly, the table view is also manifesting a strange behaviour too. In the table view, dynamic resizing has not yet been handled appropriately in the application in relation to the probable data sizes. However, the default behaviour of showing tiny table when the data rows are too few is undesirable so I had to dictate a temporary size so that the table view is at least the desired size. In a case where the data rows are too few, there is an empty white space that is rendered after the last row. Everything works fine with the application and more specifically rendering of data elements in the table view until one CLICKS the empty unoccupied white space of the table view. The application immediately crashes. I have inspected and included appropriate guard conditions to ascertain that execution of data in the repositories only occurs for valid indices. On checking the Qt Creator application building logs, there is an error that indicates that " index out range" error has occured for QList <T>::at() . This is not in my code; I am very sure about that. I am wondering if it is a thing to do with internal implementation of the QTableView class. I mean the way it resolves the indices of the selected items on the view so that when the said empty space is clicked for selection, an undefined behaviour occurs or a bug manifestation suffices. For this application, the empty white space is critical and useful, supposing that there is work around this behavour of crashing.
PLEASE SOMEONE HELP. THANK YOU.**
-
**Hi. I have this application that is supposed to operate on at least two custom data repositories. The app handles them through a Qt's model/view famework where the main repository is linked to the only table view provided. The second repository is linked to the said tableview-model implementation through some sort of signals and slots and the two models are dependent on the tableview and on the overall application operations. i.e the data rendered/edited by the table view is from/to both repositories.
Data is loaded through a QFileDialog that allows selection of the two repositories. However, I have encountered two strange behaviours that i would like someone to help understand what is happening.1). When the QFileDialog loads and one fails to select any file by way of canceling or closing the dialog window, control is not returned gracefully to the main application, but the whole application crashes and the windows system throws a segmentation error. I haven't been able to figure out whether the bug is in my codebase or with the Qt framework itself but I have so far debugged my code sufficiently.
2). Secondly, the table view is also manifesting a strange behaviour too. In the table view, dynamic resizing has not yet been handled appropriately in the application in relation to the probable data sizes. However, the default behaviour of showing tiny table when the data rows are too few is undesirable so I had to dictate a temporary size so that the table view is at least the desired size. In a case where the data rows are too few, there is an empty white space that is rendered after the last row. Everything works fine with the application and more specifically rendering of data elements in the table view until one CLICKS the empty unoccupied white space of the table view. The application immediately crashes. I have inspected and included appropriate guard conditions to ascertain that execution of data in the repositories only occurs for valid indices. On checking the Qt Creator application building logs, there is an error that indicates that " index out range" error has occured for QList <T>::at() . This is not in my code; I am very sure about that. I am wondering if it is a thing to do with internal implementation of the QTableView class. I mean the way it resolves the indices of the selected items on the view so that when the said empty space is clicked for selection, an undefined behaviour occurs or a bug manifestation suffices. For this application, the empty white space is critical and useful, supposing that there is work around this behavour of crashing.
PLEASE SOMEONE HELP. THANK YOU.**
@base_load said in STRANGE BEHAVIOUR OF QTableView and QFileDialog:
**Hi. I have this application that is supposed to operate on at least two custom data repositories. The app handles them through a Qt's model/view famework where the main repository is linked to the only table view provided. The second repository is linked to the said tableview-model implementation through some sort of signals and slots and the two models are dependent on the tableview and on the overall application operations. i.e the data rendered/edited by the table view is from/to both repositories.
Data is loaded through a QFileDialog that allows selection of the two repositories. However, I have encountered two strange behaviours that i would like someone to help understand what is happening.1). When the QFileDialog loads and one fails to select any file by way of canceling or closing the dialog window, control is not returned gracefully to the main application, but the whole application crashes and the windows system throws a segmentation error. I haven't been able to figure out whether the bug is in my codebase or with the Qt framework itself but I have so far debugged my code sufficiently.
Did you check out the documentation on QFileDialog?
It says:
This is a convenience static function that returns an existing file selected by the user. If the user presses Cancel, it returns a null string.
Therefore the assumption is that you are not checking the return value, most likely a null string. Most actions on null strings are causing crashes.
The rest is crystal ball reading.2). Secondly, the table view is also manifesting a strange behaviour too. In the table view, dynamic resizing has not yet been handled appropriately in the application in relation to the probable data sizes. However, the default behaviour of showing tiny table when the data rows are too few is undesirable so I had to dictate a temporary size so that the table view is at least the desired size. In a case where the data rows are too few, there is an empty white space that is rendered after the last row. Everything works fine with the application and more specifically rendering of data elements in the table view until one CLICKS the empty unoccupied white space of the table view. The application immediately crashes. I have inspected and included appropriate guard conditions to ascertain that execution of data in the repositories only occurs for valid indices. On checking the Qt Creator application building logs, there is an error that indicates that " index out range" error has occured for QList <T>::at() . This is not in my code; I am very sure about that. I am wondering if it is a thing to do with internal implementation of the QTableView class. I mean the way it resolves the indices of the selected items on the view so that when the said empty space is clicked for selection, an undefined behaviour occurs or a bug manifestation suffices. For this application, the empty white space is critical and useful, supposing that there is work around this behavour of crashing.
PLEASE SOMEONE HELP. THANK YOU.**
You probably need to post code sections describing your problem. Most likely you have a mismatch of rows and/or columns in your code.
BTW captial letters are interpret as shouting throughout the internet. Not sure if everybody is liking your shouting of the title and the end of your email.
-
Thank you for the correction about using uppercase letters. About my code, let me try checking your suggestion and also compose a comprehensive report about those problems I am encountering. (on a light note, I am not a speaking English as my first language. I may make a lot of grammatical errors too)
-
Thank you for the correction about using uppercase letters. About my code, let me try checking your suggestion and also compose a comprehensive report about those problems I am encountering. (on a light note, I am not a speaking English as my first language. I may make a lot of grammatical errors too)
@base_load said in STRANGE BEHAVIOUR OF QTableView and QFileDialog:
(on a light note, I am not a speaking English as my first language. I may make a lot of grammatical errors too)
Welcome to the club. Probably 80-90% are no native English speakers. Therefore, do not worry about the grammatical challenges of English. ;)
-
**Hi. I have this application that is supposed to operate on at least two custom data repositories. The app handles them through a Qt's model/view famework where the main repository is linked to the only table view provided. The second repository is linked to the said tableview-model implementation through some sort of signals and slots and the two models are dependent on the tableview and on the overall application operations. i.e the data rendered/edited by the table view is from/to both repositories.
Data is loaded through a QFileDialog that allows selection of the two repositories. However, I have encountered two strange behaviours that i would like someone to help understand what is happening.1). When the QFileDialog loads and one fails to select any file by way of canceling or closing the dialog window, control is not returned gracefully to the main application, but the whole application crashes and the windows system throws a segmentation error. I haven't been able to figure out whether the bug is in my codebase or with the Qt framework itself but I have so far debugged my code sufficiently.
2). Secondly, the table view is also manifesting a strange behaviour too. In the table view, dynamic resizing has not yet been handled appropriately in the application in relation to the probable data sizes. However, the default behaviour of showing tiny table when the data rows are too few is undesirable so I had to dictate a temporary size so that the table view is at least the desired size. In a case where the data rows are too few, there is an empty white space that is rendered after the last row. Everything works fine with the application and more specifically rendering of data elements in the table view until one CLICKS the empty unoccupied white space of the table view. The application immediately crashes. I have inspected and included appropriate guard conditions to ascertain that execution of data in the repositories only occurs for valid indices. On checking the Qt Creator application building logs, there is an error that indicates that " index out range" error has occured for QList <T>::at() . This is not in my code; I am very sure about that. I am wondering if it is a thing to do with internal implementation of the QTableView class. I mean the way it resolves the indices of the selected items on the view so that when the said empty space is clicked for selection, an undefined behaviour occurs or a bug manifestation suffices. For this application, the empty white space is critical and useful, supposing that there is work around this behavour of crashing.
PLEASE SOMEONE HELP. THANK YOU.**
@base_load said in STRANGE BEHAVIOUR OF QTableView and QFileDialog:
This is not in my code; I am very sure about that.
Still in the "denial" stage of grief, I see. Don't worry, we've all been there.
Regarding the 2 crashes posting the stack trace would help us a lot in guessing what the problem might be.
Regarding the sizing problem, what layout are you using and/or did you call
setSizeAdjustPolicyon the view?
