|
|
Post by Stefan on Nov 13, 2014 11:32:24 GMT -5
Bug: AUTO COLORISATION - display and cursor position error
Affects v8.1.4311 (but was also present in v7.1.4050)
System: Windows 7 Pro, SP1, 64-bit
To reproduce:
1) Create XXX.AUTO profile and include (e.g.) COMMENT1 3 [ ] ie. everything between [ and ] is a comment
2) Open a file of type XXX
3) Type before[comment]after
4) Notice the 'a' of "after" didn't appear when typed and the cursor is now one character to the right of where it should be.
5) Move cursor left and try deleting the 'e' of "fter"
Works fine without colorisation.
|
|
|
|
Post by George on Nov 13, 2014 15:15:15 GMT -5
Stef: Yes indeed, a bug. I'll go give it a chase down. George ---------------------------------- OK, found and fixed. If you want a quick corrected version, then you can download it from the web site. Use the following link: www.SPFLite.com/Files/SPFLite814317.EX_Just rename the file to SPFLite.EXE and replace the current one in the install folder. George |
|
steve
Freshman Member
Posts: 14 
|
Post by steve on Feb 23, 2015 15:17:25 GMT -5
Hi George, I seem to have a similar issue with the most recent version (8.1.5023) and PHP colorization. Notice in the snippit the "//" and compare to screen shot in the attached file. <?php include_once '.\mtgillib.php' ; ?>
<?php
$serverName = "MTGTIGER\TIGERPAW"; /ServerName\instanceName
$connectionInfo = array( "Database"=>"Tigerpaw", "UID"=>"sa", "PWD"=>"Tigerpaw!1");
$con = sqlsrv_connect( $serverName, $connectionInfo);
// Check connection
if (!$con)
{
Log_Trace( "Failed to connect to Tigerpaw DB - ");
die( print_r( sqlsrv_errors(), true));
}
//if (!$con || !sqlsrv_select_db('Tigerpaw', $con)) {
// die('Unable to connect or select database!');
// }
phpsnip.odt (33.35 KB) |
|
steve
Freshman Member
Posts: 14
|
Post by steve on Feb 23, 2015 18:02:13 GMT -5
Seemed to be an issue in the colorization file.
Changed COMMENTS1 6 //
to COMMENTS1 6 // 0
|
|
|
|
Post by George on Feb 24, 2015 13:40:04 GMT -5
Steve: Hmm, obviously leaving out the end operand triggers this. I would have thought parsing would have caught this, obviously not. I'll check this out.
George
Follow up: It appears (If I can read my own code properly) that a missing third operand effectively gets treated as a 1 (one). The validation here is really not up to snuff, I'll add a bit more checking.
|
|
steve
Freshman Member
Posts: 14
|
Post by steve on Mar 6, 2015 6:37:56 GMT -5
I have an additional issue related to the colorization which I'll call ghosting. In the display I am getting random characters in the display in certain areas which color has been applied. I have attached a file which is a screen shot of a section of code, one has a colorization profile being applied and the other which is the same file without colorization. color.pdf (49.44 KB) This has happened with the most current version and at least the previous, I haven't gone back and checked prior to that. Thx, Steve |
|
|
|
Post by George on Mar 6, 2015 12:32:02 GMT -5
Steve: Can you provide the .AUTO file you're using please? It's easier with the exact file rather than me guessing what's in it.
Robert: as to the characters coming from 2 lines previous - that's obviously possible, but right now I can't conceive how since the colorization code is passed the string to be colorized, not a line pointer. However, bugs are bugs, anything's possible.
George
|
|
steve
Freshman Member
Posts: 14
|
Post by steve on Mar 7, 2015 8:35:26 GMT -5
I think these are the file(s) requested... Attachments:HTML.AUTO (6.45 KB)
html.INI (991 B)
|
|
|
|
Post by George on Mar 7, 2015 13:01:48 GMT -5
Steve: Thanks. Still at a loss, maybe I need the actual data file. I tried just typing in a few lines from your screen snapshots, but they seem to work OK. Can you send the actal HTML file that messes up. Here's what I get with my test data and you INI and AUTO files. P.S. I altered the banding colors in the AUTO file so I could see things better. On my monitor, the dark bands are very dark, I can only assume they are much lighter on your monitor. George  |
|
steve
Freshman Member
Posts: 14
|
Post by steve on Mar 8, 2015 6:02:40 GMT -5
Thanks for looking at this George. File attached. I have observed this behavior. I open the file and scroll and see the characters. If I minimize the window and re-open the characters in the positions that ghosted are gone. If I scroll up and back to the position there is ghosting again. if I scroll one way (say down) the ghosted characters have a particular value if I scroll the other (say up) to the same position the characters have a different value but the scrolling repeatedly up and down will produce the same characters depending on the direction. So if I scroll down I always now see an "e" at the end of line 309 and 310, if I scroll back up to it 308 is a "t" and 309 is an "=". I believe Robert was on to the correct analysis. Attachments:Inv_logv2.html (13.02 KB)
|
|
|
|
Post by George on Mar 8, 2015 11:08:15 GMT -5
Steve: OK, thanks for the file, it helps a lot. In your screen snapshot, lines 308-310 appear as: 000308 </td>t
000309 </tr>=
000310 <tr>>
When I view the file I see: 000308 </td>x x = LF char000309 <.tr>x x = LF char000310 <tr>x x = LF charsince I normally run using one of the Raster fonts (in the optional font package) and it has NO invalid character assignments.
So ... although your file appears to be a normal CRLF delimited text file, it actually contains many embedded single LF characters. I'm not sure what font you are using for SPFLite, but be aware that many of the normally available fonts do not handle invalid characters very well. And when SPFLite draws the screen using one of these fonts, and invalid characters are encountered, weird and wonderful things happen.
I believe this is what's happening here. I've attached a screen shot of your file displayed using the Raster font, which shows the LF characters.
1. Check the font you are using, I'm sure you will find the LF char position does not contain a valid graphic character.
2. I'd try downloading and installing the Raster fonts from the SPFLite website, and setting SPFLite to one of the fonts (pick your size)
I'm willing to bet the problem 'goes away'. And maybe you might check as to how embedded LF characters are getting into your files.
George
|
|
steve
Freshman Member
Posts: 14
|
Post by steve on Mar 9, 2015 6:43:57 GMT -5
Hmm,
I am using font "Source Code Pro." The line feeds are likely from the LINUX project I was working on that I copied the code from.
Thanks for taking the time to research and find the issue.
Steve
|
|
|
|
Post by George on Mar 9, 2015 12:08:23 GMT -5
Steve: I had a look at Source Code Pro, and yes, it has a lot of 'holes' which are not defined.
Robert: Yes I guess EOL AUTO would do it. Never thought of that because we added AUTO to handle the Hercules print files better. But whatever works ...
George
|
|
