|
Post by mueh on Dec 27, 2018 1:39:15 GMT -5
Loop when Display Char for Invalid characters set to blank and restart of SPFLite . OPT allows to set InvChar to blank when blank added to Normal Characters for Screen display . Blank is displayed for x'00' untill restart of SPFLite is done . Loop seems to be at line 5741 in _SPFLite.bas after retart and edit of file which has x'00' in it . cTbl = ENV.Charset + " " ' Get local valid character table t = ENV.InvChar DO WHILE i ' Make them all the chosen MID$(lTxt, i, 1) = ENV.InvChar ' Invalid character substitute i = VERIFY(lTxt, cTbl) ' Get location of any further unprintable chars LOOP ' I think it only can loop when ENV.InvChar = "" and Invalid character substitute fails ( or not in cTbl ) possible fix could be cTbl = ENV.Charset + " " ' Get local valid character table + blank t = ENV.InvChar if t = "" then t = " " ' MUEH Hope it can be used DO WHILE i ' Make them all the chosen MID$(lTxt, i, 1) = t ' Invalid character substitute i = VERIFY(lTxt, cTbl) ' Get location of any further unprintable chars LOOP ' or in _ObjENV.inc line 700 when it is set from INI file where line is "InvChar= "+x"0d0a" Blank is needed to get same display result as before V10.1 Edit of x'ff00' in INI at begin of the two CharSet lines results that CharSet is only x'ff' . x'00' in CharSet can't be used as a CRCMV since it is ignored . Found now CRCMV by inserting in INI file x'FF' as first byte of CharSet and Edit of InvChar to x'FF' . Now screen shows "Blank" for x'00' . George it's great to have source . Otherwise i couldn't find Solution . don't understand how sINISetString sINIGetString set ENV.InvChar It would be nice if x'00' in Charset and blank in InvChar would work . Discovered now a 2'nd Problem which occures also in 8.5 When i did FIND x'ff' it find's also x'9f' . Occures also for Alphabetic Characters and x'Cx' x'Ex' Read Manual to see what X does and found If you specify a string operand on a command code, and that string contains a trailing type code of C or X, it implies a case-sensitive comparison Should it find exact match or did i miss something ? Wish you a Happy New Year . Here a file with x'00' in it . SYS1.PARMLIB.MVSRES.TK4-.D (821 B)
|
|
|
Post by George on Dec 27, 2018 11:40:39 GMT -5
Well the real error is allowing blank to be added to the valid character list, THAT I will put a stop to. I haven't explored your examples fully, but if you are editing the INI file and making manual changes to 'see what happens', my only comment is what I have told others previously - "You're on your own, I will NOT look at your problem".
I'll explore this later when I have time.
George
|
|
|
Post by George on Dec 28, 2018 12:08:56 GMT -5
Robert: The whole routine is below. A null string is no problem. The fiddle with the pTxt pointer variable is to avoid wasting time copying the string to local storage if not needed. If no invalid characters, the actual print logic simply uses the string as passed to the routine. And yes, I can now see the redundant setting of the cTbl variable.
I'm not even going to consider the case where ENV.Charset is null. User do stupid things like that, user gets stupid results, tough.
George
'----- Setup possible translated string if a data text string pTxt = VARPTR(sTxt) ' Point at passed string to start IF ISFALSE ISMISSING(sOffset) THEN ' Only do this for text data lines cTbl = ENV.Charset + " " ' Get local valid character table i = VERIFY(sTxt, cTbl) ' Get location of any unprintable chars IF i THEN ' Got some lTxt = sTxt: pTxt = VARPTR(lTxt) ' Copy and force use of the copied version cTbl = ENV.Charset + " " ' Get local valid character table t = ENV.InvChar DO WHILE i ' Make them all the chosen MID$(lTxt, i, 1) = ENV.InvChar ' Invalid character substitute i = VERIFY(lTxt, cTbl) ' Get location of any further unprintable chars LOOP ' END IF ' END IF '
|
|
|
Post by George on Dec 28, 2018 12:21:08 GMT -5
MUEH: I'll have a look at the X'FF' thing - weird. Maybe it is related to Case handling, we'll see.
George
[Update] Yes, it's the case handling. It's being applied to Hex literals and it shouldn't be. Found one instance and corrected, but there's another one still there to track down.
Meanwhile, time for a holiday invitation.
George
|
|
|
Post by George on Dec 29, 2018 14:02:29 GMT -5
Robert: The loop is only performed IF there are any invalid characters, so for 99% of the time, the overhead is almost Nil, just one VERIFY.
And yes, the re-scan should be coded as: i = VERIFY(i+1, lTxt, cTbl) that's an Oops.
As to the alternative methods:
The code that's there is a dozen or so lines of code.
To build the MatchString and NewString variables so we can use REPLACE means: creating the variables in the ENV Object; creating the Property Get stubs; Coding a new Method to build the tables and adding calls to this method from the Object CREATE routine and from the Dialog Callback from the Options dialog. Then replacing the current dozen or so lines with probably about 5-6 lines since we'd still have to setup the pTxt pointer correctly based on whether there was/wasn't any invalid characters.
You KNOW which option I'll always choose, I'm lazy and in this case, performance-wise, it's just not worth it.
George
|
|
|
Post by George on Dec 30, 2018 15:13:06 GMT -5
MUEH: OK, finally got back to SPFLite. The X'FF' thing is corrected. HEX searches should have always killed the CASE support, but it obviously wasn't. I suspect this bug has been there for many, many years. Correction will appear in the next release. If you'd like an early release, let me know and I'll email you a copy.
George
|
|
|
Post by George on Dec 31, 2018 11:01:20 GMT -5
Robert: No, the data is passed by reference (as is the norm) so I can't just translate it as that would be altering the edit data itself. So the pTxt pointer is set to the location of the passed data, then if translation is needed, a local copy of the data is made, translated, and pTxt is pointed at that. The rest of the code just uses pTxt and needn't worry about whether it's the original Edit data, or the translated copy of it.
I didn't use to care about the overhead of making local copies, but lately I've tried to convert where possible to using local string pointers, the less string assignments the better. There's lots of places that still need revision to switch to string pointers rather than doing the local copy as a default. One of those "I'll do them as I see them projects".
As to writing the translate table version in my sleep, sure, but it's still way more code, scattered in multiple places in different modules.
George
|
|
|
Post by mueh on Jan 4, 2019 1:30:37 GMT -5
George: Learned now that FUNCTION sINIGetString sINISetString use MS Function GetPrivateProfileString WritePrivateProfileString to acess INI and i see that you can't make a change there . What i realy want is to have both translations . no translation as it was done before 10.1 which worked for years and new translation with InvChar . here a Picture from 10.0 and 10.1 What do you think About following Code Change . '----- Setup possible translated string if a data text string
pTxt = VARPTR(sTxt) ' Point at passed string to start
IF ISFALSE ISMISSING(sOffset) THEN ' Only do this for text data lines
cTbl = ENV.Charset + " " ' Get local valid character table
i = VERIFY(sTxt, cTbl) ' Get location of any unprintable chars
IF i THEN ' Got some
t = ENV.InvChar
if t = " " or t = "" or VERIFY(t, cTbl) <> 0 then ' MUEH if Blank(_Dialog) or invalid(_ObjENV) don't translate(same as before 10.1)
else ' MUEH
lTxt = sTxt: pTxt = VARPTR(lTxt) ' Copy and force use of the copied version
DO WHILE i ' Make them all the chosen
MID$(lTxt, i, 1) = t ' Invalid character substitute
i = VERIFY(i+1, lTxt, cTbl) ' Get location of any further unprintable chars
LOOP '
END IF '
end if ' MUEH
END IF '
insert code here Thanks for your cooperation . P.S. Just for info FOLD ON doesn't translate to Upercase since 10.0 . Works in 8.5
|
|
|
Post by George on Jan 4, 2019 12:47:45 GMT -5
MUEH: OK, maybe I should make the translation of unprintable an option. There are two ways, another tick-box for Yes/No, or maybe use a blank InvChar as the trigger to say "don't translate".
I'd like to hear comments from anyone else.
George
|
|
|
Post by George on Jan 4, 2019 15:58:18 GMT -5
I'm afraid I disagree on what is considered invalid. By your definition everything from X'C0" thru X'FF' is valid just because they happens to be international characters.
P'.' in ISPF meant non-displayable characters, and the list was hardware dependent based on what type of 3270 you had. In Windows, non-displayable is based on what Font the user has specified. So P'.' characters are unique by user and what font they have chosen. So SPFLite lets the user designate what's valid or invalid.
In your fixed method, corruption of the display screen could occur when invalid characters are present, and you have removed the user's ability to correct the situation other than by switching to a different font. This is a backwards step.
Your other suggestions for the InvChar are fine by me.
George
|
|
|
Post by George on Jan 4, 2019 16:19:46 GMT -5
MUEH: Yes FOLD somehow just got dropped in V10. I've put it back.
(Amazed anyone even uses it!)
George
|
|
|
Post by George on Jan 5, 2019 13:15:33 GMT -5
Robert: The description for the Charset says "Normal characters for screen display and for P'.' picture literals". Could be worded better, but I doubt anyone is that confused by it means.
Whether we make it a list of valid characters or invalid characters, it's still a long list. We've already made it easier by tying it to the "English Only" option.
Regardless, from day 1 of the original ISPF, P'.' has meant non-displayable characters. It should stay that way.
Your desire seems to be to make the P'.' list some kind of customized character selection function. Your statement (one for defining what P'.' means, and one for handling undefined font entries) tries to imply these are two different things - they are not.
George
|
|
|
Post by George on Jan 8, 2019 13:08:01 GMT -5
Robert: Everyone: How about simply eliminating the Options => General valid character list, and simply internally build it based on whatever font is currently chosen? If there is a Glyph defined, the character will be added to the valid list.
Leave the Invalid character option there with:
N/n - do no substitution any other character, including a blank - use as the substitute character, whether it is in the valid list or not.
This then begs - what to do with the "Only English letters A-Z and a-z are considered alphabetic" option. I would leave that as only affecting the handling of valid WORD characters. i.e. it would NOT affect the P'.' valid character list.
George
|
|
|
Post by George on Jan 9, 2019 13:53:27 GMT -5
This whole thing started as a simple need - to prevent screen corruption caused by attempting to display characters that were not defined in the current font.
The definition of P'.' is a "bad" character, whether that is because of hardware, the chosen font, or a systems programmer decision for some other reason. The actual reason is immaterial. For windows output we have only one reason - the font, there are no hardware or system programmer reasons.
So if, as I suggested, I simply created the list automatically by examining the valid glyphs in the current font, doesn't that fix our problem and also remove any need for the user to fiddle with a long list of valid or invalid characters?
As to replacing the loop with REPLACE, I shoved the two styles into a benchmark program, and the loop is slower by only 10%. Considering the loop is only done when needed and the REPLACE would be done all the time, I think I'll stick with the loop version.
George
Right now I simply don't see a downside to switching to this method.
|
|
|
Post by George on Jan 10, 2019 13:39:02 GMT -5
OK, I yield. It seems that: - Using a list generated from examining the glyphs in a font to prevent corrupted screens is OK.
- P'.' is the stumbling block as there is no existing definition of what should be in the list, it appears it must be user created.
So there's no choice really but for the P'.' specification to be done the same way we do WORD specification. I'll have to figure out some way to migrate the existing string into the new format.
George
|
|