Saturday, January 11, 2014

Program – Saving Text Of Error Lines

Now that two minor problems found during testing have been corrected, the next step in changing the program loading process is to handle lines with errors when loading the program.  This is accomplished by saving the text of the line with an error in the line information array (which also contains the offset into the program code, the code size, and error index if any of the line).

When a line has an error, the text of the line is stored in the new text variable in the line information for the line.  This variable is cleared when a line does not have an error.  Now, when the text of a line is requested (by the edit box when processing a program change signal), if the line has an error, this text is returned instead of recreating the code for the line (since there is no code for the line).

When a line is changed or inserted and the line has an error, a program change signal is no longer emitted.  Only the edit box changes and it already has the text of lines inserted with an error.  However, when a line is appended, a program change signal is always emitted regardless of whether it has an error (lines will only be appended during loading and the edit box will need the text for all lines including those with errors).

The program changed slot of the edit box class was modified to no longer check for lines with errors (by checking if the line text string was null) because the program unit attached no longer sends signals for lines with errors (if the change originated from the edit box).

[commit 4a110b2735]

Dictionary – Remove Correction

A minor problem was discovered with the dictionary class, which can be demonstrated by entering the single statement "a=0" into an empty program and then introducing an error on the line (for example, "a=0b") and entering the line.  Once the error is removed, the line is recreated incorrectly as " = 0" (note the space where the "a" should be).

When the statement is first entered, the "a" variable gets entered into the dictionary as "A" (because variable names are case insensitive).  When the error is introduced, the statement is dereferenced (both the variable "a" and the constant "0" should be removed from the dictionaries).  However, when the attempt to remove "a" from the hash in the dictionary, it does not match the "A" that was put into the hash originally.  The dictionary item is removed (from the key list).  When the "a" is added back, the dictionary sees that it is already in the hash because it was not correctly removed and returns it index and the name doesn't get added back to the key list, which still has an empty name for the index.

This problem was corrected by adding a case sensitivity argument to the remove functions of the dictionary and info dictionary classes with a default of case insensitive (same as for the add functions).  For dictionaries that use the case sensitive option (remark and string constant), they must also use it when removing dictionary entries.  The remove function converts the obtained key from the key list for the index specified to upper case for a case insensitive dictionary so that the hash is properly removed.

[commit d7dec3ca11]

Friday, January 10, 2014

Edit Box – New Program Correction

A problem was found with the New program command.  The problem occurs when clearing (New) the loaded program.  After clearing the program, as soon as a character is entered, a crash occurred.  The problem occurred because while the document in the edit box was cleared, several of the other variables were not, so the edit box tried to remove all the lines from the attached program unit that had already been removed.  The extra selections list, line count, modified line number, and modified line is new flag variables also needed to be reset.

[commit 96557e5562]

Wednesday, January 8, 2014

Program – Append Update Operation

Complicating the new loading process is the handling of lines with errors.  When a line containing an error is entered into the edit box, no recreation of the line is necessary since the edit box already has the text.  However, when a program is being loaded from a file and a line has an error,  the text of the line has to be entered into the edit box.

When the edit box retrieves the recreated text for a changed line, the program unit returns a null string for a line with an error.  For null strings (lines with errors), the edit box ignores the line since it already has the line in the document.  The program unit will be changed to return the line with an error, and it will not send a program change signal if the line originated by a change from the edit box document.  However, when the program class is loading a program from a file, it will send program change signals for lines with errors.

The program unit will need to know whether an update came from the edit box (no signal) or program load (send signal).  During the loading of the program, the lines are loaded sequentially and each will be added (appended) to the end of the program.  If the current program unit update routine was used as is, the new program load routine would need to maintain a line number which would be incremented for each line and passed to the update routine.

To simplify the program load routine and give the update routine the ability to determine the caller (edit box or program load), a new append operation was added (in addition to the insert, change and remove operations).  The update routine detects the append operation by whether the line number passed to it is set to a -1, which the program load routine will use as it adds lines to the end of the program (and it won't need to keep track of line numbers).

When the update routine sees the line number set to -1, it sets the operation to append and the line number to the current count of lines in the program.  Otherwise, the append operation is the same as the insert operation.  The operation enumeration was moved from the error list header file to the program model header file with the new append operation.  This enumeration was only in the error list header file for the set change index routine, but this routine had been removed though its definition was accidentally left behind (it was removed).

[commit b795a47120]

Tuesday, January 7, 2014

Program Loading Process

The main window class currently loads the entire text of the program read from the selected file.  This text is given to the edit box instance using the setPlainText function, which is overloaded from the QPlainTextEdit base class, and just resets the cursor valid flag before calling the base class function.

The document of the edit box then emits a document changed signal, which is processed and the attached program unit is updated.  The cursor valid flag prevents the program change and error signals from the updated program unit from being processed, otherwise an infinite loop would occur.  Once the cursor is moved (the cursor position is changed after the document is changed), the cursor valid flag is set and the errors are processed.

This process will be changed to where the new program class will load the program from the file into the program unit.  Later all the subroutines and functions that are included in the program file will be detected and each loaded into a separate program unit.  This change in the program loading process will be handled over several sets of changes and will be explained in the next set of posts.

Sunday, January 5, 2014

Edit Box – Error Handling During Startup

During startup when the program is loaded into the edit box, any errors detected in the program were saved in a member variable until the cursor became valid.  A valid cursor is needed in order to generated the extra selections used to highlight the errors.  The error list changed routine was then called, which would process the saved errors and clear the saved errors list.

The mechanism was modified where any errors are ignored during startup.  When the cursor becomes valid, the errors are retrieved from the attached program unit and the extra selections are generated.  The saved error list member variable was no longer needed and was removed.  Access functions were added to the program model to obtain the error count and an error item by index.

[commit 10724e4aab]

Edit Box – Line Wrapping Problem

While working on the next set of changes, an unrelated problem was discovered with error highlighting.  The problem occurred when there were long lines that wrapped onto the next line.  The problem was first noticed when a line with an error was modified and error was shifted to the wrong place.  The problem also occurred in other situations, including moving to an error that was in the wrapped portion of a line, or when a recreated line was after a wrapped line.

The problem was identified to be the use of the findBlockByLineNumber() function, a member of the QTextDocument class that holds the document of the edit box (in the QPlainTextEdit base class).  This function was being used to get the text block for a given line number, which was then used to gets its position within the document to set the position of the cursor.

However, this function was not working as expected.  What it actually does is return the text block of the actual physical line specified, which takes into account wrapped lines where each part of a wrapped line counts as separate lines.  The findBlockByNumber() function does work as needed and does not consider wrapped lines.  This latter function was already being used in two places, but not in three others.

On the surface, these two functions appear to do the same thing for a plain text document.  The only difference in the help documentation was in the argument, one taking a line number and the other taking a block number.  It was incorrectly assumed that line number meant the same thing as block number.  It is true that each line is a block in a plain text document, but a line number actually represents the physical line on the screen.  Once the latter function was used throughout, there were no problems.

[commit bf7fb54a79]

Saturday, January 4, 2014

Main Window – Multiple Edit Boxes

The application will eventually support multiple edit boxes where the subroutines and functions can be opened at the same time in additional edit boxes.  The main routine or any of the subroutines or functions could also be opened in multiple edit boxes.  This support will be added later, but some preparation work can be done and this will be useful in the reorganization of the program and edit box classes.

Currently there is a list of actions that are built and given to the edit box instance for its context menu.  This context menu will only be assigned to the edit box that is currently active and only one edit box will be active at a given time (the one that has focus).  When the focus changes to a different edit box, the context menu needs to be removed from the edit box losing focus and added to the one gaining focus.  To make this easier, the list of actions are built and stored into a new member variable.  This list will be assigned to an edit box instance as needed.

In addition to setting the actions (context menu) of an edit box, the various signals from the edit box needs to be connected to the various actions in the context menu (for enabling and disabling the actions) and to the status bar update slot (for the cursor changed signal).  These items need to be done when an edit box instance becomes active.  For the edit box losing focus, the context menu (actions) needs to be removed and the signals disconnected.

This code was put into a new edit box set active routine that takes an edit box instance as an argument.  Preliminary code was added for first disconnecting the signals and removing the actions of the edit box losing focus.  This code was commented since there is currently only one edit box instance.

[commit 5b8741768c]

Friday, January 3, 2014

Program View – Edit Box Dependencies

Continuing with the reorganization of the program and edit box classes, the program view dock widget used in the main window class and is connected to the program unit, contained two minor dependencies on the edit box class the needed to be removed.  One of these dependencies required the edit box instance to be created before the program view widget could be initialized.

This dependency was that the font of the program view was set to the same fixed width font set in the edit box.  In was not necessary to use this font for the program view.  In fact, using the default proportional font uses less width than the fixed width font.  So the font of the program view widget is no longer set to the edit box font letting it use the default font.

The other dependency was in the creation of the program line delegate used to draw the program lines of the program view widget.  The base line number is passed to this delegate so that it knows what line number to use for the first program line.  This constant is currently set to zero so that the line numbers match the program line indexes to make debugging easier.  This constant was defined in the edit box class since it also needs this value.  To eliminate the dependency on the edit box class definition, this constant was moved to the main header file as a global definition.

[commit f06fa7c304]

Thursday, January 2, 2014

Main Window – Status Bar Ready Flag

In the main window class there was a flag indicating when the status bar was ready to accept the signal from the edit box for when the cursor was moved.  The line and columns numbers in the status bar along with the message are updated when this signal is received.

The status bar ready flag was needed in the program load routine to prevent the "Program loaded" message was being displayed during the initial loading of a program at startup because the status bar was not created yet.  The status bar was created after the edit box instance and the program was loaded.  The edit box instance needed to be created first since that is where the program was loaded to, and the status bar create routine made the connection from the edit box cursor changed signal to the state bar create slot.

The main window constructor was modified to create the status bar first.  The connection of the signal was moved from the status bar create routine to after where the other edit box to main window signal/slot connections are made.  This eliminated the need for the status bar ready flag and it was removed.

[commit ac678921b3]