Up to now only the simple predefined string list model has been used to hold the program. The next task was to start the implementation of a custom data model that will eventually hold the program code that will be run. To get he program model started, it will just hold a list of strings representing the lines of the program.
The new ProgramModel class is based on the QAbstractListModel as it only needs to hold a list of program lines. This will be changed as needed since the program model will eventually need to be able to hold multiple lists of program lines, one for the main routine and several for the subroutines and functions of the program.
Now that the initial program model has been implemented (click Continue... for details), using the program view, all the various edit change operations and scenarios will now be tested to make sure all the possible changes are covered and working properly. This is necessary to make sure the edit box keeps the program model properly informed of program changes. Then the process of connecting to the parser and translator will begin.
[commit b543f74b6d]
Saturday, March 16, 2013
Thursday, March 14, 2013
Edit Box Line Numbers – New Lines
When a new line is being entered into the edit box, a line that has not been inserted into the program yet, the line numbers don't match between the edit box and the program view from the new line to the end. Therefore, the drawing of line numbers in the edit box was updated to display no number fora new line (just the '+' character). In the line number paint routine, each line after the new line needed to have one subtracted from its real line number in the edit box document to match the line numbers in the program view.
This lead to a problem after the new line was inserted into the program, the line numbers for all the lines after the new line were not updated to reflect their real line numbers. This was corrected in the capture modified line routine. When the line reported was marked as a new line, the update routine of the line number widget (the line number area) was called with the coordinates of the line number area rectangle. Technically, only the rectangle from the current line down to the bottom is needed, but I couldn't figure out how to determine the Y-coordinate of the current line. Redrawing the whole line number area shouldn't be a problem.
[commit c75d67d509]
This lead to a problem after the new line was inserted into the program, the line numbers for all the lines after the new line were not updated to reflect their real line numbers. This was corrected in the capture modified line routine. When the line reported was marked as a new line, the update routine of the line number widget (the line number area) was called with the coordinates of the line number area rectangle. Technically, only the rectangle from the current line down to the bottom is needed, but I couldn't figure out how to determine the Y-coordinate of the current line. Redrawing the whole line number area shouldn't be a problem.
[commit c75d67d509]
Wednesday, March 13, 2013
Program View Line Numbers
A number of changes were made to display the line numbers in the program view similar to the edit box. The paint function in the program line delegate was updated to display the line number and the program line in separate rectangles. The background color of the line number rectangle is displayed in light gray like the edit box. To space the characters in these rectangles nicely, a half character space was added on both sides of the line number and in front of the program line text.
Before the line number can be drawn, the width of the line number rectangle needs to be determined, which is based on the number of lines present in the program. A new update width function was added that is called with a new line count each time it changes. This function calculates the number of digits the new line count will take plus one character to account for the two half spaces on either side of the line number. The number of pixels required is calculated and if different from the previous value calculated, the new value is stored into a new member variable and a signal is emitted to indicate that the program view needs to be updated on the screen.
Two other members were added to the class, the pixel width of a digit and the base line number (the number of the first line). The constructor was modified with two new arguments, one for the base line number, which is stored, and the font metrics of the font used for the program view, which is used to get the pixel widget of one digit and is stored for the new width update function.
The lines to set up the program line delegate and program view in the main window constructor needed to be moved to before the initial program is loaded so that the correct line number count gets to the program line delegate. The program changed slot was modified to check when the program line count has changed by checking a new program line count member variable, which is then stored and the update width function is called.
Finally, the program view update signal is connected to a new main window slot that updates the program view rectangle. This slot and the program line count member variable are temporary until a more advanced program model is implemented. Currently the program model is a simple string list model that is unaware of the program. The other commit made was to have the program view use the same fixed width font of the edit box.
[commit 3b68b11d11] [commit a7f38c99e4]
Before the line number can be drawn, the width of the line number rectangle needs to be determined, which is based on the number of lines present in the program. A new update width function was added that is called with a new line count each time it changes. This function calculates the number of digits the new line count will take plus one character to account for the two half spaces on either side of the line number. The number of pixels required is calculated and if different from the previous value calculated, the new value is stored into a new member variable and a signal is emitted to indicate that the program view needs to be updated on the screen.
Two other members were added to the class, the pixel width of a digit and the base line number (the number of the first line). The constructor was modified with two new arguments, one for the base line number, which is stored, and the font metrics of the font used for the program view, which is used to get the pixel widget of one digit and is stored for the new width update function.
The lines to set up the program line delegate and program view in the main window constructor needed to be moved to before the initial program is loaded so that the correct line number count gets to the program line delegate. The program changed slot was modified to check when the program line count has changed by checking a new program line count member variable, which is then stored and the update width function is called.
Finally, the program view update signal is connected to a new main window slot that updates the program view rectangle. This slot and the program line count member variable are temporary until a more advanced program model is implemented. Currently the program model is a simple string list model that is unaware of the program. The other commit made was to have the program view use the same fixed width font of the edit box.
[commit 3b68b11d11] [commit a7f38c99e4]
Monday, March 11, 2013
Saving The Window State Settings
Saving the window geometry alone is not sufficient to save the state of the Program View dock widget. The state of the main window also needed to be saved to preserve the settings of the tool bars and dock widgets, including where they are docked or floating (undocked), their sizes, and whether they are turned on or off. This window state was added to the save and restore settings routines of the main window, which were given the settings name windowState.
A dock widget can also be turned off by clicking its close button on its upper-right corner. To turn it back on, there is a context (right-click) menu that can be accessed by clicking on the unused part of the menu bar or tool bar area. A dock widget can be undocked (to make it floating) by dragging the dock widget title bar away from the main windows. Tool bars can also be undocked.
When I discovered this context menu when noticing that there was an empty tool bar beside the main tool bar that should not have been there. Besides the Program View dock widget, this context menu also showed a blank tool bar and toolBar. The blank tool bar was actually the main tool bar and it was blank because the main tool bar was never given a title (the windowTitle property).
These issues were corrected by assigned the main tool the title Main Tool Bar and the extra tool bar was removed (which must have been added by default when the Main Window GUI class was created and a new tool bar was inadvertently created to hold the tool bar actions).
[commit 9d3c4a9404]
A dock widget can also be turned off by clicking its close button on its upper-right corner. To turn it back on, there is a context (right-click) menu that can be accessed by clicking on the unused part of the menu bar or tool bar area. A dock widget can be undocked (to make it floating) by dragging the dock widget title bar away from the main windows. Tool bars can also be undocked.
When I discovered this context menu when noticing that there was an empty tool bar beside the main tool bar that should not have been there. Besides the Program View dock widget, this context menu also showed a blank tool bar and toolBar. The blank tool bar was actually the main tool bar and it was blank because the main tool bar was never given a title (the windowTitle property).
These issues were corrected by assigned the main tool the title Main Tool Bar and the extra tool bar was removed (which must have been added by default when the Main Window GUI class was created and a new tool bar was inadvertently created to hold the tool bar actions).
[commit 9d3c4a9404]
Sunday, March 10, 2013
Program View Line Numbers – Custom Item Delegates
It will be very helpful during testing if the program view displayed line numbers like the edit box. This was accomplished with what Qt calls a custom item delegate. An item delegate is responsible for drawing the items in a widget and widgets have a default delegate.
A new ProgramLineDelegate class was created with the QItemDelegate class as its base. Since the program list view is read-only, the only function that needs to be reimplemented in this new class is the paint() function, which has arguments to the painter (used for drawing to the screen), the current style option (which contains information about the view item like its bounding rectangle), and an index of the item to paint.
To start simple, the line number is obtained from the row of the index and the text of the line is obtained from the model of the index (currently the QStringListModel setup to hold the program lines), which is used to get the string of the item that needs to be displayed. These two items are formatted using the string "%1: %2" to put the line number followed by a colon and the string of the program line. This string is then drawn to the screen using the painter's drawText() function.
This is crude, but was a proof of concept (this is my first time using delegates). This will be cleaned up next by drawing the line number separately in its own rectangle with a different background color. It will also need to determine the width of this rectangle based on the maximum line number like with the edit box.
[commit 941b1f8e75]
A new ProgramLineDelegate class was created with the QItemDelegate class as its base. Since the program list view is read-only, the only function that needs to be reimplemented in this new class is the paint() function, which has arguments to the painter (used for drawing to the screen), the current style option (which contains information about the view item like its bounding rectangle), and an index of the item to paint.
To start simple, the line number is obtained from the row of the index and the text of the line is obtained from the model of the index (currently the QStringListModel setup to hold the program lines), which is used to get the string of the item that needs to be displayed. These two items are formatted using the string "%1: %2" to put the line number followed by a colon and the string of the program line. This string is then drawn to the screen using the painter's drawText() function.
This is crude, but was a proof of concept (this is my first time using delegates). This will be cleaned up next by drawing the line number separately in its own rectangle with a different background color. It will also need to determine the width of this rectangle based on the maximum line number like with the edit box.
[commit 941b1f8e75]
Loading File and New File Issues
While testing with the new program view, when doing a File/New, the last line in the document remained in the program and the line was set modified. With New, the entire program should be cleared. Further testing revealed additional problems when loading a new file replacing the current file where the lines in the old file were not being removed before the new file's lines were inserted.
Some additional checks were needed to properly handle these situations, which occur when the document is empty. If the cursor move failed (which occurs when the file is emptied either with a New or before a new file is loaded), if the change indicates one character was added (occurs with the first of two change signals), then a New operation is occurring. The modified line variable is set to -2 to indicate that a New is in progress so that when the second signal is processed, the code knows if it is due to a New and not a file load. Otherwise, if the current line count is zero (the document was empty before the change), then this is the first signal of a file load and should be ignored.
When the document is empty and neither of these conditions exist, then all of the document contents were removed, either because a new file is being loaded, a New was selected, or all of the characters were deleted (for example, with repeated deletes or Selected All and Delete). For the first two situations, all of the lines of the program should be reported as deleted, but for the third, the last line should remain and be set as the modified line. The load file conditional occurs when the cursor move failed and the New previously set the modified line to -2. For these conditions, the net line count is set to the number of lines that were in the document, the new line count is set 0 and the change at the beginning of the line flag is set because it is not set when the document is empty.
At the end of the document change routine where the modified line is set to the current cursor line (the end of the change), it needs to instead be set to -1 if it currently set to a -2 from a New operation, so that the first (and only) line in the document after a New operation is not marked as modified.
One other minor problem was also discovered when an empty file is loaded and the document was previously not empty. The window modified flag was set (shown with an asterisk after the file name in the window title bar). I'm not sure why this occurs, but it was corrected by clearing the window modified flag after a program is loaded and the document is set. Reseting the edit box document's modified flag was not sufficient.
Finally, it was noticed that the program view list widget was grabbing focus when a new file was loaded or New was selected as evidenced by the edit box cursor disappearing and the focus could be seen be the light blue focus indicator around the widget. This list view widget was prevented from grabber focus by setting its focusPolicy property to NoFocus.
[commit 65bd6a9233]
Some additional checks were needed to properly handle these situations, which occur when the document is empty. If the cursor move failed (which occurs when the file is emptied either with a New or before a new file is loaded), if the change indicates one character was added (occurs with the first of two change signals), then a New operation is occurring. The modified line variable is set to -2 to indicate that a New is in progress so that when the second signal is processed, the code knows if it is due to a New and not a file load. Otherwise, if the current line count is zero (the document was empty before the change), then this is the first signal of a file load and should be ignored.
When the document is empty and neither of these conditions exist, then all of the document contents were removed, either because a new file is being loaded, a New was selected, or all of the characters were deleted (for example, with repeated deletes or Selected All and Delete). For the first two situations, all of the lines of the program should be reported as deleted, but for the third, the last line should remain and be set as the modified line. The load file conditional occurs when the cursor move failed and the New previously set the modified line to -2. For these conditions, the net line count is set to the number of lines that were in the document, the new line count is set 0 and the change at the beginning of the line flag is set because it is not set when the document is empty.
At the end of the document change routine where the modified line is set to the current cursor line (the end of the change), it needs to instead be set to -1 if it currently set to a -2 from a New operation, so that the first (and only) line in the document after a New operation is not marked as modified.
One other minor problem was also discovered when an empty file is loaded and the document was previously not empty. The window modified flag was set (shown with an asterisk after the file name in the window title bar). I'm not sure why this occurs, but it was corrected by clearing the window modified flag after a program is loaded and the document is set. Reseting the edit box document's modified flag was not sufficient.
Finally, it was noticed that the program view list widget was grabbing focus when a new file was loaded or New was selected as evidenced by the edit box cursor disappearing and the focus could be seen be the light blue focus indicator around the widget. This list view widget was prevented from grabber focus by setting its focusPolicy property to NoFocus.
[commit 65bd6a9233]
Saturday, March 9, 2013
Viewing Program Changes
To monitor the contents of the program, which will be updated by the program changed signal, a Program View dock widget was added to the right side of the application GUI using Designer. A dock widget can be docked to any side of the window, through this dock widget was restricted to the left and right sides. A dock widget can also be undocked from the main window.
A QListView widget was added to the Program View dock widget. The editTriggers property was set to NoEditTriggers to prevent editing and the selectionMode property was set to NoSelection to prevent selection. In other words, this list view was made read-only.
A QListView is meant to work with a data model. Eventually a custom Program Model will be created that will hold the program. The MainWindow class will contain a pointer to the Program Model. To keep it simple to start, the predefined QStringListModel was used. This model simply maintains a list of strings, which for now are set to the program line strings.
The program model is instanced in the MainWindow constructor, which must be done before the edit box is instanced, since the edit box will generate a program change signal. This model is then assigned to the QListView widget. Any changes to the model will be reflected in the dock widget. The program changed slot in main window was modified to update the program model as changes are received instead of outputting the changes to the console.
[commit 60e125362e]
A QListView widget was added to the Program View dock widget. The editTriggers property was set to NoEditTriggers to prevent editing and the selectionMode property was set to NoSelection to prevent selection. In other words, this list view was made read-only.
A QListView is meant to work with a data model. Eventually a custom Program Model will be created that will hold the program. The MainWindow class will contain a pointer to the Program Model. To keep it simple to start, the predefined QStringListModel was used. This model simply maintains a list of strings, which for now are set to the program line strings.
The program model is instanced in the MainWindow constructor, which must be done before the edit box is instanced, since the edit box will generate a program change signal. This model is then assigned to the QListView widget. Any changes to the model will be reflected in the dock widget. The program changed slot in main window was modified to update the program model as changes are received instead of outputting the changes to the console.
[commit 60e125362e]
Entire Loaded Program Detection
The only remaining use of edit box ignore change flag mechanism was to stop detection when the document was set using the reimplemented setPlainText() function, which set this ignore flag before calling the base class function and cleared it afterward. The document change function upon seeing this flag set returned without processing the change.
Since it was now desired to process this change and report all lines as being added, the ignore flag mechanism was removed. Also, the remaining functionality of the reimplemented setPlainText() function was calling the base class function and then setting the line count variable. The line count variable will now be set by the document change function, and since this function was only calling the base class function, it was also removed.
For some strange reason, there are actually two document contents change signals generated when the document text is set, one where it indicates one character removed and none added, and a second one with no characters removed and the number of characters in the file added. My guess is that the first signal is generated from the document being cleared before being set, and the one character is an empty line where the document always contains at least one block (with a single new line).
This first change signal needed to be ignored, which can be accomplished by checking if the document is empty. However, this is not the only case where the document could be empty (like if all the characters were deleted). Another indicator was needed for this condition. The document change function does a move cursor position by the number of characters added to determine where the cursor will end up. It turns out that this function returns whether the move succeeded. If the document is empty, this move fails, so this status is captured. If the document is empty and the move failed, the document change function only resets the modified line and returns.
The cursor position move also fails when with the second signal because the number of characters added is one more than the cursor can be moved. Since this move fails, the number of lines modified ends up being zero instead of being set to the number of lines in the document that were added. To emit the correct number of lines inserted, the number of lines changed is only adjusted if the cursor move succeeded or the number of lines modified is not less than the net line count change when lines were added to the document.
[commit 23c1ace139]
Since it was now desired to process this change and report all lines as being added, the ignore flag mechanism was removed. Also, the remaining functionality of the reimplemented setPlainText() function was calling the base class function and then setting the line count variable. The line count variable will now be set by the document change function, and since this function was only calling the base class function, it was also removed.
For some strange reason, there are actually two document contents change signals generated when the document text is set, one where it indicates one character removed and none added, and a second one with no characters removed and the number of characters in the file added. My guess is that the first signal is generated from the document being cleared before being set, and the one character is an empty line where the document always contains at least one block (with a single new line).
This first change signal needed to be ignored, which can be accomplished by checking if the document is empty. However, this is not the only case where the document could be empty (like if all the characters were deleted). Another indicator was needed for this condition. The document change function does a move cursor position by the number of characters added to determine where the cursor will end up. It turns out that this function returns whether the move succeeded. If the document is empty, this move fails, so this status is captured. If the document is empty and the move failed, the document change function only resets the modified line and returns.
The cursor position move also fails when with the second signal because the number of characters added is one more than the cursor can be moved. Since this move fails, the number of lines modified ends up being zero instead of being set to the number of lines in the document that were added. To emit the correct number of lines inserted, the number of lines changed is only adjusted if the cursor move succeeded or the number of lines modified is not less than the net line count change when lines were added to the document.
[commit 23c1ace139]
Newly Inserted Lines Fix
When a new program is loaded, the entire program must be loaded into the document (as plain text) and the class that will hold the encoded program. One method would be to set the edit box document to the plain text of the program and then set the program class. Another method is to allow the program change signal that would be emitted when the document is set to the text of the program (which is presently disabled).
After re-enabling the signal when the document text is set, and trying to get the proper signals to be emitted, I discovered that newly inserted lines were not always being emitted correctly. A simple example of this is when a return is entered at the end of the new line - the line was reported as changed instead of inserted.
This problem occurred because the code needed to check if the current modified line is going to be new, but was not previously new before adjusting the number of lines changed and inserted for the new line. When the line is new, but wasn't previously new, the number of lines modified is incremented by one and the number of inserted lines is decremented by one to account for the new line that hasn't been inserted yet.
The aid in debugging, a status indicator character was added to the line number widget after the line number of the current line to indicate when the current line is modified (with an asterisk) or is new (with a plus). This is easier than having a message on the console indicating the line number modified and new status, and then having to refer to edit box to see which line the cursor is at.
[commit 9f15211791]
After re-enabling the signal when the document text is set, and trying to get the proper signals to be emitted, I discovered that newly inserted lines were not always being emitted correctly. A simple example of this is when a return is entered at the end of the new line - the line was reported as changed instead of inserted.
This problem occurred because the code needed to check if the current modified line is going to be new, but was not previously new before adjusting the number of lines changed and inserted for the new line. When the line is new, but wasn't previously new, the number of lines modified is incremented by one and the number of inserted lines is decremented by one to account for the new line that hasn't been inserted yet.
The aid in debugging, a status indicator character was added to the line number widget after the line number of the current line to indicate when the current line is modified (with an asterisk) or is new (with a plus). This is easier than having a message on the console indicating the line number modified and new status, and then having to refer to edit box to see which line the cursor is at.
[commit 9f15211791]
Line Change Detection Complete
The detection of program line changes should now be complete. This feature is necessary so that program lines can be incrementally compiled as they are modified. Even though the implementation was starting to look rather complicated, it turned out to be fairly simply, which was mostly concentrated in the processing of the edit box document's contents change signal that contained sufficient information to report line changes. From the time the new implementation was started, the size of the edit box code was reduced by about half and the previous implementation wasn't complete.
The next step is to connect the new program changed signal from the edit box to some new program class that will eventually hold the BASIC program code, though the goal of the current 0.3.x release series is to get the translator part hooked up. However, this is a good point to make a development release. In preparation for this, there was some minor cleanup of the code:
[commit a2cfa5361a] [commit a13c485632]
The next step is to connect the new program changed signal from the edit box to some new program class that will eventually hold the BASIC program code, though the goal of the current 0.3.x release series is to get the translator part hooked up. However, this is a good point to make a development release. In preparation for this, there was some minor cleanup of the code:
- Renamed the edit box line number widget related functions with the consistent prefix of lineNumberWidget (separate commit).
- Corrected a memory leak of the edit box instance by assigning the main window as its parent.
- Removed the setting of the ignore change flag at the end of the edit box key press event handler (this flag is now only used when a new program is set).
- Updated the copyright of the modified files and a few other very minor changes.
[commit a2cfa5361a] [commit a13c485632]
Friday, March 8, 2013
Capture Modified Line Upon Saving
If the edit box has a modified line, it needs to be reported before the program is saved. This is accomplished by calling the capture modified line routine (currently called when the cursor is moved from a modified line) in the save program routine. This required the capture function to be made public. This function already contains a check if there is a modified line before reporting a change, so if there is not a modified line, no action is taken.
[commit 0561cc9a64]
[commit 0561cc9a64]
Save Action Enabling
There is a feature in LibreOffice where the save action (menu and tool bar) is only enabled when the document has been modified, otherwise it is disabled. Microsoft Office does not have this feature. This feature was simple to add and only required the edit box's document's modification changed signal to be connected to the save action's enabled slot.
[commit 93c856dcb4]
[commit 93c856dcb4]
Select All Correction
While testing, it was noticed that when using the Select All (Control+A) key sequence to select the entire document, a cursor position change signal was not being received. The prevented a line changed signal from being emitted if the current line was modified. The cursor should be moved to the end of the document. Using Select All from either the Edit menu or the context menu did work correctly. This problem was corrected by intercepting the Select All key sequence and calling the select all function that was connected to the menu actions.
[commit 6a7c9c57e4]
[commit 6a7c9c57e4]
Detecting Changes With Undo/Redo
Curiously, when the document's contents change signal is received for an undo or redo operation, the cursor has not been moved yet, so the current cursor position cannot be used to determine the number of lines changed from its line number and whether the cursor is now at the end of the line.
The beginning of the document changed slot function was modified to get the current text cursor and set its position to the position of the change. The line number of this position and whether this position is at the beginning of the line is obtained. This cursor is then moved to the end of the change by moving the cursor right by the number of characters added by the change. This method also works for all of the other types of document changes. Several of the local variables in the function were renamed to make the code clearer.
The reimplemented undo and redo functions are no longer deleted and were removed along with the checks for the undo and redo key sequences in the key press event handler. It is also no longer necessary to keep track of the undo and redo operations on the current modified line, so the undo added slot was removed along with the modified line count and undo active variables. This mechanism was originally implemented to keep track of changes on the current line so that unnecessary line change signals were not emitted, but now the receiver of this signal is will be responsible for detecting actual line changes (see post on March 3).
[commit a9db922c4d]
The beginning of the document changed slot function was modified to get the current text cursor and set its position to the position of the change. The line number of this position and whether this position is at the beginning of the line is obtained. This cursor is then moved to the end of the change by moving the cursor right by the number of characters added by the change. This method also works for all of the other types of document changes. Several of the local variables in the function were renamed to make the code clearer.
The reimplemented undo and redo functions are no longer deleted and were removed along with the checks for the undo and redo key sequences in the key press event handler. It is also no longer necessary to keep track of the undo and redo operations on the current modified line, so the undo added slot was removed along with the modified line count and undo active variables. This mechanism was originally implemented to keep track of changes on the current line so that unnecessary line change signals were not emitted, but now the receiver of this signal is will be responsible for detecting actual line changes (see post on March 3).
[commit a9db922c4d]
Before Selection Not Needed
Previously, information about the selection before a document change operation was saved. This information was used to figure out what text was replaced by the operation. This is no longer needed because this information can be determined from the position received in the document's contents change signal and from the current cursor position, which is at the end of the change.
Therefore, the before selection no longer needs to be saved. Also, since this was the only use of the Selection class, this class was also removed.
[commit ebffb4445c]
Therefore, the before selection no longer needs to be saved. Also, since this was the only use of the Selection class, this class was also removed.
[commit ebffb4445c]
Thursday, March 7, 2013
Adjusting/Correcting Return Key Behavior
Previously, a Return key only inserted a new line when the cursor was at the end of a non-blank line. Otherwise, the cursor is moved to the beginning of the next line. This will reduce accidentally breaking lines in the middle of them. The Control+Return key was implemented to insert a new line always. Upon, using the edit box for a while, I decided to make Return insert a new line when on a blank line.
A problem was corrected when there was a selection, a Return key ignored the selection an moved to the next line instead of replacing the selection. The code was changed to only move to the next line when there is no selection.
There was also a problem when a selection went across two lines, with part of the second line selected. A Control+Return key entered should replace the selected text with a new line, which it did, however, the edit box contents were no redrawn properly where the selected characters on the second line remained selected on the screen. These characters were not actually selected and the were deleted from the document. Must be some sort of bug in the Qt libraries or the libraries routines were not being utilized correctly.
This problem was corrected by replacing the insert text call of a new line with the creation of a new key press event with a Return key, calling the QPlainTextEdit base class key press event handler, deleting the key press event and returning.
[commit a8b9f09778]
A problem was corrected when there was a selection, a Return key ignored the selection an moved to the next line instead of replacing the selection. The code was changed to only move to the next line when there is no selection.
There was also a problem when a selection went across two lines, with part of the second line selected. A Control+Return key entered should replace the selected text with a new line, which it did, however, the edit box contents were no redrawn properly where the selected characters on the second line remained selected on the screen. These characters were not actually selected and the were deleted from the document. Must be some sort of bug in the Qt libraries or the libraries routines were not being utilized correctly.
This problem was corrected by replacing the insert text call of a new line with the creation of a new key press event with a Return key, calling the QPlainTextEdit base class key press event handler, deleting the key press event and returning.
[commit a8b9f09778]
Subscribe to:
Posts (Atom)