|
|
Post by George on Jun 19, 2022 14:24:57 GMT -5
Robert: We never should have implemented (DataInsert). That function, along with hi-liting is just becoming more than I can manage. It is pervasive and affects all kinds of data changes.
Correcting this error is going to be incredibly hard; I don't even know where to start.
George
|
|
|
|
Post by George on Jun 19, 2022 14:48:07 GMT -5
What it looks like is a revision of the sequence of events in doing an insert, but that happens in several places and the details are all different. Makes it hard to 'find a place' to correct this. It's REALLY awkward.
George
|
|
|
|
Post by George on Jun 20, 2022 12:49:57 GMT -5
Robert: You have to remember how so many of the features were added - expediency - which in many cases turned into inserting similar, but not identical code into a variety of places. It comes back to haunt you at times like this when there is no single point to 'fix' a problem.
And yes, (DataInsert) is active for PT mode, you wouldn't have let me get away with saying it wasn't supported in PT.
George
|
|
|
|
Post by George on Jun 20, 2022 14:06:59 GMT -5
OK, it seems to be corrected, I'll post another beta.
George
|
|
|
|
Post by George on Jun 20, 2022 15:17:26 GMT -5
You're always more confident in my debugging skills than I am.
The whole last re-write of attribute support sucks! I wish there were a whole different method of storing the text/attribute stuff, and I've experimented with a bunch of ideas, but each fails somewhere - usually performance. It's just hard to design something that can handle the attribute bits for each character in a text string. (it needs 16 bits)
Right now it's a matching WSTRING, which at least lets me perform duplicate parallel String functions on the WSTRING to match the Text strings as they're manipulated. In this bug case, it turned out to be a faulty RTRIM$ on the WSTRING version (along with some other basic logic flaws)
There's just no 'nice' storage solution around.
George
|
|
|
|
Post by George on Jun 21, 2022 7:29:17 GMT -5
I've thought of a 'character' structure as well, but then you lose all the built in PB STRING functions, the speedy string ARRAY functions (SORT, Search etc.) it would mean re-creating all those functions, and PB has an extensive set.
And I tested making a single text line into an Object. Performance plummets. I did a test just setting and fetching a string variable from a normal array and from an array of Objects. About a 20x difference.
Yep, no reasonable way.
George
|
|
|
|
Post by George on Jun 21, 2022 11:54:52 GMT -5
Robert:
Not so simple. Mostly because altering the text data and the attr data are not setting them to the same string So the macro would need both values as parameters.
e.g.
It's not QAssign(name, newvalue)
it's
QAssign(name, txtValue, attrValue)
And many routines (like the one I recently fixed) do not directly modify the real data storage area, but simply manipulate passed strings, so the macros to modify the real data areas wouldn't help in those cases.
So we're talking replacing a couple lines like:
me.LTxtSet(ix, tt) ' N.B. LTxtSet is not just a simple assignment, it's a METHOD with 6-8 lines of code
me.LAttrSet(ix, tc) ' tt is the text data, tc is the attr data
with
QSetTxt(ix, tt, tc)
which would just generate basically similar code.
I just don't think it buys us anything.
George
|
|
|
|
Post by George on Jun 21, 2022 15:16:00 GMT -5
"Would it error proof things?" I doubt it. The type of errors that have been uncovered lately have not been those that could be described as caused by some mechanical coding error.
What is far more likely is that creating these macros, and altering code to use them, would generate far more errors than just leaving things alone.
You touch working code - you break it.
Go look at some real code, try _TabData.INC -> Join - a typial Primary command. Review that and see just how many places a macro might be used to "error proof" the code.
I'm not trying to be negative, just realistic.
George
|
|
|
|
Post by George on Jun 22, 2022 8:52:14 GMT -5
Robert: I don't want you to think I'm anti-macro or something like that. SPFLite is already crawling with macros, if you look in _Types.INC you'll find probably 150+ macros in use already. Sure, most are trival, but they were created to do exactly what you're proposing - eliminate potential dumb coding errors.
George
|
|
|
|
Post by George on Jun 22, 2022 12:11:04 GMT -5
Quick count: about 60K+ code lines.
|
|
