It would be convenient to be able to move the cursor the next (or previous) error. This was accomplished be adding two additional actions, one for moving the cursor to the next error and the other to move the cursor to the previous error. Each action was given an arrow icon, which were modified to have a red hue. Both were also assigned key shortcuts, which were Ctrl+. (period) for next and Ctrl+, (comma) for previous. These keys were chosen because they also contain the greater than and less than keys, which are like arrows.
The actions are automatically connected to associated triggered functions in the MainWindow class, which call new functions in the EditBox class to perform the action. These functions first find the error for the current line. If the current line does not have an error, the find returns the index of next error or will return in index one beyond the end of the error list. The functions then move to the next or previous error depending whether the cursor is already sitting at the error found. If beyond the last or first error, a question box is displayed informing this and asks whether to move to the first or last error in the program. If there is only one error, then no question box is displayed.
There is some sort of issue when running on Linux (Mint 13 KDE) using the static QMessageBox::question() function to display the question asking whether to wrap around and to the first or last error - an X Error message is output. This may have something to do with another problem where there is suppose to be a question mark icon on this message box, but the information icon is displayed instead. These problems do not occur on Windows and also do not occur on Linux if the application is launched with the -style Plastique option.
For now the next and previous error tool bar buttons and edit menu items are always enabled. Next these will be disabled when there are no errors.
[commit f086ce50b8]
Saturday, May 18, 2013
Sunday, May 12, 2013
Error Highlighting – Error Messages
To display error messages in the status bar area at the bottom of the application window required a few minor changes. Two labels were added to the status bar of the main window, one for the current line number and column, and the other for the error message. A signal was added to the edit box, which is emitted when the cursor positioned has changed.
A new function was added to the main window class for creating the status bar: adding the labels to the status bar and connecting the signal cursor changed signal from the edit box to a new update status bar slot in main window. New member label pointers were added so that the labels are easily accessible when it's time to update their text. New access functions were added to the edit box class to return the current line number, column and message for the line (if there is one) so the update slot can get the information for the status bar labels.
The new message access function of the edit box searches for the line number in the error list. A new find index function was added to the error list class, which returns a -1 if the line number does not have an error. The existing find function is called, which only returns an index regardless if the line has an error, so a check is made if the index returned is the line being search for. If the line does not have an error, a blank message string is returned.
There were a couple of issues getting the error messages to be displayed in the status bar correctly. Click Continue... for details of these issues and how they were resolved.
[commit c38cd02bd4]
A new function was added to the main window class for creating the status bar: adding the labels to the status bar and connecting the signal cursor changed signal from the edit box to a new update status bar slot in main window. New member label pointers were added so that the labels are easily accessible when it's time to update their text. New access functions were added to the edit box class to return the current line number, column and message for the line (if there is one) so the update slot can get the information for the status bar labels.
The new message access function of the edit box searches for the line number in the error list. A new find index function was added to the error list class, which returns a -1 if the line number does not have an error. The existing find function is called, which only returns an index regardless if the line has an error, so a check is made if the index returned is the line being search for. If the line does not have an error, a blank message string is returned.
There were a couple of issues getting the error messages to be displayed in the status bar correctly. Click Continue... for details of these issues and how they were resolved.
[commit c38cd02bd4]
Saturday, May 11, 2013
Error Highlighting – Program Load Fix
Displaying the error messages on the status bar at the bottom of the window has proven to be difficult. While working on getting these changes to work, a problem was discovered when loading a program with errors - the errors were not display just like the problem when the application first starts.
The mechanism added to correct that initial start up problem did not work for this case because the cursor valid flag, which is initially reset, is set the first time the cursor is moved. When a program is loaded, the text of the program loaded in set in the edit box's document using the setPlainText() function. Apparently while the text is being set, the cursor is again invalid preventing the errors from being highlighted.
The cursor valid flag mechanism was utilized to correct this problem. The setPlainText() function of the base QPlainTextEdit class was reimplemented in the edit box class, which resets the cursor valid flag and calls the base class function. Once the text is set, a cursor changed signal gets emitted and the cursor valid flag is once again set triggering the errors to be updated.
[commit 58b0f23680]
The mechanism added to correct that initial start up problem did not work for this case because the cursor valid flag, which is initially reset, is set the first time the cursor is moved. When a program is loaded, the text of the program loaded in set in the edit box's document using the setPlainText() function. Apparently while the text is being set, the cursor is again invalid preventing the errors from being highlighted.
The cursor valid flag mechanism was utilized to correct this problem. The setPlainText() function of the base QPlainTextEdit class was reimplemented in the edit box class, which resets the cursor valid flag and calls the base class function. Once the text is set, a cursor changed signal gets emitted and the cursor valid flag is once again set triggering the errors to be updated.
[commit 58b0f23680]
Saturday, May 4, 2013
Errors List Corrections
While testing the error highlighting, some problems were found. The first one exhibited itself as the last error was not correctly updated when it changed. The problem was that a new error was being incorrectly inserted each time an error was changed. This occurred in the set error routine in the program model because it did not return after replacing an error and it proceeded to also insert an error.
The set error routine was cleaned up where the first part now specifically handles changes (not inserts) and returns after an error is removed (the line no longer has an error), or an error is replaced (the line still has an error). The rest of the routine handles inserting a new error and adjusting the rest of the error indexes and line numbers (for line inserts). The remove error routine contained an else clause for exiting when called for an insert, but since this no longer occurs, the else clause was removed.
The second problem was in the edit box update errors slot. The problem occurred when two or more lines with an error were removed and all the errors were changed as a result (due to the line numbers changing). The problem is that the ending change index is set to the last index upon the first removed error, but after the second error is removed, the ending change index is not beyond the end of the error list. This caused the routine to run past the end of the errors list causing a segmentation fault. This was corrected by limiting the number of errors changed to one less than the size of the errors list.
[commit 30e7d98a1d] [commit 65893e51f9]
The set error routine was cleaned up where the first part now specifically handles changes (not inserts) and returns after an error is removed (the line no longer has an error), or an error is replaced (the line still has an error). The rest of the routine handles inserting a new error and adjusting the rest of the error indexes and line numbers (for line inserts). The remove error routine contained an else clause for exiting when called for an insert, but since this no longer occurs, the else clause was removed.
The second problem was in the edit box update errors slot. The problem occurred when two or more lines with an error were removed and all the errors were changed as a result (due to the line numbers changing). The problem is that the ending change index is set to the last index upon the first removed error, but after the second error is removed, the ending change index is not beyond the end of the error list. This caused the routine to run past the end of the errors list causing a segmentation fault. This was corrected by limiting the number of errors changed to one less than the size of the errors list.
[commit 30e7d98a1d] [commit 65893e51f9]
Friday, May 3, 2013
Error Highlighting – Initial Start Up Fix
The problem with the errors not being highlighted when the program is first loaded was not caused due to the edit box not being drawn yet as first thought. The problem was identified to be that the text cursor was not valid initially. When the extra selection list was set up, each enter had an invalid cursor, so nothing was highlighted. The seemed to be no way to initialize the text cursor in the edit box constructor.
To compensate for this problem, a mechanism was implemented where the updated errors list is saved and not acted upon unless the text cursor is valid. A new errors list member was added to the edit box class to hold the saved errors list. The errors list needs to be saved anyway because it will be needed to access the error messages.
A new cursor valid flag was also added to the edit box class, which is initialized to false. In the cursor moved slot, the text cursor will be valid and this event always occurs during startup. So in this slot, if the cursor valid flag is not set, it is set to true and then the update errors slot is called to set the extra selections list.
[commit 89cfa532a8]
To compensate for this problem, a mechanism was implemented where the updated errors list is saved and not acted upon unless the text cursor is valid. A new errors list member was added to the edit box class to hold the saved errors list. The errors list needs to be saved anyway because it will be needed to access the error messages.
A new cursor valid flag was also added to the edit box class, which is initialized to false. In the cursor moved slot, the text cursor will be valid and this event always occurs during startup. So in this slot, if the cursor valid flag is not set, it is set to true and then the update errors slot is called to set the extra selections list.
[commit 89cfa532a8]
Thursday, May 2, 2013
Error Highlighting – Extra Selection List
To highlight the errors sent from the program model, a new extra selections list member was added to the edit box class. The update errors slot first determines the number of errors that have been inserted or removed by taking the difference between the size of the new errors list and the size of the current extra selections list. The number of errors that changes is determined by taking the difference between the end and start change indexes plus one, then subtracting the number of errors inserted (which may be zero).
Starting at the start change index for the number of errors that changed (which may also be zero), the extra selection is replaced with the corresponding error item from the errors list. Continuing for the number of errors inserted, the new error items from the error list are inserted into the extra selections list. Finally for the number of errors removed, the extra selections are removed from the list. (There will never be both insertions and removals.)
A new support function was added for converting an error item to an extra selection. If the length of the error is negative, this indicates an alternate column (which occurs in the case where there is a syntax error in the exponent of a floating point number, where the column is the beginning of the number). For this case, the syntax error will be highlighted and not the number for a length of one character.
The format of the extra selection is set to red background. The block for the line of the error item is retrieved from the document to get its position. The cursor of the extra selection is set to the text cursor of the document and positioned to the error (position of the line plus the column of the error. The cursor is moved to the end of the error with the keep anchor option, which highlights the error with the selected format.
Once the extra selections list has been updated for the change in the errors list, the edit box extra selections are set, which causes the errors to highlight. However, there is a problem. If a program contains errors when it is loaded, the errors are not initially highlighted. I think this is because the edit box hasn't been drawn yet at the time the first errors changed signal is emitted.
[commit 24ae7f0467]
Starting at the start change index for the number of errors that changed (which may also be zero), the extra selection is replaced with the corresponding error item from the errors list. Continuing for the number of errors inserted, the new error items from the error list are inserted into the extra selections list. Finally for the number of errors removed, the extra selections are removed from the list. (There will never be both insertions and removals.)
A new support function was added for converting an error item to an extra selection. If the length of the error is negative, this indicates an alternate column (which occurs in the case where there is a syntax error in the exponent of a floating point number, where the column is the beginning of the number). For this case, the syntax error will be highlighted and not the number for a length of one character.
The format of the extra selection is set to red background. The block for the line of the error item is retrieved from the document to get its position. The cursor of the extra selection is set to the text cursor of the document and positioned to the error (position of the line plus the column of the error. The cursor is moved to the end of the error with the keep anchor option, which highlights the error with the selected format.
Once the extra selections list has been updated for the change in the errors list, the edit box extra selections are set, which causes the errors to highlight. However, there is a problem. If a program contains errors when it is loaded, the errors are not initially highlighted. I think this is because the edit box hasn't been drawn yet at the time the first errors changed signal is emitted.
[commit 24ae7f0467]
Subscribe to:
Posts (Atom)