|
Post by Stefan on Dec 13, 2020 7:11:58 GMT -5
I appreciate you cannot fix what we cannot recreate. I just thought you ought to know that 'there be gremlins in the machinery'. Might come in handy in future.
The "HEX ON and special lines" crash is repeatable - see above post for procedure. And that one kills the current v255 release also.
I'll report any other I find in separate post as requested. Will probably stick them in the Problems and Bugs section. Makes them easier to find in future.
|
|
|
Post by George on Dec 13, 2020 12:51:57 GMT -5
Stefan: If your *New* is this: (I can't find a *Newer*)
this scenario makes little sense, but I condensed it to the minimum keystrokes required to demonstrate the error. <RETURN> key is mapped as (NewLine)
(1) Select 'NEW' from FM page
(2) Type line command N3 on 'Top of Data' line to create 3 lines
(3) Type line command MARK on Line 2
(4) Place a single '<' somewhere on the =MARK> line
(5) Enter primary command HEX ON
(6) Press <Return> key twice more to reposition the cursor
Then I still can't trigger it. But maybe I'm confused by your mapping comment. When you say <Return> I'm not sure whether you want (Enter) or (NewLine)
(Newline) makes no sense since the HEX ON wouldn't be processed, or are you implying an (Enter) after the HEX ON and THEN two (NewLines)
I guess instructions should always be in terms of the SPFLite Primitives so there's no confusion. Either way, I can't make it fail.
Stumped, both v255 and my current refuse to fail.
George
|
|
|
Post by Stefan on Dec 15, 2020 3:23:18 GMT -5
Sorry George, my bad. Having been very specific with keystrokes in the past, I used the wrong verb (Type...) when I meant (Enter..., as in "Type ... and press ENTER"). Also, my keyboard is mapped 3270-style with the the RIGHT-CTRL key as (Enter) and the RETURN key as (NewLine) This should help... but see UPDATE below(1) Select 'NEW' from FM page (2) Type line command N3 on 'Top of Data' line to create 3 lines & press ENTER(3) Type line command MARK on Line 2 & press ENTER(4) Place a single '<' somewhere on the =MARK> line & press ENTER(5) Enter primary command HEX ON & press ENTER (6) Press <Return> key twice more to reposition the cursor
UPDATE!!
I've done more work on this, and now believe the problem lies with screen handling when HEX ON is in effect.
With a brand new CFG file (to eliminate all other variables)
(1) Load any file you like into the editor. (2) Enter HEX ON if the filetype profile doesn't specify it anyway.
You see the usual "1 TXTLine + 2-HexLines + A row of dashes" display for each data line. In case of the 'Top of Data' and the 'Bottom of Data' lines, the 2 HEXLines are blank, for the other TXTLines they show the hex representation.
The hiccup is that the HEXLines have blanks in the line number field. If the user types anything in these areas, SPFLite crashes.
The keyboard primitives treat these areas inconsistently... (Tab) and (BackTab) both get it wrong for the 'Top of Data' and 'Bottom of Data' lines and place the cursor 'in space', but skip correctly for other TXTLines. (except that (Backtab) should jump from line number field to the previous line's data col-1, but doesn't)
(Newline) gets it wrong for every line. (Up), (Down), (Left), (Right) understandably will put the cursor in those areas - so they work as expected.
The FM-NEW scenario is just a special case in point - a new file will always be empty - but the same happens if you load a file with zero records. The HEX ON may be deliberately entered by the user, or it may be inherited from the filetype profile.
You will end up with a weird display like this...
and lots of opportunity to type where you shouldn't.
You can avoid this by entering HEX OFF first. Then data entry (appears to) proceed as usual.
The primitives need tweaking to ensure that they leave the cursor in a 'legal' place, but the simple (Up), (Down), (Left), and (Right) are working as designed, and users expect them to move one char/line at a time. so there's always a chance that a user types into a 'void' on the page.
Hence, I think the input routine needs to validate that the cursor is in a 'legal' place when reading the screen. If you're not certain, it may be better to ignore (UNDO?) the last user interaction and repaint the previous screen (with error message of course) than risk a crash and incur data loss across all open Tabs.
This reminds me of when there were issues with the extra line caused by COLS ON/OFF in various profiles. It seems SPFLite reacts inflexibly when a screen isn't in the format it expected.
|
|
|
Post by George on Dec 15, 2020 9:50:25 GMT -5
Stefan: OK, your screen shot helped. It's triggered by using the crosshair cursors (which I don't use). As soon as I turn them on - Boom!
Off to browse code. (This should be fun)
George
[UPDATE]
OK, tracked it down. Triggered by the MARK logic trying to figure out where the bottom of the vertical line should end.
I'm going to post a new version 2.3.20342.
Note the test name is now SPFLite23, this version contains no logic changes really from 2.2, but I've done a large amount of code shuffling and FUNCTION/SUB/Variable renaming to try and make the code more understandable.
Check the Pre-release topic for the new version.
[\UPDATE]
|
|
|
Post by Stefan on Dec 15, 2020 10:38:30 GMT -5
Hi guys - I had to go shopping so you beat me to it.... see my changed post above (sorry George). I think the 'white space' to the left of the HEX lines are part of the problem.
|
|
|
Post by George on Dec 15, 2020 11:37:52 GMT -5
Stefan: The white space is simply cosmetic. Maybe someday I'll chase down the offending code.
Robert: Error was triggered by some other cosmetic code to adjust MARK lines and the Bottom of Text marker line.
George
|
|
|
Post by Stefan on Dec 15, 2020 13:14:21 GMT -5
We may be at cross-purposes about the 'white space', the vertical ruler line drawing, etc.
Could be we're chasing down different bugs.
The following observed using version 2.2.20350 (labelled SPFLite23.exe)
I start with a completely new CFG file (so no settings like line vertical ruler, MARKs, etc - all totally vanilla)
(1) Load any file - you'll be prompted to create a profile.
(2) Type HEX ON & press ENTER key (3) From the Primary command line, use your (Newline) key - that's RETURN in my case - twice
Assuming 'Top of Data' is your first line, this positions the cursor in column 1 of the visible display on the 'blank' line immediately below the 'Top of Data' line.
(4) Press any alphanumeric key of your choice or even the space bar. (5) Crash
The same happens if the user presses any character incl. space bar while the cursor is anywhere vertically between two line commands in HEX ON view. See red boxed zones in the screenshot.
Hence my earlier description of the various keyboard primitives and how they vary in placing the cursor in 'problem' zones. And because primitives like (Up), (Down), (Left) and (Right) are supposed to be able to move the cursor into those zones, even correcting primitives like (Tab), (Backtab), (Newline), etc to avoid those zones, will not prevent a crash.
Having used SPFLite for years, I can't believe that I have never accidentally tried to type into these zones before, so I must conclude that this did not used to happen in previous versions. Either the primitives used to skip reliably over those zones, or (more likely) SPFLite was more tolerant under those circumstances.
It accepts me typing into other 'read-only' zones, like the excluded lines placeholder or the 'Top Of Data' line, etc.
As always, I hope this helps.
|
|
|
Post by George on Dec 15, 2020 15:33:41 GMT -5
Stefan: OK, the crash portion is solved, a minor tweak. The inconsistencies for the other primitives I will look at long term. Believe it or not, the primitive cursor movement code is perhaps the most convoluted stuff in there. I had a stab at correcting this and all I did was dig a deeper and deeper hole. You have to remember we have TABS ON/OFF, tabs that are off the visible screen, meaning screen repositioning is needed to reach them, then throw in HEX mode where there is not a one for one match between data lines and screen lines and you get the picture. I backed out my attempts and will have another go when I am in the right mood to handle the frustration. Besides, it's my birthday tomorrow, I don't need this aggravation. To clarify the whitespace thing, I was thinking of cosmetic stuff like the following screenshot . George
|
|
|
Post by George on Dec 15, 2020 16:23:53 GMT -5
Robert: I've added to CFGMaint your suggestion for a single table Export.
You will be able to run CFGMAINT -EXPONE [tablename]
to get an Export file of just the named tablename.
George
|
|
|
Post by Stefan on Dec 16, 2020 15:55:05 GMT -5
HAPPY belated BIRTHDAY! At least I hope this is "belated", because nobody should be working on the birthday!!!
CFGMaint: In terms of the 'single table Export' option, won't Robert also need the ability to IMPORT a table file, without human interaction to pick from a list? e.g. CFGMaint -IMPORT <filename-containing-relevant-table(s)>
|
|
|
Post by Stefan on Dec 16, 2020 16:13:01 GMT -5
I am most sorry about this, but,...
On Version 2.2.20255, on the FM-CONFIG tab, I can click on (or type 'S' in front of) a profile name and the profile EDIT dialog pops up.
On Version 2.3.20350, the same action results in a red message across the chosen line 'Select only available for the active instance'
Both version are running of the same CFG file but are not active at the same time. The file shows BUILD=2.3.20350 so I'd have expected v255 to have an issue.
Am I missing something simple or is this a problem?
PS: Awkward page throw in this thread - I hope you caught my previous message on bottom of page 2 of this thread.
|
|
|
Post by George on Dec 16, 2020 16:49:41 GMT -5
Stefan: I really can't see making that a command line option. Just say -IMPORT and select from the file list pulldown. (The unique table exports still appear in the pull-down list).
George
|
|
|
Post by Stefan on Dec 16, 2020 18:23:51 GMT -5
Robert Sorry, I must have misunderstood. I thought you wanted to switch Keyboards without having the rest of the CFG settings, profiles, etc divirging over time (hence no separate Instance). I figured one solution might be to isolate the keyboard table from an EXPORT file and save it separately for each keyboard needed. You could then start SPFlite from a .BAT file (or similar). The bat file would 'Update' the CFG by importing the relevant keyboard table file, leaving the rest of the CFG ASIS and then
Start SPFLite. With the ability to specify the 'filename of the table to be imported' on the CFGMaint command line, the process would be seamless. No user action required, just click the right icon.
|
|
|
Post by mueh on Dec 17, 2020 3:09:57 GMT -5
George: For Stefan's S Profile Problem i think that you didn't change following code . ( Only 1 blank in "Profile: " with 20350) _FMLCmd.inc METHOD FMLCmdSelect(i AS LONG) CASE %FConfig ' Config IF LEFT$(AFList(i).FD.FileName, 10) = "Profile: " THEN ' The Profile Type? Maybe if other find it usefull is suggestion to support Start of an inactive instance instead of saying 'Select only available for the active instance' . I'm doing it now with macro code executed by RMB . Thanks
|
|
|
Post by George on Dec 17, 2020 10:24:43 GMT -5
Stefan: MUEH:
Corrected it. Triggered by SPFLite's own CHANGE command logic. I was cleaning code and did a bunch of variable renames to make them more meaningful. To avoid shifting comment columns as lengths of names changed, I did them all using SPFLite itself
So lines like:
IF LEFT$(AFList(i).FD.FileName, 10) = "Profile: " THEN ' The Profile Type?
if you do a - CHANGE ALL WORD AFList gFMAFList - you get
IF LEFT$(gFMAFList(i).FD.FileName, 10) = "Profile: " THEN ' The Profile Type?
Note the alteration of the literal. The CHANGE command 'eats' extra multiple spaces to the right of the change point.
Stefan: The version number was 'out' because the 2.3 code resided in another folder and my daily 'update the version' process only did the production folder.
MUEH: Not sure how many would find a start of an Instance from the Config menu useful. Comments anyone else?
I'll replace the 2.3 version with a corrected one (2.3.20352)
George
|
|