|
Post by George on Oct 21, 2022 14:07:28 GMT -5
Robert: My concern was simply the format you used
000001 A B C 7 8 9 000002 414243373839 which would be really tough to handle.
George
|
|
|
Post by George on Oct 21, 2022 10:25:30 GMT -5
Well, the COLS aspect is the trivial part of this. The change to support either hex VERT or hex DATA is a whopping huge change. And Robert, please don't say 'sleep on it and it will become simple', since it won't. This affects the guts of how data is entered and how the screen is positioned. The logical cursor position (which tracks physical cursor to logical cursor) will have to be enhanced. Screen display routines also needs enhancing. Screen scrolling also needs enhancing. And a significant # of KB commands that directly update the on-screen data will need changing. Don't hold your breath on this one. George [Added] BTW, the ISPF implementation of HEX DATA is NOT the way you seem to be picturing it. See attached.
|
|
|
Post by George on Oct 20, 2022 15:34:59 GMT -5
It's interesting how careers develop. I started out working in a bank, in the branches. At one point I was sent to take a series of aptitude tests. A few months later I was offered a position in what was then called "Machine Accounting". i.e. punch card processing, slugging million line card files around, it was more like manual labour. However it became plug-board wiring, then onward to 1401 operations, programming and further onward to 360's etc. etc. for almost 40 years.
And to think, I could have been a bank manager!
|
|
|
Post by George on Oct 20, 2022 13:04:49 GMT -5
Stefan: As you indicated, this is a hairy area. It has been poked and prodded, and totally (and I do mean totally) rewritten 3 times over the years. But as we've added stuff like Line Macros etc. to the mix, the last re-write design is being obviously subverted by the additions.
What it really needs is a fourth total rewrite. And you know, I just don't think it's in me. When I was exploring your B& bug, I truly realized how much I don't know anymore about how it all works. It's the most intricate logic I've ever written because it simply has way more to cope with internally than you can imagine.
It really comes down to a simple statement - "If entering a Line command which involves a companion Primary command (like CUT), then avoid also entering other 'normal' sets of line commands".
I wish I could tackle stuff like this, but as I approach 80, I have to recognize the things I can't (or shouldn't) tackle. Like walking without my cane or walker)
George
|
|
|
Post by George on Oct 18, 2022 13:25:56 GMT -5
OK, how be I restore the code. The Doc has had it removed, so it will be simply be 'not mentioned' anywhere.
The code can go away later, the doc is harder to back out since I made many other changes in there at the same time, don't want to have to re-do them.
George
|
|
|
Post by George on Oct 18, 2022 12:35:00 GMT -5
Why, if it hasn't been used in years, and we're going to deprecate it, who can it impact?
George
|
|
|
Post by George on Oct 18, 2022 12:11:04 GMT -5
Sorry, yanking is so quick and easy, they're gone.
George
|
|
|
Post by George on Oct 18, 2022 9:41:36 GMT -5
I am going to 'retire' DROP and KEEP.
George
|
|
|
Post by George on Oct 17, 2022 14:34:34 GMT -5
Hopefully, truncation should be gone, the box sizes are calculated based on the final scaled font size.
George
|
|
|
Post by George on Oct 17, 2022 13:42:45 GMT -5
OK, there is now an option on the Options -> Screen to provide a Status Bar / Tab Title Scale factor, the default is 1.0, smaller values shrink the font, larger values increase it. The size of SB boxes is now (hopefully) based on the ultimate font size used, so we shouldn't see truncated data displayed.
I need feedback from the next beta as everyone runs with different monitors, different Windows text file sizes etc. so this support may need some additional tweaking.
George
|
|
|
Post by George on Oct 17, 2022 13:34:33 GMT -5
Sounds good. Going from the PB version to the PCRE version is trivial.
George
|
|
|
Post by George on Oct 17, 2022 9:05:12 GMT -5
Robert: No problem if REGEX is needed. If you do, it's probably better to use the PCRE version rather then the built in PB version.
Calling is simple, here's a sample:
t = PCRERegexCompile("\.[0-9]{6}\-[0-9]{6}\.[0-9]{6}") ' Setup PCRE Search for .999999-999999.999999 PCRERegexTest(str, 1, j, k) ' Look like a Backup file?
t = Null string if the compile OK, or an error message string The test scans the str, starting at position 1, and returns j=found location and k=length
Problem is you'd need the code for the two functions as well as some global and initialization code - awkward
Maybe use PB's version, with a view to swapping later to the PCRE version. The PB version is very close:
REGEXPR mask$ IN target$ [AT start&] TO iPos& [, iLen&]
George
|
|
|
Post by George on Oct 17, 2022 8:50:45 GMT -5
Stefan: You're probably right that a better default scheme should be shipped. Yes, the scheme may or may not 'look nice' with the users other color choices, but at least it won't just be monochrome. I'll try and get this in place, just have to choose the new defaults.
George
|
|
|
Post by George on Oct 16, 2022 15:56:45 GMT -5
Robert: You've totally lost me. I do not grasp the <- syntax diagram type stuff, to me it's just meaningless confusion.
The profile for a tab if fetched from the CFG file. That is the basis for all Profile related decisions in that tab.
If a Profile variable is altered, the Tab's version of the Profile data is ALWAYS altered. And if the profile is UNLOCKED, that variable in the profile is altered in the CFG database as well.
So, to me, your suggestion that I might be able to 'revise the definition of a Profile Object to reflect this bi-modal behavior" is meaningless. Just what would does that mean? You're pointing in a direction, and I don't have a compass.
I mean the Profile data is already bi-modal, it can be read, and it can be altered (under LOCK control), so what are you suggesting to change?
Mark me very confused.
George
|
|
|
Post by George on Oct 16, 2022 14:28:55 GMT -5
Profiles are swapped in and out all the time. Think MEdit where all the files may not be the same Profile type.
A Profile object is simply the current collection of Profile variables based on where and how it's used. e.g. Every open tab (including FM) has it's own Profile object representing THAT tabs 'current' profile. i.e. Every tab has a 'Prf' object defined. So, within that tab, any code that asks for Prf.HEX gets the value from THAT tabs Prf Object. Any command like HEX ON/OFF does the SET to the Prf object within that tab. (N.B. Prf here is not something special, it's just the name of the Profile object as I have declared it within the tab's own data object. (Which if you looked at SPFLite code) is pointed to by the GLOBAL TP variable, which is a pointer to an object.
Objects are fine, and provide great data isolation, but a Profile cache will be a global resource, so handling it has to be done carefully, especially if it is done within the Prf objects which are local.
|
|