The error highlighting implementation is now complete and it is time for a development release. I made the decision to change the naming convention of repository tags from releaseX.X.X to vX.X.X, which is the convention used by many other projects under git revision control (like the git source repository itself). All the "release" named tags have been replaced with the new "v" named tags. These can be removed from a local repository using the command git tag -d `git tag -l release*` (backward single quotes) or the repository can be re-cloned.
To support this change, the CMake build configuration file CMakeLists.txt was modified for this naming convention. A change was also required in the building of the version string in the command line class, which previously added seven to the release string pointer, seven being the length of the "release" part of the version string. This could have simply been changed to one, the length of the "v" part of the string, but instead a little code was added to look for the start of the version number part of the string (by using a regular expression) so it doesn't matter what string precedes the version number.
The change in tag names will not cause a problem when building one of the archive files downloaded for a given tag because CMake will generate the version string being that the git repository will not be available. Though the version announced as being built will still have the "release" string in the name.
However, if building at an older tag with the new tag naming convention, then these changes are needed, which is not an issue with any of the versions prior to 0.2. CMake will not complain from versions 0.2-1 to 0.2-6 but the version number output will be messed up. The changes need to be applied manually. Starting with the final version 0.2.0 through the 0.3.X versions, the changes can be applied by git using the command git cherry-pick fa89 command where fa89 is the abbreviated commit ID of the commit with the changes. To preserve this commit, a new branch can be created using the command git checkout -b xxx where xxx is the desired branch name.
Finally, previous blog entries were edited to reflect the new tag naming convention. All blog previously given the Pre-Release blog tag was given the Tag blog tag. Major releases still contain the Release blog tag (and not the Tag blog tag so they can be differentiated).
[commit fa89de8a0d]
Saturday, June 15, 2013
Friday, June 14, 2013
Modifying A Line With An Error
When a line is modified that contains an error, the highlighted error can be shifted around or changed in size. This can make the error message no longer applicable, so the highlighted error should be removed. Upon the cursor leaving the line, the line will be rechecked for errors. A check for this situation was added to the document change slot of the edit box class when a single line is changed. No action was taken for single line changes.
When a single line is modified, the errors lists is searched its line number. If the line contains an error, but the modification occurred after the error, no further action is taken. If the cursor and the error are at the end of the line, or the cursor is within the error, the error is removed from the error list. If the cursor is before the error, the column of the error is moved by the net change (number of characters added less the number removed).
The update errors slot is called to update the display. A cursor changed signal is also emitted so that the error message on the status line is removed when the error is removed. This didn't always occur because the cursor is not always moved when the document is changed (for example, when characters are deleted). New move error column functions were added to the error list and error item classes to support the shifting of errors.
[commit 98d7b2c0b4]
When a single line is modified, the errors lists is searched its line number. If the line contains an error, but the modification occurred after the error, no further action is taken. If the cursor and the error are at the end of the line, or the cursor is within the error, the error is removed from the error list. If the cursor is before the error, the column of the error is moved by the net change (number of characters added less the number removed).
The update errors slot is called to update the display. A cursor changed signal is also emitted so that the error message on the status line is removed when the error is removed. This didn't always occur because the cursor is not always moved when the document is changed (for example, when characters are deleted). New move error column functions were added to the error list and error item classes to support the shifting of errors.
[commit 98d7b2c0b4]
Thursday, June 13, 2013
Error Action Enabling/Disabling
Now with actions to move the cursor to the next or previous error, these actions should only be enabled when there are actually errors. To accomplish this, an errors available signal was added to the edit box class. The update errors slot was modified to determine when the errors available condition changes by comparing the before and after error list emptiness status. Several problems were found and corrected while testing the new signal.
In the update errors slot, when there were no errors in the incoming errors list, a Qt error occurred because bad indexes were used in accessing the errors list. This was due to using the start and end change indexes when they were not valid. A check was added for when the incoming error list has no errors to prevent this.
The second problem occurred when there were no errors and the next or previous error key shortcuts were used. This was due because the Ctrl+. (period) and Ctrl+, (comma) were not intercepted since the errors actions were disabled, causing these keys to be treated as a regular period and comma, which was inserted into the program. Checks were added to the key press event handler to catch and ignore the period and comma keys when the Ctrl modifier was active.
Finally, during testing, an unrelated problem was found with the detection of changed lines when comparing RPN lists that contained errors. Previously this comparison (equality operator function) compared the error column and length and reported equality if they were the same. This caused a problem were sometimes the error was not displayed correctly in the modified line (or not at all). The equality function was modified to report no match if either RPN list has an error.
[commit 352667221f] [commit 15084235a2]
In the update errors slot, when there were no errors in the incoming errors list, a Qt error occurred because bad indexes were used in accessing the errors list. This was due to using the start and end change indexes when they were not valid. A check was added for when the incoming error list has no errors to prevent this.
The second problem occurred when there were no errors and the next or previous error key shortcuts were used. This was due because the Ctrl+. (period) and Ctrl+, (comma) were not intercepted since the errors actions were disabled, causing these keys to be treated as a regular period and comma, which was inserted into the program. Checks were added to the key press event handler to catch and ignore the period and comma keys when the Ctrl modifier was active.
Finally, during testing, an unrelated problem was found with the detection of changed lines when comparing RPN lists that contained errors. Previously this comparison (equality operator function) compared the error column and length and reported equality if they were the same. This caused a problem were sometimes the error was not displayed correctly in the modified line (or not at all). The equality function was modified to report no match if either RPN list has an error.
[commit 352667221f] [commit 15084235a2]
Saturday, May 18, 2013
Move To Error Actions
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]
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]
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]
Monday, April 29, 2013
Error List Changes Finalized
The method of keeping a list of change operations does not work when multiple lines of the program are changed with more than one error affected because each line of the multiple line change is processed individually. This caused errors will the same index to be repeatedly set leading to the many extra change operations being appended to the change list. Even though this was a failed attempt, it did lead to a clue on how to get the start and end indexes of the changes method working correctly.
The index to the start of the changes only needs to be set the first time since a lower index will not be changed. The index to the end of the changes will still be set if a higher index is changed, but with a slight modification.
The clue to the solution came from the debug output in the edit box receiving errors changed signal. As the list of changes were processed, the debug code simply incremented the index for each change operation except for a remove operation. The index was not incremented for a remove operation since an error was removed from the list and the next operation applied to the same index.
Therefore, before checking if end change index needs to be set to the current higher index, the index is decremented first for a remove operation. The edit box will determines the number of errors that have changed by subtracting the start from the end index and adding one. For example, for a single remove operation, the end index will be one less than the start index, so the number of errors changes will calculate to zero. The number of errors removed (or inserted) is determined by the change in the size of the error list.
The debug output code in the edit box was updated to allow for an end index to be one less than the start index. The code still outputs asterisks for errors that changed (because the index is within the start and end indexes of the changes), but now outputs a minus if no errors were changed (only removed).
[commit 9ea17018cc]
The index to the start of the changes only needs to be set the first time since a lower index will not be changed. The index to the end of the changes will still be set if a higher index is changed, but with a slight modification.
The clue to the solution came from the debug output in the edit box receiving errors changed signal. As the list of changes were processed, the debug code simply incremented the index for each change operation except for a remove operation. The index was not incremented for a remove operation since an error was removed from the list and the next operation applied to the same index.
Therefore, before checking if end change index needs to be set to the current higher index, the index is decremented first for a remove operation. The edit box will determines the number of errors that have changed by subtracting the start from the end index and adding one. For example, for a single remove operation, the end index will be one less than the start index, so the number of errors changes will calculate to zero. The number of errors removed (or inserted) is determined by the change in the size of the error list.
The debug output code in the edit box was updated to allow for an end index to be one less than the start index. The code still outputs asterisks for errors that changed (because the index is within the start and end indexes of the changes), but now outputs a minus if no errors were changed (only removed).
[commit 9ea17018cc]
Sunday, April 28, 2013
Error List Changes Revisited
Using a start and an end index to track changes to the error list is not sufficient to be able to reproduce the changes in the edit box. A simple example of this is if one error inserted and one error removed. The next effect is that one error is changed. However, the start and end indexes will indicate that two lines were changed.
A new scheme was implemented where there is just a start index (renamed to simply change index) and a list of change operations preformed on the error list (insert, change and remove). This will allow the edit box to repeat the operations that were performed starting at the change index.
This scheme works because as the change list is built as a program update is processed, the index of each change will be sequential. However, while this works for single line changes (or a group of lines with a single error change), it doesn't work when multiple lines are changed (like with a multiple line insert or delete). Too many changes operations are appended to the change list because each line of the program update change is processed individually.
[commit 28af130fef]
A new scheme was implemented where there is just a start index (renamed to simply change index) and a list of change operations preformed on the error list (insert, change and remove). This will allow the edit box to repeat the operations that were performed starting at the change index.
This scheme works because as the change list is built as a program update is processed, the index of each change will be sequential. However, while this works for single line changes (or a group of lines with a single error change), it doesn't work when multiple lines are changed (like with a multiple line insert or delete). Too many changes operations are appended to the change list because each line of the program update change is processed individually.
[commit 28af130fef]
Saturday, April 27, 2013
RPN List – Error Storage
The RPN list class was storing the token where an error was detected, but it only really needed the column and length. Therefore, the code was changed to only store the column and length of the error.
While these changes were being made and tested, translator test #14 (parser errors) failed because there were extra blank lines after error messages. This extra blank line was left in so that the result files would not need to be changed, but this did not affect parser errors. The output of the extra blank line was removed and expected results files were updated.
[commit fdb798281c]
While these changes were being made and tested, translator test #14 (parser errors) failed because there were extra blank lines after error messages. This extra blank line was left in so that the result files would not need to be changed, but this did not affect parser errors. The output of the extra blank line was removed and expected results files were updated.
[commit fdb798281c]
Friday, April 26, 2013
Program Model – Error List Changes
The program model is now keeping a list of errors in the program. This list will be used to create the extra selections in the edit box to highlight the errors in the program. A signal was added to the program model to emit the error list when it changes and a slot was added to the edit box to receive the error list. For now, this slot just outputs the error list with indicators of the start and end errors that were changed.
The error list class was modified to capture the start and end indexes of the changes to a list when the program model receives a lines changed signal. New start and end change indexes were added to the error list class along with access functions - one for resetting these indexes called at the start of the program model update slot, one for checking if there was a change to the error list called at the end of the update slot (to determine if the error list change signal should be emitted), and two to access each index called by the edit box to update the error highlighting.
To catch when errors in the list are modified, the insert, remove and replace functions in the error list class were overloaded. Each calls the QList base function and then calls a new set change index private function, which checks if the index being modified is lower or higher then the current start and end change indexes. New increment and decrement line number functions were also implemented, which call the error item functions and then the set change index function.
The new update errors slot function for the edit box class receives the error list change signal. For now, the function just outputs the error list with indicators on the errors that changed, which was used for debugging.
[commit 666b15b531]
The error list class was modified to capture the start and end indexes of the changes to a list when the program model receives a lines changed signal. New start and end change indexes were added to the error list class along with access functions - one for resetting these indexes called at the start of the program model update slot, one for checking if there was a change to the error list called at the end of the update slot (to determine if the error list change signal should be emitted), and two to access each index called by the edit box to update the error highlighting.
To catch when errors in the list are modified, the insert, remove and replace functions in the error list class were overloaded. Each calls the QList base function and then calls a new set change index private function, which checks if the index being modified is lower or higher then the current start and end change indexes. New increment and decrement line number functions were also implemented, which call the error item functions and then the set change index function.
The new update errors slot function for the edit box class receives the error list change signal. For now, the function just outputs the error list with indicators on the errors that changed, which was used for debugging.
[commit 666b15b531]
Thursday, April 25, 2013
Another Undo/Redo Problem
Now that the program model is keeping a list of errors in the program, the next incremental change is to report changes to this list to the edit box so that the errors can be highlighted. While testing these changes, another problem was found with the detection of lines changes when using redo.
The problem occurs when the current line is modified (specifically from a redo) and another redo causes a change to occur in another part of the program. The line that was modified does not get reported. This can also occur with an undo, but only when going up and down through the undo/redo stack. The line is not being reported because for undo and redo, the document change signal occurs before the cursor moved signal (where a modified line gets reported).
A check was added towards the beginning of the document change slot after gathering information about the change but before acting upon it. If there is a modified line and the modified line is not at the line of the change, then the modified line is captured before processing the current change.
A complication occurs when the modified line is after the line of the change. When reporting the modified line, the capture routine needs to report the line number contained in the modified line variable, however, when retrieving the text of this line, since the document has already been modified by the undo or redo, the number of the line is not necessarily the same if the undo or redo inserted or deleted lines.
Fortunately, the offset of where the actual program line is (after the undo or redo change) is the same as the net line count change caused by the undo or redo. The capture modified line routine was modified to take an optional offset. The net line count change is passed if the modified line is after the line of the change, otherwise, no offset is needed if the modified line is before the change.
[commit 0049ab8883]
The problem occurs when the current line is modified (specifically from a redo) and another redo causes a change to occur in another part of the program. The line that was modified does not get reported. This can also occur with an undo, but only when going up and down through the undo/redo stack. The line is not being reported because for undo and redo, the document change signal occurs before the cursor moved signal (where a modified line gets reported).
A check was added towards the beginning of the document change slot after gathering information about the change but before acting upon it. If there is a modified line and the modified line is not at the line of the change, then the modified line is captured before processing the current change.
A complication occurs when the modified line is after the line of the change. When reporting the modified line, the capture routine needs to report the line number contained in the modified line variable, however, when retrieving the text of this line, since the document has already been modified by the undo or redo, the number of the line is not necessarily the same if the undo or redo inserted or deleted lines.
Fortunately, the offset of where the actual program line is (after the undo or redo change) is the same as the net line count change caused by the undo or redo. The capture modified line routine was modified to take an optional offset. The net line count change is passed if the modified line is after the line of the change, otherwise, no offset is needed if the modified line is before the change.
[commit 0049ab8883]
Saturday, April 20, 2013
Program Model – Error List
The next not so small increment to implement the error highlighting was the addition of an error list to the program model that will hold information about each error in the program. A new ErrorList class was implemented based on the QList class of the new ErrorItem class, which will contain the type of error (translator or encoder), line number, column, length and error message.
The errors in the list will be kept in order by line number, which allows finding an error by line number quickly by using a binary search. This class contains a find function with the binary search routine, which returns the index of the line number if found or the nearest error for a line number less than the line number being searched for. The nearest error location is used insert a new error into the list.
The program model update function, which receives program updates, was expanded into several new functions. The update function now calls the new update line function for changed, deleted and inserted lines. The remaining purpose of the update function is to call the appropriate triggers to update the program view.
The new update line function first compiles the line (change and insert), which for now just translates the line. For a change, if line has not changed, returns an indication that no change occurred, otherwise the line is replaced and the new set error function is called. For an insert, new set error function is called and the line is inserted into the program. For a delete, the new remove error function is called, the program line is deleted.
The new set error function (called for change and insert) first determines if the line has an error. If the line does not have an error, any current error (change only) is removed by the new remove error function. If a changed line had an error and still has an error, the old error is replaced with the new error. If the line has a new error, the error is inserted into the error list. The rest of the errors in the list are also adjusted - if a new error was inserted, the error index of the program line for each error is incremented; and if a new line is being inserted, the line number of each error is incremented.
The new remove error function (called for change and delete) determines in the line has an error, which is removed from the error list if it does. The rest of the errors in the list are also adjusted - if an error was deleted, the error index of the program line for each error is decremented; and if a line is being deleted, the line number of each error is decremented.
[commit 7c94dd4630]
The errors in the list will be kept in order by line number, which allows finding an error by line number quickly by using a binary search. This class contains a find function with the binary search routine, which returns the index of the line number if found or the nearest error for a line number less than the line number being searched for. The nearest error location is used insert a new error into the list.
The program model update function, which receives program updates, was expanded into several new functions. The update function now calls the new update line function for changed, deleted and inserted lines. The remaining purpose of the update function is to call the appropriate triggers to update the program view.
The new update line function first compiles the line (change and insert), which for now just translates the line. For a change, if line has not changed, returns an indication that no change occurred, otherwise the line is replaced and the new set error function is called. For an insert, new set error function is called and the line is inserted into the program. For a delete, the new remove error function is called, the program line is deleted.
The new set error function (called for change and insert) first determines if the line has an error. If the line does not have an error, any current error (change only) is removed by the new remove error function. If a changed line had an error and still has an error, the old error is replaced with the new error. If the line has a new error, the error is inserted into the error list. The rest of the errors in the list are also adjusted - if a new error was inserted, the error index of the program line for each error is incremented; and if a new line is being inserted, the line number of each error is incremented.
The new remove error function (called for change and delete) determines in the line has an error, which is removed from the error list if it does. The rest of the errors in the list are also adjusted - if an error was deleted, the error index of the program line for each error is decremented; and if a line is being deleted, the line number of each error is decremented.
[commit 7c94dd4630]
Wednesday, April 10, 2013
Program Model – Line Info List
As good practice, the changes to implement the error highlighting will be made in small increments. The first was to replace the program model's list of translated lines (pointers to RPN lists) with he list of line information items, each containing a pointer to the RPN list for the line (for now until the encoder is implemented) and an index to the error list if the line as an error (for now not used).
This change was trivial and just amounted to adding the definition of the LineInfo structure, private to the ProgramModel class since will be the only user of this structure; and changing the uses of the translated lines list member with the line information list member.
[commit aee559d041]
This change was trivial and just amounted to adding the definition of the LineInfo structure, private to the ProgramModel class since will be the only user of this structure; and changing the uses of the translated lines list member with the line information list member.
[commit aee559d041]
Subscribe to:
Posts (Atom)