|
Post by George on Jul 15, 2022 10:02:08 GMT -5
Robert: Hmmm, correct.
Now fixed, I'll post a Beta.
George
===> Beta corrected the issue. R
|
|
|
Post by mueh on Jul 21, 2022 7:45:25 GMT -5
Hi George! JFYI :TAG and .LABEL remain also on same line nr . I'm not shure if they should go with sorted data . Please could you upload ...22194.Source.zip as already requested by Stefan . Thanks
===> My vote would be that they also move during a SORT. Line coloring, X status, User status, Labels and Tags are all attributes of a line. Right now, colors and User status are retained as of the last fix. X status is also retained, as long as you say SORT DX. (SORT treats "modification" of lines due to sorting as a "change", the kind that makes excluded lines "pop out" during a FIND or CHANGE.)
R
|
|
|
Post by George on Jul 21, 2022 8:08:00 GMT -5
MUEH: 22194 source is there, I just tried DL'ing it and it started just fine. If you don't even see the link, then clear/refresh your browser cache. I'll check out the :TAG and .LABEL, they probably suffer the same error. George
[UPDATE] Corrected. New Beta (22202) posted
[/UPDATE]
|
|
|
Post by Stefan on Jul 22, 2022 4:28:17 GMT -5
Hi George,
Another similar user case: Line Handles do not move with the relevant line during SORT but remain with the same line pointer, which is now a different data line.
|
|
|
Post by George on Jul 22, 2022 15:28:21 GMT -5
Stefan: Sigh! I'm sure you're right, I'll go extend the fix.
George
|
|
|
Post by mueh on Jul 23, 2022 9:15:49 GMT -5
George: Just to remind you that LTrak for Get_Trk_... Macros should also go with sorted data . Noticed also that LTrak is not set for repeated inserted lines . ( for reload of file LTrak increases by 100000 ) Correceted LTrk to LTrak in this post .
|
|
|
Post by George on Jul 23, 2022 9:56:22 GMT -5
MUEH: Good catch, I've included it. If we get more, this is going to become messy.
George
===> Going to be? Far, far too late for that :-)) R
|
|
|
Post by George on Jul 23, 2022 12:02:32 GMT -5
R: Yes, someone asked years ago why changes sometimes introduce new bugs -- i.e. don't you have a test suite to make sure nothing 'breaks' when changes are made?
Basically impossible I answered, I wouldn't even know where to start. And add in variations to test out some various CFG options. My mind boggles.
George
|
|
|
Post by mueh on Jul 24, 2022 3:51:05 GMT -5
George: Some more issues after 22204 . 1. TLP = Get_Trk_LPtr(TID) returns LPtr+1 . METHOD LLTrakScan (BYVAL key AS STRING * 4) AS LONG LOCAL k AS LONG ARRAY SCAN L(), FROM 37 TO 40, = key, TO k METHOD = k END METHOD seems to return it . Maybe TrkID 2 returned by Get_Trk_TrkID for Top line is the problem . Shouldn't it be 1 . 2. LTrak is ZERO if Lines are Insert Repeat Copy or Primary cmd Paste is done . LTrak is set to Line's included if Primary cmd COPY is done . Lines have now either zero LTrak or multiple lines having same LTrak . (accordig TRACK doc it should have a permanently assigned Track ID "unique for every Data Line" ) result is LPtr of first match in L Array . Use below macro to display result after Insert Repeat Copy lines or paste/copy of a file You can use this macro as test data . Invoke macro with Cursor on a line . 3. If reload is done LTrak increased by 100000 . Thanks
' MUHa.MACRO
DIM HA, LA, TID, TPO, TP2, TP3 AS STRING
DIM LN, LP, TLP AS number
LP = Get_Csr_LPtr
LN = Get_LNum(LP)
' LA = Get_Label$(LP)
HA = Get_Handle$("."+LN)
TID = Get_Trk_TrkID(LP)
if Get_RC > 0 then halt(Get_RC,Get_Msg$)
TLP = Get_Trk_LPtr(TID)
if Get_RC > 0 then halt(Get_RC,Get_Msg$)
TPO = Get_Trk_Pos$(1)
TP2 = Get_Trk_Pos$(2)
TP3 = Get_Trk_Pos$(3)
Halt(2,LP+"/"+LN+"|"+TLP+"/"+Get_LNum(TLP)+"|"+LA+"|"+HA+"|"+TID+"|"+TPO+"|"+TP2+"|"+TP3)
|
|
|
Post by George on Jul 24, 2022 10:30:09 GMT -5
MUEH: Yes, it's out 1.
I tried the correction in LLTrakScan, and the whole TRACKB and TRACKF logic collapsed in a mess. That logic drove me nuts trying to get it to work in the first place, so rather than go through all that again, I took the simpler way out and adjusted the value right in the Get_Trak_LPtr routine in _BMacro.
While investigating, I also made a change to LInsertEmpty. When the line table expands, the entries are all fully reset, however the way it is called on opening a tab, that did not occur, so I corrected that. It didn't help this particular problem, but still needed doing.
I'll post another Beta.
George
|
|